KVM

•

こんにちは！こんにちは！かわいい変態 (っ´∀｀)っ ゃーたんだよー！今日は、
KVMのホストOSでカーネルをupdateして再起動したら、ゲストOSの1つが上がってこ
なかった話をするね！

■ 事象

ホストOS再起動後、自動起動するはずのゲストOSが起動してこない。手オペで起動しようとすると

error: Timed out during operation: cannot acquire state change lock

というメッセージが・・・

 

■ 環境

旧カーネル)

2.6.18-274.12.1.el5

 

新カーネル)

2.6.18-274.17.1.el5

 

 

kvmのバージョン

$ yum info kvm
Installed Packages
Name : kvm
Arch : x86_64
Version : 83
Release : 239.el5.centos.1

 

 

libvirtのバージョン

$ yum info libvirt
Installed Packages
Name : libvirt
Arch : x86_64
Version : 0.8.2
Release : 15.el5_6.4

 

 

OSのバージョン

$ cat /etc/redhat-release
CentOS release 5.7 (Final)

 

 

 

■ 対処方法

hogehoge.example.com というゲストOSだけ立ち上がってこない場合、rootになるかsudoで以下のコマンドを起動

# killall -9 libvirtd
# rm -f /var/run/libvirtd.pid
# /etc/init.d/libvirtd restart
# virsh start hogehoge.example.com

 

ぼくの場合、これで起動しました。
※ 参考URI Red Hat Bugzilla – Bug 676205

•

結論：  圧倒的じゃないか、我が軍 (--accelerateオプション)は！

 

ddコマンドさん、疑ってすみませんでした。むしろ、 virt-install に --accelerate をつけたときの比較では、最初にddでイメージ作ったほうが速かったです。<つぶやき>まるで真っ先に石狩の障害原因としてzfsが疑われたような扱いでしたね・・・

というわけで、前回のエントリの続きです。４つのインストール方法ごとの結果を公表いたしまする。。。今日の作業も下北沢オープンソースCafeで行なっとりやす。

…続きを読む →

•

KVMのゲストOSが格納されるディスクイメージの作り方によって、ゲストOSができあがるまでの時間と起動後のパフォーマンスにすんげー差があるというお話。

比較対象のゲストOSはいずれもvcpuを1にしてメモリも1.5GBずつ、ハードディスクは20GBずつにしたんだけど、最初にddコマンドでイメージを作ってからvirt-installでゲストをインストールするのと、virt-installする際にディスクイメージを作るのとだと、後者のほうが圧倒的に早かった。それぞれのコマンドを比較してみる。

[cc lang='bash' ]INSTANCE=1.example.com ; PORT=10000 ; sudo dd if=/dev/zero of=/opt/vmimg/${INSTANCE}.img bs=1048576 count=1 seek=19456 && sudo virt-install --connect qemu:///system --name=${INSTANCE} --ram=1536 --vcpus=1 --network=bridge:br0 --file=/opt/vmimg/${INSTANCE}.img --file-size=20 --nonsparse --hvm --os-type=linux --vnc --vncport=$PORT --cdrom=/home/oresama/tmp/CentOS-5.6-x86_64-bin-DVD-1of2.iso[/cc]

 

[cc lang='bash' ]INSTANCE=2.example.com ; PORT=10001 ; MEMSIZE=1536 ; DISKSIZE=20 ; sudo virt-install --connect qemu:///system -n ${INSTANCE} -r ${MEMSIZE} --vcpus=1 -f /opt/vmimg/${INSTANCE}.img -s ${DISKSIZE} --os-type linux --os-variant=virtio26 --accelerate --network=bridge:br0 --hvm --cdrom=/home/oresama/tmp/CentOS-5.6-x86_64-bin-DVD-1of2.iso --vnc --vncport=$PORT[/cc]

 

前者は40分くらいかかったのに対し、後者はわずか10分足らず。面倒なことするだけ無駄ってことか？理由がわかる人いたら教えてください＞＜

•

以前、こちらでゲストOSのメモリサイズ変更方法を書いたが、たまにうまく動かないことがある。理由はわからんけど、コマンドそのものは正常終了しているのに反映されなかったり、ゲストOSを起動している間でないと反映されなかったり(ありえねー)・・・。

というわけで、どうにかならんものかとググったら枯山水のメーリングリストが引っかかったが、
調査したところ、libvirt(0.8.2-0.8.3)のqemuドライバでは、domainSetMaxMemory APIは
未サポートのようでした。（xenドライバではサポートされています。）
とのこと。うちのは libvirt-0.8.2-15.el5.3 だったんだけど、この辺とか見てると未だ対応中？ということで手動でゲストOSのメモリサイズを変更してみた。流れは以下のとおり。
1) メモリサイズを変更したいマシンをシャットダウンする

$ ssh hogehoge.example.com
$ sudo /sbin/shutdown -h now
または
$ su -
# shutdown -h now

2) エディタでxmlファイルを編集しメモリの上限サイズを変更する

$ sudo cp -p /etc/libvirt/qemu/hogehoge.example.com.xml /etc/libvirt/qemu/hogehoge.example.com.xml.orig

$ sudo vi /etc/libvirt/qemu/hogehoge.example.com.xml
変えるところは以下の2行。
  262144
  262144
ここの数値はキロバイト単位なので、1024で割ったら256MBになるって寸法。xmlファイルの先頭4～5行目にあるので、すぐに見つけられるはず。
 
 
3) 母艦マシンのvirshコマンドで反映させる
対象ゲストOSのxmlファイルを編集し終わったら、以下のコマンドで反映させる。
$ sudo virsh define /etc/libvirt/qemu/hogehoge.example.com.xml
4) 母艦マシンのvirshコマンドでマシンを起動する
$  sudo /usr/bin/virsh start hogehoge.example.com

作業前後で仮想マシンにログインしてfreeコマンドやtopコマンドで確認して、期待通りであればOKです。
ね、簡単でしょ？