返信する: ぶろぐコメント
| 対象モジュール | なーお'nぶろぐ |
| 件名 | [仮想PC] KVM+QEMU on UbuntuでAMD-V |
| 要旨 | 仮想ＰＣ、今度は「KVM」＋「QEMU」にトライ中です。 もうほとんどビョーキですね。 しかし、かなりサクサク動く印象です。... |
- [仮想PC] KVM+QMEU まとめ
- 投稿者: なーお 投稿日時: 2008/12/22 7:09
現行のVMware-server上の仮想ＯＳブートティスクをRawDiskに変換して、KVM+QEMUで起動することだできた！
まずは、前日分に遡ってのメモから。
ページ内コンテンツ1 パッケージのインストール
sudo apt-get install kvm qemu bridge-utils libvirt-bin virt-manager
ほかにもあったかも。。
2 kvmの有効化
2-1 kvmモジュールをロード
$ sudo modprobe kvm $ sudo modprobe kvm_amd
2-2 /etc/modulesの編集
起動時にkvmを自動的に読み込むようにするため，/etc/modulesに
kvm kvm_amd
という２行を追記。
2-3 確認
$ lsmod | grep kvm kvm_amd 22156 0 kvm 64944 1 kvm_amd
3 ネットワークのブリッジ接続
3-1 /etc/kvm/kvm-ifupの編集
NICの２枚挿しに対応するための編集。
４行目で、「br0」の生書きに変更しないと、うまくリンクされない。1 2 3 4 5
#!/bin/sh /sbin/ifconfig $1 0.0.0.0 up /usr/sbin/brctl addif br0 $1 exit 03-2 /etc/network/interfacesの編集
ブリッジ接続するほうのNIC「eth3」は記述を完全消去。 それまで使っていた固定IPをbr0に振る。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
auto lo eth4 iface lo inet loopback iface eth4 inet static address 192.168.1.26 netmask 255.255.255.0 broadcast 192.168.1.255 network 192.168.1.0 auto br0 iface br0 inet static address 192.168.0.26 netmask 255.255.255.0 broadcast 192.168.0.255 network 192.168.0.0 bridge_ports eth3 bridge_stp off bridge_maxwait 5 gateway 192.168.0.1 up ip route add 192.168.0.0/24 via 192.168.0.26 up ip route add 192.168.0.0/24 dev br04 .vmdk >> .img DISK変換
実運用中のVMware-server2の仮想DISKイメージから、KVMで実行できるRAW?DISKイメージに変換する。 以下を、変換するDISK毎に実行。
4-1 VMDKの結合
最大2GBまでに分割された複数DISKを結合するVMwareコマンド。
sudo vmware-vdiskmanager -r /Virtual/test/root.vmdk -t 0 /Virtual/root-con.vmdk
4-2 VMDk >> RAW DISK
sudo qemu-img convert root-con.vmdk root.img
5 起動コマンド
5-2 起動！
元々、/homeディレクトリを分離させているので、 「root.img」「home.img」の２つのディスクを指定する必要がある。
- ゲストOSのCPUを１コアで起動の場合
sudo kvm -m 1024 -hda root.img -hdb home.img -boot c -net nic -net tap,script=/etc/kvm/kvm-ifup -daemonize -localtime
- ゲストOSのCPUを２コアで起動の場合
sudo kvm -m 1024 -smp 2 -hda root.img -hdb home.img -boot c -net nic -net tap,script=/etc/kvm/kvm-ifup -daemonize -localtime
- ２コアのCPUに対して１コア設定だと、実際に消費されるホストＯＳのＣＰＵパワーも１コア分だけみたい。よって２コア設定（-smp 2）を推奨。（ホストＯＳのシステムモニタで確認済み）
このあたりの挙動は、１コア設定でもホスト２コアをフルに使ってくれたVMware-serverの場合と異なるので、要注意。 （２コア設定にしたら却って遅くなったりしていた。）
- ２コアのCPUに対して１コア設定だと、実際に消費されるホストＯＳのＣＰＵパワーも１コア分だけみたい。よって２コア設定（-smp 2）を推奨。（ホストＯＳのシステムモニタで確認済み）
なお、初回起動時にDISKのデバイス名違いで途中で止まった場合は、そこでルートログインし、「/etc/fstab」内を編集する。 例えば、「/dev/sda」＞＞「/dev/hda」など。
6 速度比較
期待した速度ですが、http上のXoopsCubeLegacyの動作速度は、稼動中のVMware-server2と同等ですし、仮想OS内のファイルコピーでも、有意な差は認められません。
- 方法
最大500MBバイト、最小11MBほどのgzファイルを計７つ、合計750MBほどのファイルを、SSHログインで一度にコピー。開始?完了の間の時間を計測。
- マシンＡ：（CPU）AMD AthronX2-3800+(65W)（2GHz）
仮想OSの割り当てメモリ：２GBマシン 実行時間 ホストＯＳ（ubuntu8.10）１回目 34秒 ホストＯＳ（ubuntu8.10）２回目 20秒 KVM（Vine4.2）１回目 55秒 KVM（Vine4.2）２回目 6秒
- マシンＢ：（CPU）AMD AthronX2-4850e(45W)（2.5GHz）
仮想OSの割り当てメモリ：１GB（実運用中のホストOS側ファイルを元に使ったので、１回目は計測できず。）マシン 実行時間 ホストＯＳ（ubuntu8.10）２回目 15秒 VMware-server2（Vine4.2）１回目 45秒 VMware-server2（Vine4.2）２回目 26秒
マシンＡのほうがCPU速度が遅いのですが、その割りにKVMの速度低下の割合は小さいですね。 キャッシュが効く２回目はとても速いですし。 ただ、すぐに乗り換えるほどでは無いという気もします。
- ゲストOSのCPUを１コアで起動の場合