【CentOS】OpenStack(RDO)をインストールしてみる

https://www.rdoproject.org/

RDO is a community of people using and deploying OpenStack on CentOS, Fedora, and Red Hat Enterprise Linux.
ということで、OpenStackはどんなもんじゃろうということで、空いているHDDにCentOSを入れて、インストールしてみました。
（LinuxMintでDevStackを入れようと思ったら上手く入らなかった）

といっても、基本的にはここにある通り、コマンドを打てば簡単にインストール可能
https://www.rdoproject.org/install/packstack/

$ su -
$ yum update -y
$ yum install -y centos-release-openstack-queens

(略)
Installed:
centos-release-openstack-queens.x86_64 0:1-1.el7.centos

Dependency Installed:
centos-release-ceph-luminous.noarch 0:1.1-2.el7.centos
centos-release-qemu-ev.noarch 0:1.0-3.el7.centos
centos-release-storage-common.noarch 0:2-2.el7.centos
centos-release-virt-common.noarch 0:1-1.el7.centos

Complete!

$ yum update -y
$ yum install -y openstack-packstack

(略)
Installed:
openstack-packstack.noarch 1:12.0.0-2.el7

Dependency Installed:
facter.x86_64 1:2.4.4-4.el7
hiera.noarch 1:1.3.4-5.el7
libimagequant.x86_64 0:2.8.2-2.el7
libselinux-ruby.x86_64 0:2.5-12.el7
openjpeg2.x86_64 0:2.1.2-1.el7
openstack-packstack-puppet.noarch 1:12.0.0-2.el7
puppet.noarch 0:4.8.2-1.el7
puppet-aodh.noarch 0:12.4.0-1.el7
puppet-apache.noarch 0:2.3.1-1.e587f2agit.el7
puppet-archive.noarch 0:2.2.1-0.10888dbgit.el7
puppet-ceilometer.noarch 0:12.5.0-1.el7
puppet-certmonger.noarch 0:2.3.0-1.el7
puppet-cinder.noarch 0:12.4.0-1.el7
puppet-concat.noarch 0:4.1.1-1.d4857dfgit.el7
puppet-corosync.noarch 0:6.0.1-0.9940eb9git.el7
puppet-firewall.noarch 0:1.12.0-1.3dc1990git.el7
puppet-glance.noarch 0:12.5.0-1.el7
puppet-gnocchi.noarch 0:12.4.0-1.el7
puppet-heat.noarch 0:12.4.0-1.el7
puppet-horizon.noarch 0:12.4.0-1.el7
puppet-inifile.noarch 0:2.2.0-1.d2c38b9git.el7
puppet-ironic.noarch 0:12.4.0-1.el7
puppet-keystone.noarch 0:12.4.0-1.el7
puppet-magnum.noarch 0:12.2.0-1.el7
puppet-manila.noarch 0:12.4.0-1.el7
puppet-memcached.noarch 0:3.1.0-1.el7
puppet-mysql.noarch 0:5.2.1-1.a5497b2git.el7
puppet-neutron.noarch 0:12.4.0-1.el7
puppet-nova.noarch 0:12.4.0-1.el7
puppet-nssdb.noarch 0:1.0.1-1.el7
puppet-openstack_extras.noarch 0:12.4.0-1.el7
puppet-openstacklib.noarch 0:12.4.0-1.el7
puppet-oslo.noarch 0:12.4.0-1.el7
puppet-ovn.noarch 0:12.4.0-1.el7
puppet-panko.noarch 0:12.4.0-1.el7
puppet-rabbitmq.noarch 0:8.1.1-0.d4b06b7git.el7
puppet-redis.noarch 0:3.2.0-2.bfcc212git.el7
puppet-remote.noarch 0:0.0.1-3.7420908git.el7
puppet-rsync.noarch 0:0.4.0-3.447685fgit.el7
puppet-sahara.noarch 0:12.4.0-1.el7
puppet-ssh.noarch 0:3.0.1-4.fb2de75git.el7
puppet-staging.noarch 0:1.0.4-1.b466d93git.el7
puppet-stdlib.noarch 0:4.24.0-1.b0d99adgit.el7
puppet-swift.noarch 0:12.4.0-1.el7
puppet-sysctl.noarch 0:0.0.11-1.el7
puppet-tempest.noarch 0:12.5.0-1.el7
puppet-trove.noarch 0:12.4.0-1.el7
puppet-vcsrepo.noarch 0:2.3.0-1.bb1209egit.el7
puppet-vswitch.noarch 0:8.4.0-1.el7
puppet-xinetd.noarch 0:3.0.0-1.b95c79cgit.el7
python-docutils.noarch 0:0.11-0.3.20130715svn7687.el7
python2-olefile.noarch 0:0.44-1.el7
python2-pbr.noarch 0:3.1.1-8.el7
python2-pillow.x86_64 0:4.0.0-1.el7
ruby-augeas.x86_64 0:0.5.0-1.el7
ruby-shadow.x86_64 0:1.4.1-23.el7
rubygem-rgen.noarch 0:0.6.6-2.el7

