KVMその3(オプション色々)

さて、kvmコマンド(実際には、内部で /usr/bin/qemu-system-x86_64 を呼び出すラッパースクリプトだけど)には、多くのオプションがある。

オプション一覧は、
$ kvm -h
もしくは
$ kvm -help
で出てくるが、めちゃくちゃ多い。

とりあえず、分かるところ、よく使いそうなところだけピックアップして紹介。

[マシンタイプ関連(-machine)]
仮想マシンの基本構成に関するオプションになる。
$ kvm -machine help
でリストが出てくる。
どのチップセットとコントローラをエミュレートするのか？という選択肢で、事実上

• i440FX + PIIX
• Q35 + ICH9

のどちらかになるみたいだ。
ヘルプでは、xenfv / xenpv というのも指定出来るように書かれているが、これを使うためには、別途xen関連のライブラリをインストールする必要がありそうだ。
xenを使う予定は無いので、無視することにする。

基本的な使い方は以下の通り。
$ kvm -hda test.img -boot c -m 512 -machine type=pc
$ kvm -hda test.img -boot c -m 512 -machine type=q35

マシンタイプの設定に、アクセラレータの指定もある。
良く分からないのだが、kvm / xen / tcg の3つのどれかを指定できるようだ。

使い方例
$ kvm -hda test.img -boot c -m 512 -machine type=q35,accel=tcg
$ kvm -hda test.img -boot c -m 512 -machine type=q35,accel=kvm
(xen はmachinetypeを xenfv or xenpv にした時に意味があるようだ。xen 環境は使用する予定が無いので、こちらも無視することにする。)

kvm を指定する場合、CPU に仮想化支援機能(Intel だと vt-x)が搭載されていないと使えないように見受けられる。
従って、tcg を指定した場合が一番遅く、(恐らく)kvmを指定するのが一番速いのではないだろうか？

ただ、これは qemu-system-* コマンドを実行した時に意味がある気がする。
というのも、kvm コマンド自体は、内部で qemu-system-x86_86 コマンドを、-enable-kvm オプション付きで呼び出しているから、アクセラレータは自動的にkvmになるような気がする。
(というのも、軽く触ってみた感じでは、速度差があるようには思えなかったからだ。)

試しに、kvm コマンドではなく、 qemu-system-x86_64 コマンドで呼び出してみよう。
$ qemu-system-x86_64 -hda test.img -boot c -m 512 -machine type=q35,accel=tcg
$ qemu-system-x86_64 -hda test.img -boot c -m 512 -machine type=q35,accel=kvm
ありゃ、tcgを使ったら、「TCGをサポートしてへんで」みたいなワーニングが出た。(CPU IDが違う？とかなんとか)
しかし、起動だけでものすごく時間がかかっている。やはり、tcgでは処理が遅いようだ。
軽く測ってみたところ、コマンド実行からログインプロンプトが表示されるまでの時間は、以下の通りだった。

accel=tcg	accel=kvm
65秒	10秒

accel=kvm の方が圧倒的に速い。ちなみに、シャットダウンしてウィンドウがクローズするまでの時間も段違いだった。
また、accel=kvm を指定した場合は、kvmコマンドで実行した時と同じ時間で起動出来ている様子。
ということは、-enable-kvm を使用した場合は、自動的に accel=kvm も指定されるということなのだろう。

マシンタイプ関連のオプションは他にもたくさんあるが、とりあえずここまでにして、必要に応じて書き足すことにしよう。

[CPU関連]
CPU関連のオプションは主に2つ。

• どのタイプのCPUをゲストに見せるか？(-cpu)
• 仮想マシンに幾つのCPUを割り当てるか？(-smp)

の2つだ。

-cpu は、仮想マシンのCPUの種別を指定するオプションで、かなりたくさんの種類がある。
kvm -cpu help
で一覧を確認することが出来るぞ。
例えば、Broadwell を指定すると、ゲストOSは搭載しているCPUが第5世代 Intel Core i に見えるはず…だ。ただ、Broadwell を指定しても、仮想マシンのCPUにvt-x(vmx)は搭載されていないように見えるようだ。
-cpu に host を指定した場合、ホストマシンのCPUの機能が仮想マシンにそのまま引き継がれるようだ。従って、仮想マシン側でも vt-x(vmx) が認識できる。
恐らく、-cpu host と指定することで、 nested KVM (KVMの仮想マシン上でKVMを建てる)なんてことが出来るようになるはずだ。
異なる世代のCPUを搭載した物理マシン間では、-cpu host と指定した仮想マシンは、オンライン移行(V-Mothion)は出来ないだろう。これは余裕があったら検証したい。

色々なオプションを指定しながら、ゲストOS側で cat /proc/cpuinfo を実行してみるとその差が分かると思う。
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host

-smp で仮想マシンから認識可能なCPUの数を指定できる。
結構細かく指定できるのだが、あまり差異は無いと思われる。
今私が使っているマシンは、2コア4スレッドで、論理4コアのため、恐らく4を超える数字を指定することは出来ないだろう。
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host -smp 4
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host -smp 8
なんと、8個も指定できてしまった。(16も指定できた…）
これ、8CPUではなく、2sockets * 2cores * 2thread の論理8CPUとして定義してみたらどうだろうか？
$ kvm -hda test.img -boot c -m 512 -machine type=q35 -cpu host -smp 8,cores=2,threads=2,sockets=2
う～ん、指定できた。しかも、きちんと2ソケット2コア2スレッドの合計8CPU(論理)で認識されている。ちょっと驚きだ。

[network関連(-netdev)]
ネットワーク関連のオプションは、かなり複雑怪奇。
なお、-netというオプションもあるが、どうやらこちらは古いオプションで、今後は-netdevを使用することになるようだ。

network関連をきちんと使うには、libvirtを使用する形(virsh等で設定)が良いようだ。
現時点ではまだvirshやvirt-managerは使っていないため、次のタイミングで要調査とする。

[storage関連(-fd?/-hd?等)]
こちらも、オプションがたくさんあるが、virsh等を用いた方が効率が良いようだ。
virshやvirt-managerを使うタイミングで記載することにしよう。

[display関連]
こちらもオプションは多く、一つ(-spice)だけ紹介することにする。(詳細は後日…)
今までの状態では、サーバ側でゲストOSの画面が作成され、それがXプロトコルにて手元の操作端末に転送されていたと思う。
Xプロトコルというのは、実はお世辞にもそんなに速いプロトコルではなく、更に手元の端末のWindowsの画面描画と仕組み的に合わず、VcXsrv等のソフトウェアが上手いこと差分を吸収してくれている。

但しこれだと、Xで描画が出来なくなった状態(サーバと作業端末の間のXプロトコルが切断されてしまった場合、ネットワークトラブル等)で、仮想マシンがダウンしてしまう。
これでは、仮想マシンを運用するメリットが無いと言い切ってもいいだろう。

そこで幾つかのオプションがある。

そのうちの一つが、画面転送でよく使われているvncプロトコルを利用するオプション(-vnc)だ。
だけど、敢えてvncではなく、spiceの方(-spice)を利用する。
spiceは、vncのような画像転送プロトコルだが、非常に優れた機能を持っている(らしい)。

spiceの使用に関しては、また別途記載する。

長くなったので、一旦ココまで。