Complete!

$ sudo packstack --allinone
Welcome to the Packstack setup utility

The installation log file is available at: /var/tmp/packstack/20180811-164344-0UZHo_/openstack-setup.log
Packstack changed given value to required value /root/.ssh/id_rsa.pub

Installing:
Clean Up [ DONE ]
Discovering ip protocol version [ DONE ]
Setting up ssh keys [ DONE ]
Preparing servers [ DONE ]
Pre installing Puppet and discovering hosts' details [ DONE ]
Preparing pre-install entries [ DONE ]
Setting up CACERT [ DONE ]
Preparing AMQP entries [ DONE ]
Preparing MariaDB entries [ DONE ]
Fixing Keystone LDAP config parameters to be undef if empty[ DONE ]
Preparing Keystone entries [ DONE ]
Preparing Glance entries [ DONE ]
Checking if the Cinder server has a cinder-volumes vg[ DONE ]
Preparing Cinder entries [ DONE ]
Preparing Nova API entries [ DONE ]
Creating ssh keys for Nova migration [ DONE ]
Gathering ssh host keys for Nova migration [ DONE ]
Preparing Nova Compute entries [ DONE ]
Preparing Nova Scheduler entries [ DONE ]
Preparing Nova VNC Proxy entries [ DONE ]
Preparing OpenStack Network-related Nova entries [ DONE ]
Preparing Nova Common entries [ DONE ]
Preparing Neutron LBaaS Agent entries [ DONE ]
Preparing Neutron API entries [ DONE ]
Preparing Neutron L3 entries [ DONE ]
Preparing Neutron L2 Agent entries [ DONE ]
Preparing Neutron DHCP Agent entries [ DONE ]
Preparing Neutron Metering Agent entries [ DONE ]
Checking if NetworkManager is enabled and running [ DONE ]
Preparing OpenStack Client entries [ DONE ]
Preparing Horizon entries [ DONE ]
Preparing Swift builder entries [ DONE ]
Preparing Swift proxy entries [ DONE ]
Preparing Swift storage entries [ DONE ]
Preparing Gnocchi entries [ DONE ]
Preparing Redis entries [ DONE ]
Preparing Ceilometer entries [ DONE ]
Preparing Aodh entries [ DONE ]
Preparing Puppet manifests [ DONE ]
Copying Puppet modules and manifests [ DONE ]
Applying 192.168.11.XXX_controller.pp
192.168.11.XXX_controller.pp: [ DONE ]
Applying 192.168.11.XXX_network.pp
192.168.11.XXX_network.pp: [ DONE ]
Applying 192.168.11.XXX_compute.pp
192.168.11.XXX_compute.pp: [ DONE ]
Applying Puppet manifests [ DONE ]
Finalizing [ DONE ]

**** Installation completed successfully ******

Additional information:
* A new answerfile was created in: /root/packstack-answers-20180811-164344.txt
* Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components.
* Warning: NetworkManager is active on 192.168.11.XXX. OpenStack networking currently does not work on systems that have the Network Manager service enabled.
* File /root/keystonerc_admin has been created on OpenStack client host 192.168.11.XXX. To use the command line tools you need to source the file.
* To access the OpenStack Dashboard browse to http://192.168.11.XXX/dashboard .
Please, find your login credentials stored in the keystonerc_admin in your home directory.
* Because of the kernel update the host 192.168.11.XXX requires reboot.
* The installation log file is available at: /var/tmp/packstack/20180811-164344-0UZHo_/openstack-setup.log
* The generated manifests are available at: /var/tmp/packstack/20180811-164344-0UZHo_/manifests

インストールができればダッシュボードにアクセスが可能。
なお、パスワードは以下のファイルに記載されている（ランダム生成）。
/root/keystonerc_admin

以下で、アクセス可能。
http://192.168.11.XXX/dashboard
user:admin
password:****************

【LinuxMint】カーネルロールバック

仮想マシンのLinuxMintをカーネルを4.13にしたらうまく動くなったので、4.10に戻しました。

キャプチャとかできなかったので雑に。
①仮想マシン起動後に即ESCキーを実行、一度GRUB画面でカーネル4.10で起動します。
②Ubuntu Kernel Update Utility (Ukuu) - GUIから簡単にカーネルのバージョンを確認して古いカーネルを削除できる | Ubuntuアプリのいいところ
を参考に

$ sudo apt-add-repository ppa:teejee2008/ppa
$ sudo apt update
$ sudo apt install ukuu

ukuuをGUI起動し、4.13カーネルをremoveすることで、4.10での起動ができるようになります。

※今どのカーネルを利用できるかは以下のコマンドで確認可能

$ uname -r

【KVM/QEMU】仮想マシン(Win10)と実マシン(Win10)のベンチマーク比較（おまけで仮想ディスクベンチマーク）

タイトルの通りですが、どんなもんだろうと思って比較しました。

■前提条件

・仮想マシンはついこないだ構築したばかり(【Linux Mint】KVMによるパススルー設定 - かっこいいブログ名つけたい)でLinuxMint上のWin10です。

・実マシンと言っているのは、↑とは別のSSDにインストール済みの元々使っていたWin10ですが、割と使い込んでいるのでいろいろアプリが入ってます。

・基本的に各パターン1回程度の実行です。本当は何回かやったほうがいいと思うけど、時間が足りない。

・一応、環境を再記載

マザボ:ASRock Z170 Extreme4

メモリ:DDR4 32GB

CPU:Core i7-6700K 

グラボ:STRIX-GTX1060-DC2O6G

１．cpu-z(1.84)でのCPUベンチマーク比較

パターン①：virt-managerの設定にて

・設定：「ホストCPUの設定をコピー」

・トポロジー：ソケット数2　コア数：4

パターン②：virt-managerの設定にて

・設定：「ホストCPUの設定をコピー」

・トポロジー：ソケット数1　コア数：8

パターン③：virt-managerの設定にて

・設定：モデルに直接「host-passthrough」(参考：KVM - ArchWiki)

・トポロジー：手動設定なし

パターン④：virt-managerの設定にて

・設定：モデルに直接「host-passthrough」(参考：KVM - ArchWiki)

・トポロジー：ソケット数2　コア数：4

パターン⑤：実マシン

整理すると

パターン	設定	ソケット数	コア数	CPU Single Thread	CPU Multi Thread
パターン①	ホストCPUの設定をコピー	2	4	418	2322.1
パターン②	ホストCPUの設定をコピー	1	8	427.8	2288.8
パターン③	host-passthrough	手動設定なし	手動設定なし	440.4	869.7
パターン④	host-passthrough	2	4	412.2	2335.5
パターン⑤	-	1	8	435.2	2408.8

です。

計測時の画像でReferenceを設定していたりしていなかったりはご愛嬌で・・・。

パターン③のCPU Multi Threadが極端に遅いのはソケット数とコア数がともに２ずつしか認識していないからですね。Windows7～10ではソケット数の上限が2個に制約されてしまうらしいです(WindowsServerならそうでもないらしい？)。ので、Redhatの仮想化のチューニングと最適化ガイド - Red Hat Customer Portalで記載されている、

「注記

環境によっては要件が異なることもありますが、 ソケット数を選択する場合、 コア、 スレッドいずれもひとつのみにした方が一般的には最善のパフォーマンスとなります。」

というのを信じて、仮想Windowsマシンをソケット数8でコア数1で設定しても、パターン③同様にソケット数は2個として認識されます。

実際のところ、仮想環境でオーバーヘッドがかかるかと思いきやそうでもない感じですかね？

実マシンとの性能差異がない、というか、Referenceの6700Kと比較しても遜色がないですな・・・。

ちなみに

【Linux/QEMU/KVM】 CPU Pinning（CPUアフィニティ）の設定でゲスト上のWindowsを快適に動かす - TECHLOGICS

を参考にCPU Pinningをやっていますが、やっていない状態とあまりスコアの違いは見られませんでした。

なお、設定を「ホストCPUの設定をコピー」と「host-passthrough」ではcpu-z上でCPU欄は以下のように変わります。

・「ホストCPUの設定をコピー」

・「host-passthrough」

「host-passthrough」のほうはプロセッサ情報が実CPU情報になるようですね。面白いですねぇ。

２．CrystalMark2004R7での比較

パターン①：virt-managerの設定にて

・設定：「ホストCPUの設定をコピー」

・トポロジー：ソケット数1　コア数：8

パターン②：virt-managerの設定にて

・設定：モデルに直接「host-passthrough」(参考：KVM - ArchWiki)

・トポロジー：ソケット数2　コア数：4

パターン③：実マシン

総合スコアでみるとなぜか実マシンが負けるという・・・

３．結論

ベンチマーク的に見れば仮想環境でも十分性能は発揮できる。1項の設定パターンについては、思った以上にはスコア差出なかったのでパターン③以外であれば何でもいいんじゃないですかね。(適当)

４．おまけ

ところで仮想環境上ではSSDの読み書きは遅くなるのかな？ と思って測ってみました。

ただ、フォーマットはqcow2とrawで比較するとraw(非スパース)のほうがいいらしい。

なんでもqcow2は使った分だけディスク領域を使うがオーバーヘッドが発生し、raw(非スパース)は定義したディスク領域を最初からガツっと確保するらしいので、オーバーヘッドが起きにくいとか。ということなので、それも比較。

参考：KVMを使う（ディスク性能編その2） « さくらインターネット研究所

パターン①【qcow2】

・仮想ディスクのパフォーマンスオプション
キャッシュモデル：ハイパーパイザーのデフォルト(writethrough)
IOモード：ハイパーパイザーのデフォルト

パターン②【raw(非スパース)】

※qcow2→raw(スパース)→raw(非スパース)に変換したもの

・仮想ディスクのパフォーマンスオプション
キャッシュモデル：ハイパーパイザーのデフォルト(writethrough)
IOモード：ハイパーパイザーのデフォルト

あまり変わりませんね・・・？

qcow2はディスク拡張すると性能劣化が激しいと聞いており、実際やりましたが(【LinuxMint】【QEMU/KVM】ディスク容量を拡張する - かっこいいブログ名つけたい)、そうでもありませんね。

というより、CT250MX500SSD1使っていますが、read：560MB/s、wirte：510MB/sなのになぜそれより早いのか？ 仮想マシンだからキャッシュメモリを使ってるとかそんな感じかな？

仮想マシンで動かしたほうが早くなるってことになるのかな・・・？(謎)

【LinuxMint】【QEMU/KVM】ディスク容量を拡張する

KVM上に入れたWindows10ですが、250GBのうち、仮想マシン用として８０GB用意してデータ移管していたらあっという間に容量がなくなったため、更に５０GB追加します。ので容量拡張方法をメモ。 

1.バックアップを取る

バックアップを取りますが、qcow2形式で仮想マシンを作っており、かつスナップショットを利用していた場合、スナップショットを削除してからバックアップをとったほうが良いです。

スナップショットを消さずに拡張しようとしたらエラーになりました。

$ sudo qemu-img resize win10.qcow2 +50G
qemu-img: Can't resize an image which has snapshots
qemu-img: This image does not support resize

 スナップショットは以下の画面から操作可能。

スナップショットを削除後、容量のあるドライブにイメージファイルを退避。

普通に仮想マシンを作っていれば以下に格納されているはず。

$ cd /var/lib/libvirt/images

$ ls

win10.qcow2

※ /var/lib/libvirt/imagesはアクセス拒否されるかもしれないので、chmod755でパーミッションを変更したほうがいいかも

・イメージを退避

$ sudo cp -a win10.qcow2 /mnt/3TB/noSnapshot-win10-backup.qcow2

2．ディスクの拡張

以下のコマンドで実行されます。今回は50Gを拡張

$ sudo qemu-img resize win10.qcow2 +50G

Image resized.

３．Windows上でのディスク拡張

2項を実行後に仮想マシンのWin10を起動。この状態では、増えた容量は未割当て状態になるため、これを使えるようにする。

エクスプローラを開き、「PC」→右クリック→「管理」→「記憶域」→「ディスクの管理（ローカル）」

拡張できていれば空き領域５０GB分ができているはずなので、割り当て済みの領域（（C:）と書かれているところ）の上で右クリックし、「ボリュームの拡張」を選択

サイズを選択。ここではすべて

拡張が完了すれば、すべての領域がWin10上で使用可能になる。

【Linux Mint】【QEMU/KVM】KVMによる仮想化Win10へのGPUパススルー設定

さて、STRIX-GTX1060-DC2O6Gを購入しましたが、現状はゲームで利用しているだけで流石にどうかとおもったので、思い切ってメインPCの構成を変えることにしました。

以下の内容は個人的なメモではあるものの、GPUパススルーをやってみたいという方への助けになればと思ってます。

■参考サイト

Running Windows 10 on Linux using KVM with VGA Passthrough – Heiko's Blog

うらもちゃのブログ: ゲストにPCIパススルー(GPU割当)

CentOS7 KVM で PCIパススルー、USBパススルー - わすれないうちにメモしよう

PCI passthrough via OVMF - ArchWiki

 KVM GPUパススルー設定 - 睡分不足

あと、用語はこちらが参考になるかと

KVM-wiki TOP - PukiWiki

※2018/10/23追記

一応、Ubuntu 18.04 LTSでも同じ手順でできました。

１．やりたいこと

有り余るマシンスペックを使うべく、考えた構成は以下のとおりです。

・ホストとなるベースOSはLinuxにしたい

・ホストの上に仮想マシンを構築し、Windows１０とそれとは別にLinuxを載せたい

・グラボについては、仮想Win10でのモニタ表示、仮想LinuxでGPGPUとして使いたい（グラボのリソースは共有できないので、どちらか一方が起動していたらどちらかは落ちてる状態）

正直、今のグラボは性能はいいですが、いかんせんユーザ（私）自身が十分にスペックを活用できているかというとそうではありません。

また、機械学習（AI）の勉強をしてみたいと思っており、そうであればGPUを使わない手はありません。

であれば、グラボを活用できるように構成を見直す、というのがコンセプトです。

なお、グラボに関してですが、GPUパススルー設定をするとホストOSでは一切使用できません。ホストOSで画面描写に利用するのはCore i7-6700Kに搭載されている内蔵GPU機能となります。要するにホストOSはマザボのHDMIを使って、ゲストOSのWin10でグラボを使うようになります。

２．構成

メインPCとして利用しているマシンの構成は以下のとおりです。

・マザボ：ASRock Z170 Extreme4

・メモリ：DDR4 32G

・CPU：Core i7-6700K 

・グラボ：STRIX-GTX1060-DC2O6G

３．KVMの利用について

まず、メインPCとして利用するホストOSについてですが、

Linux Mint 18.3 Cinnamon - Linux Mint

とします。Ubuntu系であるというのと、GUIにそれなりに気を配っている点を考慮してです。

仮想化については、KVMを使います。KVM自体はLinuxカーネルに含まれる仮想化基盤となるため、今回はQEMUと組み合わせての利用となります。

普通に仮想基板上で画面描写をした場合、これはもうFF14ベンチマークがローディングで止まるぐらいクソ遅いのですが、ここで重要になるのが仮想基盤を通さず、直接グラボとやり取りできる、いわゆるGPUパススルーです。が、それが今回の大きな難関なわけで、esxi 6.5とProxmox VEでやってみたけど、挫折してQEMU/KVMにしたというのが正直なところ・・・。

４．マザボの設定

いくつかのサイトで既に記載されていますが、CPUがIntel製であれば、基本的にVT-dをONに設定できるマザボである必要があります。

幸い、私のマザボのASRockはそこら辺がだいたい全部対応してるとのことで、UFEIでVT-DをONにするだけでいけます。他のメーカは・・・まぁそれぞれによるかと。

基本的に「Intel VT-d」「I/O Virtualization Technology」などの名前の設定項目を有効にすれば問題なし。

５．ホストOSのインストール

これは普通にインストールをするだけなので省略。

６．GRUBの設定

GPUパススルーをするにはintelの仮想化支援機構である、IOMMUを活性化する必要があります。これはGRUB、要するにLinuxのブートローダですが、これを実行するときにIOMMUの指定が必要です。設定するファイルは以下の通り。

$ sudo vi /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash "
↓
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on"

$ sudo update-grub

※PCを再起動

参考サイトによっては、GRUB_CMDLINE_LINUX_DEFAULTで定義したり、GRUB_CMDLINE_LINUXで定義したり・・・。

両方試しましたが、どちらでもよさそうで、以下のように『IOMMU enabled』が確認できればとりあえず問題ない（はず）です。

 $ dmesg | grep -e DMAR -e IOMMU
[ 0.000000] ACPI: DMAR 0x0000000087A48EA0 000070 (v01 INTEL SKL 00000001 INTL 00000001)
[ 0.000000] DMAR: IOMMU enabled

７．IOMMUグループが有効であることを確認する

一旦以下のシェルを作り、PCIデバイスがどのようにIOMMUグループにマップされているかを確認できます。暫定的に作るのでファイル名は適当。

$cd ~/

$ vi aaa

#!/bin/bash
shopt -s nullglob
for d in /sys/kernel/iommu_groups/*/devices/*; do
n=${d#*/iommu_groups/*}; n=${n%%/*}
printf 'IOMMU Group %s ' "$n"
lspci -nns "${d##*/}"
done;

$ sudo chmod 755 aaa
$ ./aaa

IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation Sky Lake Host Bridge/DRAM Registers [8086:191f] (rev 07)
IOMMU Group 1 00:01.0 PCI bridge [0604]: Intel Corporation vfio-pciSky Lake PCIe Controller (x16) [8086:1901] (rev 07)
IOMMU Group 1 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c03] (rev a1)
IOMMU Group 1 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f1] (rev a1)

・・・

今回は赤文字のグラボをパススルーします。なお、以下のコマンドでよって、グラボが現状どのドライバを使っているか詳細に確認できます。（後々重要）

$ lspci -nnk -d 10de:1c03

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c03] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:85c5]

Kernel driver in use: nouveau

Kernel modules: nvidiafb, nouveau

$ lspci -nnk -d 10de:10f1

01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f1] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:85c5]

Kernel driver in use: snd_hda_intel

Kernel modules: snd_hda_intel

８．各種必要なソフトウェアのインストール

aptでインストールできるlibvirtに関しては、びっくりするほどバージョンが古いため、LinuxMintのGUI上のソフトウェアソースにて、以下のPPAを予め設定しておきます。

ppa:jacob/virtualisation

上記を行ったうえで、qemu, libvirt, ovmf, virt-managerをそれぞれインストールします。

＄ sudo apt update
＄ sudo apt install qemu-kvm qemu-utils qemu-efi ovmf libvirt-bin libvirt-dev libvirt0 virt-manager

libvirt：仮想化管理用の共通APIを提供する

OVMF：仮想環境で UEFI を使えるようにする

virt-manager：仮想環境をGUI上で管理運用できるようにするオープンソースソフトウェア

以下のコマンドで、libvirtとvirtlog(libvirtのログ出力サービス)の実行と自動実行設定を行います。

$ sudo systemctl start libvirtd
$ sudo systemctl enable libvirtd

$ sudo systemctl start virtlogd
$ sudo systemctl enable virtlogd

 なお、この際にlibvirtdのstatusを確認し、エラーが発生していた場合は以下の対応をします。

参考：https://kernhack.hatenablog.com/entry/2014/05/12/221554

$ sudo systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since 木 2018-03-29 18:21:51 JST; 1s ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 4130 (libvirtd)
CGroup: /system.slice/libvirtd.service
└─4130 /usr/sbin/libvirtd

3月 29 18:21:51 XXXX-desktop systemd[1]: Starting Virtualization daemon...
3月 29 18:21:51 XXXX-desktop systemd[1]: Started Virtualization daemon.
3月 29 18:21:51 XXXX-desktop libvirtd[4130]: libvirt version: 2.2.0, package: 0~16.04~ppa0 (Jacob Zimmermann <ppa@jzimm.net> Wed, 07 Sep 2016 22:
3月 29 18:21:51 XXXX-desktop libvirtd[4130]: hostname: XXXXXXX
3月 29 18:21:51 XXXX-desktop libvirtd[4130]: direct firewall backend requested, but /sbin/ebtables is not available: そのようなファイルやディレク
3月 29 18:21:51 XXXX-desktop libvirtd[4130]: 内部エラー: Failed to initialize a valid firewall backendIOMMU Group 1 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c03] (rev a1)
IOMMU Group 1 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f1] (rev a1)

※ebtablesをインストール。

$ sudo apt install ebtables

$ sudo systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enab。led; vendor preset: enabled)
Active: active (running) since 木 2018-03-29 18:26:31 JST; 5s ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 5341 (libvirtd)
CGroup: /system.slice/libvirtd.service
├─5341 /usr/sbin/libvirtd
└─5444 /usr/sbin/libvirtd

3月 29 18:26:31 XXXX-desktop systemd[1]: Starting Virtualizod 755 aaa ation daemon...
3月 29 18:26:31 XXXX-desktop systemd[1]: Started Virtualization daemon.

ここで一旦再起動すれば、ソフトウェアに「仮想マシンマネージャー」が追加されているはずです。

９．仮想マシンを作る

CPUやメモリサイズに関しては各自の設定したいスペックに合わせて。

Win10の仮想マシンを作るときの最後のダイアログで、「インストールの前に設定をカスタマイズする」にチェックを入れ（これ重要）、完了。

出てきたダイアログの【概要】のファームウェアでUEFIを選択します。

参考にさせていただいたhttp://mmi.hatenablog.com/entry/2018/03/25/010933では仮想マシン作成後に直接設定ファイルを弄ってましたが、これは一度仮想マシンを作るとGUI上は変更できないようで、作る際に上記のようにGUIで操作しておけば問題ない模様。

・Windows10インストール

Win10は

Windows 10 のディスク イメージ (ISO ファイル) のダウンロード

からisoファイルのダウンロードしてマウントし、クリーンインストールします。

注意点として、インストール時にVirtIOのドライバがないと、ドライバを読み込めと言われて先に進めなくなります。

そのため、まず

https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/index.html

にある「Stable virtio-win iso」をダウンロードします。

virt-managerで『ハードウェアの追加』からCD-ROMデバイスを追加し、先ほど落としたvirtio-win.isoをマウントしておきます。

もう一度整理すると、Window10インストール時はWin10自体のイメージとVirtIOドライバ用のイメージの両方が必要になります。

１０．vendor id偽装

今回使用するのは、NVIDIAのGeForceですが、これはグラフィック用に販売されているだけあって、GPUパススルーをするにはロックがかかっていて通常はできないらしいです（NVIDIA TeslaのようなGPGPU専用製品はそうではない模様）。

しかし、今回はパススルーするために以下のように8項で作っておいた仮想マシンの設定を変更することでGPUパススルーができるようになります（※もちろんメーカ非推奨のため注意！）。

なお、仮想マシン名はwin10です。

$ virsh edit win10

<features>
  <acpi/>
  <apic/>
  <hyperv>
    <relaxed state='on'/>
    <vapic state='on'/>
    <spinlocks state='on' retries='8191'/>
    <vendor_id state='on' value='whatever'/> ←追加
  </hyperv>
  <kvm>　←追加
    <hidden state='on'/>←追加
  </kvm>←追加

</features>

１１．vfio-pciの使用

VIFOについては↓のブログで説明されているのですが、

VFIOによるデバイス操作 - 睡分不足

vfio-pciは要するに擬似ドライバみたいなものらしく（あってる？）、それを使うというのはどういうことかというと、要するにホストOS（私の環境ではLinuxMint）で認識されているグラボを認識から外す、と言った感じになるようです。

現状のグラボのドライバ読み込みは以下のようになっています。

$ lspci -v -d 10de:1c03 | grep Kernel

Kernel driver in use: nouveau

Kernel modules: nvidiafb, nouveau

$ lspci -v -d 10de:10f1 | grep Kernel

Kernel driver in use: snd_hda_intel

Kernel modules: snd_hda_intel

nouveauはNVIDIA グラボ用のフリードライバとのこと。

1項で書いたとおり、ホストOSではグラボは使いません（ホストOSのモニタ表示はCPU内臓のGPU機能を使う）。

グラボはホストOS上の仮想Win10のモニタ表示と仮想LinuxのGPGPUとして使いたいので、上記のようにホストOSでグラボが認識できるようNVIDIA用のドライバが読み込まれていると不都合なわけです。

そのため、グラボのドライバをvfio-pciにすることで、ホストOSによるモニタ表示に使えなくします（これをしないとホストOSとゲストOS（win10）でグラボを取り合うことになるので画面は正常に動かなくなる模様）。

 ・vfio-pciが使えるか確認

$ modinfo vfio-pci
filename: /lib/modules/4.13.0-37-generic/kernel/drivers/vfio/pci/vfio-pci.ko
description: VFIO PCI - User Level meta-driver
author: Alex Williamson <alex.williamson@redhat.com>
license: GPL v2
version: 0.201です。:00.1
srcversion: 559BDF748E53047F2FF090B
depends: vfio,irqbypass,vfio_virqfd
intree: Y
name: vfio_pci
vermagic: 4.13.0-37-generic SMP mod_unload
parm: ids:Initial PCI IDs to add to the vfio driver, format is "vendor:device[:subvendor[:subdevice[:class[:class_mask]]]]" and multiple comma separated entries can be specified (string)
parm: nointxmask:Disable support for PCI 2.3 style INTx masking. If this resolves problems for specific devices, report lspci -vvvxxx to linux-pci@vger.kernel.org so the device can be fixed automatically via the broken_intx_masking flag. (bool)
parm: disable_vga:Disable VGA resource access through vfio-pci (bool)
parm: disable_idle_d3:Disable using the PCI D3 low power state for idle, unused devices (bool) 

上記のように表示されればまず問題ないはず。というか、Linuxカーネル4.1以上でvfio-pciは組み込まれているはずなので、それ以上であれば問題ないはず。

・モジュールリストの更新。

以下を追加することでブート時に読み込むモジュール指定できます。

$ sudo vi /etc/modules
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
kvm
kvm_intel

※この段階で一度再起動する

・上記の設定が問題なければ、追加したモジュールはlsmodで見れます。

$ lsmod | grep vfio
vfio_pci 40960 0
vfio_virqfd 16384 1 vfio_pci
irqbypass 16384 2 kvm,vfio_pci
vfio_iommu_type1 24576 0
vfio 28672 2 vfio_iommu_type1,vfio_pci

$ lsmod | grep kvm
kvm_intel 204800 0
kvm 589824 1 kvm_intel
irqbypass 16384 2 kvm,vfio_pci

・/etc/modprobe.d/vfio.confを新規に作ってデバイスを設定

LinuxMintにはvfio.confがはいっていなかったので、新規に作ります。私の環境では以下の通りですが、これは６項に一度記載した グラボのグラフィックとオーディオのPCI ID部分が設定対象になります。

 IOMMU Group 1 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c03] (rev a1)
IOMMU Group 1 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f1] (rev a1)

$ sudo vi /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:1c03,10de:10f1,1b21:1242,1033:0194

後ろの２つのPCI-IDはUSB PCIのパススルー設定ですが、今回は説明を割愛。

・一度再起動した後、以下のコマンドを実行

$ dmesg | grep -i vfio
[ 3.382020] VFIO - User Level meta-driver version: 0.3
[ 3.390893] vfio_pci: add [10de:1c03[ffff:ffff]] class 0x000000/00000000
[ 3.412048] vfio_pci: add [10de:10f1[ffff:ffff]] class 0x000000/00000000
[ 3.412053] vfio_pci: add [1b21:1242[ffff:ffff]] class 0x000000/00000000
[ 3.412054] vfio_pci: add [1033:0194[ffff:ffff]] class 0x000000/00000000

上記のように登録されていればOK。

再起動後、ホストOS上でグラボにどのドライバが設定されているかを見ます。

$ lspci -v -d 10de:1c03 | grep Kernel

Kernel driver in use: nouveau

Kernel modules: nvidiafb, nouveau

$ lspci -v -d 10de:10f1 | grep Kernel

Kernel driver in use: vfio-pci

Kernel modules: snd_hda_intel

上記のようにオーディオが変わっているが、グラフィックのほうが変わっていない場合は更に設定を変更します。

方法は3つ。なお、私の環境では①はうまく動かず、②は他のサイトに書いてありましたが未実施、というか③のほうがより明示的な指定なので、③の方式にしました。

①ブラックリストに/etc/modprobe.d/blacklist.confに記載を追加

$ sudo  vi /etc/modprobe.d/blacklist.conf
blacklist nouveau
blacklist snd-hda-intel

※保存後、再起動

②/etc/default/grubの設定で、nomodesetを追加

$ sudo vi /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT=01:00.1"quiet splash intel_iommu=on"
↓
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on nomodeset"

$ sudo update-grub

※再起動

③/etc/default/grubの設定で、modprobe.blacklist=nouveauを追加

$ sudo vi /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on"
↓
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on modprobe.blacklist=nouveau"

$ sudo update-grub

※再起動

 再起動後はグラフィックボードからのグラフィック出力がなくなるので、マザボのHDMIに予め繋いでおいたほうが良いです。

設定後に以下のようになっていればOK。

$ lspci -v -d 10de:1c03 | grep Kernel

Kernel driver in use: vfio-pci

Kernel modules: nvidiafb, nouveau

 １２．仮想マシン設定でパススルーするPCIを設定

仮想マシンの「ハードウェアの追加」からPCIを選択します。

 IOMMU Group 1 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:1c03] (rev a1)
IOMMU Group 1 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10f1] (rev a1)

 6項で確認したデバイスの番号と合うものを選択します。

後は仮想マシン設定で「ディスプレイSpice」と「ビデオQXL」を削除します。

仮想マシンを起動して、グラボに繋いだHDMIからモニタに出力されていればGPUパススルーは完了です。

１３．グラボのGPUパススルーと直使用の比較

FF14ベンチマークをやってみました。

【GPUパススルー】

【直】

やはり性能差は出る模様ですが、ゲームをする分には支障ないレベルみたいです。

おそらくチューニングをやれば性能は上がると思われますが…

※追記

設定ごとの性能比較してみたけど、CPU性能とかはそんなに変わらないかもしれない。

engetu21.hatenablog.com

GPUパススルーでNVIDIAのCUDA(機械学習)に利用する場合はこちら

engetu21.hatenablog.com

※2018/10/23追記

仮想化Win10を使った音声ですが、HDMI経由の音声を使うか、USBをパススルーしてUSBオーディオ機器を使うか、音声PCIをパススルーするかになります。

音声PCIをパススルーすると仮想Win10実行中はホストOSは音声出力できなくなります。

また、HDMI経由の音声というのは、要するにモニタのしょぼいステレオから流れるということになるので、S/PDIF(光デジタルオーディオ)使ってスピーカーと繋げたいんだ！という人は「HDMI 音声 分離」でググって出てくるHDMI音声分離器とか使ってみるといいかと思います。（私はこの方法です）

【Linux Mint】SambaのGUI（system-config-samba）が動かない場合の対処

LinuxMintでSambaを入れました。

$ sudo apt-get install samba system-config-samba

インストールすれば、それっぽいアイコンがメニューに現れると思いますが、メニューにない場合は、sudo system-config-sambaでも実行可能。

が、デスクトップからGUI起動できない・・・。

どうやら1.7xは大丈夫らしいけど、1.8xではダメらしい。

どうやらetc配下にlibuser.confというファイルを作り、権限を与えるといいらしい。

$ sudo touch /etc/libuser.conf
$ sudo chmod 777 /etc/libuser.conf

 無事起動しました。解決！

※追記

Ubuntu18.04でも同じような感じだったので、上記の対応で解消できる。

【Linux Mint】NTFSフォーマットのHDDが見れなくなったのでリードオンリーでマウント

Linux Mint18.3を使っているのですが、ついさっきまで見えていたNTFSフォーマット（Windowsで使ってた）の3TBが急に見えなくなりました。

$ sudo fdisk -l
Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: ED778F8E-0EBF-4D86-9F87-79F2D16093CF

デバイス Start 最後から セクタ Size タイプ
/dev/sda1 34 262177 262144 128M Microsoft reserved
/dev/sda2 264192 5860532223 5860268032 2.7T Microsoft basic data

Partition 1 does not start on physical sector boundary.

 なんか変なエラーが出ています・・・。

$ sudo mount /dev/sda2 /mnt/3TB/
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Failed to mount '/dev/sda2': 許可されていない操作です
The NTFS partition is in an unsafe state. Please resume and shutdown
Windows fully (no hibernation or fast restarting), or mount the volume
read-only with the 'ro' mount option.

どうやらntfsfixというコマンドで修復できるらしいのですが、現在やっているのはWindows→LinuxMintへの移設（正確には後で書くけど、KVM×Windows10×GPUスルーをやる予定）で、念の為Windowsで使えるようにはしておきたいので、どうなるかわからないこのコマンドは打ちたくない。そして現状はリードオンリーで問題ない。

というわけで以下のコマンドを実行

$ sudo mount -r /dev/sda2 /mnt/3TB/

はい、すんなりマウントできました。

後でちゃんと変換しないとなぁ