さて、これまで何度も、仮想マシンが動いているホストを shutdown させようとして、shutdown のハング→強制的に電源 Off/On を行うという事故をやらかしている。
であれば、ホスト停止時に、ゲストを自動的に shutdown させる仕組みを実装すればいいのではないか？
というわけで探してみる。
どうやら、ホスト側の /etc/default/libvirt-guests が鍵のようだ。
検証をしたいが、物理ホストを用いるのはちょっと危険。
従って、仮想マシンの gemini を再び使用することにする。
但し、 gemini 上で用意していた仮想マシン leo は、既に sagittarius / aquarius 側に移動させてしまっているので、gemini 上に戻すところからだ。
今回は、/mnt/iso-os という cifs 領域を、sagittarius / aquarius / gemini で共有しているので、そこを利用する。
(leo が稼働していたら事前に止めておこう。)
(sagittarius) $ cd /
(sagittarius) $ sudo tar cSjf /mnt/iso-os/leo.tbz \
var/lib/libvirt/images/leo.qcow2 \
var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ ls -l /mnt/iso-os/leo.tbz
(sagittarius) $ tar tvSjf /mnt/iso-os/leo.tbz
(sagittarius) $ cd
gemini 上に展開
(gemini) $ ls -l /var/lib/libvirt/images/leo.qcow2 \
/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(gemini) $ cd /
(gemini) $ sudo tar xSjf /mnt/iso-os/leo.tbz
(gemini) $ ls -l /var/lib/libvirt/images/leo.qcow2 \
/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(gemini) $ cd
(gemini) $ sudo rm /mnt/iso-os/leo.tbz
仮想ディスクの再認識
(gemini) $ virsh vol-list default
(gemini) $ virsh pool-refresh default
(gemini) $ virsh vol-list default
gemini へ leo を登録
(gemini) $ virsh list --all
(sagittarius) $ virsh dumpxml leo > leo.xml
(sagittarius) $ virsh -c qemu+ssh://(geminiのIP)/system \
define leo.xml
(gemini) $ virsh list --all
(sagittarius) $ rm leo.xml
sagittarius / aquarius から leo の定義を削除。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh undefine leo --nvram
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
(aquarius) $ sudo systemctl restart libvirt-bin.service
(reload ではダメで、やっぱり restart させる必要があるようだ。restart すると、ゲストOSが停止してしまうようなので、ちょっとやり方考えないといけないかな？この辺り、詳細は別途調査しよう。…あれ？restart でもゲストOS落ちないな…。以前落ちたことがあったんだけど…。)
(aquarius) $ virsh list --all
(sagittairus) $ virsh vol-list default
(sagittairus) $ virsh vol-delete leo.qcow2 default
(sagittairus) $ virsh vol-list default
(aquarius) $ virsh vol-list default
(aquarius) $ virsh pool-refresh default
(aquarius) $ virsh vol-list default
これで、leo を gemini 上に移動させることが出来た。
では、/etc/default/libvirt-guests を編集してみよう。
(gemini) $ sudo vi /etc/default/libvirt-guests
--ココから
25行目付近
#ON_SHUTDOWN=shutdown
↓
ON_SHUTDOWN=shutdown
--ココまで
あと、そもそもゲスト側で acpi が有効になっていて、acpid が稼働している必要があるらしい。
(gemini) $ virsh dumpxml leo | grep acpi
<acpi/>が出力されればOKだ。
leo で acpid が稼働しているかは、leo を起動、ログインして確認する必要がある。
(gemini) $ virsh start leo
(leo) $ systemctl status acpid
(もし acpid が稼働していなければ、インストール・起動しておこう)
まずは、gemini から普通にシャットダウン等出来るかを確認。
(virt-viewer を使うので、端末側で X が動くようにしておくこと。)
(gemini) $ virt-viewer leo &
(gemini) $ virsh shutdown leo
普通にシャットダウンメッセージが出た。
あと、電源管理機能も使っておきたいので、leo の定義で suspend to mem と suspend to disk も有効化しておきたい。
(gemini) $ virsh edit leo
--ココから
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
↓
<pm>
<suspend-to-mem enabled='yes'/>
<suspend-to-disk enabled='yes'/>
</pm>
--ココまで
では、ホスト側から、ゲストに対して電源管理機能を使用した suspend を。
(gemini) $ virt-viewer leo &
(gemini) $ virsh start leo
(gemini) $ virsh dompmsuspend leo --target disk
おっと？「エラー: サポートされない引数: QEMU ゲストエージェントが設定されていません」って表示されてエラーになった。
ゲストOS(leo)に、qemu-guest-agent を導入する必要があるらしいな…。
入れてみるか。
(leo) $ sudo apt-get update
(leo) $ sudo apt-get install qemu-guest-agent
う～ん。コレだけではダメで、仮想マシン定義に serial の設定を施す必要があるようだ。
pmsuspend は置いておいて、後日調査だな…。
とりあえず、ホスト側からシャットダウンさせることは出来たので、本題に戻って、ゲスト(leo)が起動しているまま、ホスト(gemini)をシャットダウンさせてみよう。
(gemini) $ virsh list --all
(gemini) $ sudo systemctl poweroff
上手く行ったのだろうか…。
gemini を起動して確認してみよう。
(sagittarius) $ virt-viewer gemini &
(sagittarius) $ virsh start gemini
gemini の起動時にエラーっぽいものは無かったな。
次いで leo を。
(gemini) $ virsh list --all
(gemini) $ virt-viewer leo &
(gemini) $ virsh start leo
こちらも見た感じ、特に問題は無さそうだ。
ホストOS停止時に、ゲストOSを合わせて停止させる方法はこれで確立したかな？
次回は、pmsuspend をもう少しツッコんで見る。
2017年5月30日火曜日
続いて、autofs を sagittarius に
今回は、前回に引き続いて sagittarius 上に autofs を適用してみる。
但し、sagittarius 上で仮想マシンが稼働しているので、それのオンラインマイグレーションを実行した後に、だ。
早速、マイグレーションの実施。
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
(sagittarius) $ virsh \
migrate --live \
--domain (対象の仮想マシン名) \
--change-protection \
--desturi qemu+ssh://(aquariusのIP)/system \
--migrateuri tcp://(aquariusのIP)/ \
--verbose
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
おっと、スナップショットを持っている仮想マシンは、ライブマイグレーション出来ないんだった。
この辺り、libvirt の弱点だなぁ。
とりあえず、gemini がスナップショットを持っているため、ライブマイグレーション出来なかった。
gemini は一旦停止してから、aquarius にて起動する、という手順を踏む。
(と思ったけど、gemini は元々、CPU Mode を「host-mode」(物理 CPU と同構成)にしているから、CPU の世代が違う sagittarius ←→ aquarius 間でオンラインマイグレーションは出来ないんだった…)
ついでに、suspend to mem と suspend to disk を有効にしておこうかな…。
(gemini) $ sudo systemctl poweroff
(sagittarius) $ virsh list --all
(aquarius) $ virsh edit gemini
--ココから
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
↓yesに変更
<pm>
<suspend-to-mem enabled='yes'/>
<suspend-to-disk enabled='yes'/>
</pm>
--ココまで
(sagittarius) $ sudo systemctl restart libvirt-bin
(libvirt-bin を再起動すると、その上で稼働している仮想マシンが落ちる？なので、sagittairus 上で仮想マシンが全て停止していることを確認してから実施するように。)
(もしかしたら、 reload でいいのかも)
(aquarius) $ virsh start gemini
(aquarius) $ virsh list --all
sagittairus 上の仮想マシンが全て停止(aquarius 上で稼働)しているのが確認できたら、前回と同様の作業を実施。
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get install autofs
(sagittarius) $ sudo mkdir /etc/auto.master.d
(sagittarius) $ sudo vi /etc/auto.master.d/mnt.autofs
--ココから
/mnt /etc/auto.master.d/auto.mnt --timeout=60 --ghost
--ココまで
(sagittarius) $ sudo vi /etc/auto.master.d/auto.mnt
--ココから
iso-os -fstype=cifs,guest ://(NASのIP)/(共有フォルダ)
--ココまで
(sagittarius) $ sudo systemctl stop /mnt/iso-os
(sagittarius) $ sudo systemctl restart autofs
(sagittarius) $ df /mnt/iso-os
(sagittarius) $ ls /mnt/iso-os
(sagittarius) $ sleep 60
(sagittarius) $ df /mnt/iso-os
(sagittarius) $ sudo vi /etc/fstab
--fstab の当該行のコメント化(内容省略)
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ ls /mnt/iso-os
再起動後に確認が出来たら、仮想マシンは戻しておこう。
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
(aquarius) $ virsh \
migrate --live \
--domain (対象の仮想マシン名) \
--change-protection \
--desturi qemu+ssh://(sagittariusのIP)/system \
--migrateuri tcp://(sagittariusのIP)/ \
--verbose
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
gemini はスナップショットを持っているので、上記手順ではオンラインマイグレーション出来ない。(やり方があるのかも分からない)
当面は、ゲストOSのシャットダウン→反対側の物理マシン(今回は sagittarius )でゲストを起動、で逃げよう。
とりあえず、/mnt/iso-os を autofs 化するのはこれでオシマイ。
但し、sagittarius 上で仮想マシンが稼働しているので、それのオンラインマイグレーションを実行した後に、だ。
早速、マイグレーションの実施。
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
(sagittarius) $ virsh \
migrate --live \
--domain (対象の仮想マシン名) \
--change-protection \
--desturi qemu+ssh://(aquariusのIP)/system \
--migrateuri tcp://(aquariusのIP)/ \
--verbose
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
おっと、スナップショットを持っている仮想マシンは、ライブマイグレーション出来ないんだった。
この辺り、libvirt の弱点だなぁ。
とりあえず、gemini がスナップショットを持っているため、ライブマイグレーション出来なかった。
gemini は一旦停止してから、aquarius にて起動する、という手順を踏む。
(と思ったけど、gemini は元々、CPU Mode を「host-mode」(物理 CPU と同構成)にしているから、CPU の世代が違う sagittarius ←→ aquarius 間でオンラインマイグレーションは出来ないんだった…)
ついでに、suspend to mem と suspend to disk を有効にしておこうかな…。
(gemini) $ sudo systemctl poweroff
(sagittarius) $ virsh list --all
(aquarius) $ virsh edit gemini
--ココから
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
↓yesに変更
<pm>
<suspend-to-mem enabled='yes'/>
<suspend-to-disk enabled='yes'/>
</pm>
--ココまで
(sagittarius) $ sudo systemctl restart libvirt-bin
(libvirt-bin を再起動すると、その上で稼働している仮想マシンが落ちる？なので、sagittairus 上で仮想マシンが全て停止していることを確認してから実施するように。)
(もしかしたら、 reload でいいのかも)
(aquarius) $ virsh start gemini
(aquarius) $ virsh list --all
sagittairus 上の仮想マシンが全て停止(aquarius 上で稼働)しているのが確認できたら、前回と同様の作業を実施。
(sagittarius) $ sudo apt-get update
(sagittarius) $ sudo apt-get install autofs
(sagittarius) $ sudo mkdir /etc/auto.master.d
(sagittarius) $ sudo vi /etc/auto.master.d/mnt.autofs
--ココから
/mnt /etc/auto.master.d/auto.mnt --timeout=60 --ghost
--ココまで
(sagittarius) $ sudo vi /etc/auto.master.d/auto.mnt
--ココから
iso-os -fstype=cifs,guest ://(NASのIP)/(共有フォルダ)
--ココまで
(sagittarius) $ sudo systemctl stop /mnt/iso-os
(sagittarius) $ sudo systemctl restart autofs
(sagittarius) $ df /mnt/iso-os
(sagittarius) $ ls /mnt/iso-os
(sagittarius) $ sleep 60
(sagittarius) $ df /mnt/iso-os
(sagittarius) $ sudo vi /etc/fstab
--fstab の当該行のコメント化(内容省略)
(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl reboot
(sagittarius) $ ls /mnt/iso-os
再起動後に確認が出来たら、仮想マシンは戻しておこう。
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
(aquarius) $ virsh \
migrate --live \
--domain (対象の仮想マシン名) \
--change-protection \
--desturi qemu+ssh://(sagittariusのIP)/system \
--migrateuri tcp://(sagittariusのIP)/ \
--verbose
(sagittarius) $ virsh list --all
(aquarius) $ virsh list --all
gemini はスナップショットを持っているので、上記手順ではオンラインマイグレーション出来ない。(やり方があるのかも分からない)
当面は、ゲストOSのシャットダウン→反対側の物理マシン(今回は sagittarius )でゲストを起動、で逃げよう。
とりあえず、/mnt/iso-os を autofs 化するのはこれでオシマイ。
2017年5月24日水曜日
仮想マシンの共有領域への移動(稼働状態)
とりあえず、停止している仮想マシンを共有領域へ移動させることは完了した。
次は残っている稼働中の仮想マシンだ。
(前回 sagittarius からアンマウントしてしまった共有領域は、同じ場所にマウントしておこう。)
現在、稼働中の仮想マシンは以下の3つ。
そのため、本当に稼働中にオンラインで移行したいと思う。
ただ、既に移行は実績有りで、ココの後半の手順に従えばいい。
コマンドを実行するのは sagittarius からで変わらないが、From/To が逆になるため、若干コマンドオプションが変わってくるので注意だ。
(sagittarius) $ virsh \
migrate --live \
--domain (対象の仮想マシン名) \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://(aquariusのIP)/system \
--migrateuri tcp://(aquariusのIP)/ \
--verbose
これでいいはずだ。
残りの pegasus はメインで使っている環境で、ほぼ常時稼働させている。
また、ハードウェアを直接マッピングしているため、ハードウェア構成が異なる aquarius へは移行することが出来ない。(但し、そのハードウェアが無くても、ゲストOSとしては問題なく稼働する。)
そのため、仮想マシン停止→H/Wのマッピング解除→前回の手順でコールド移行→稼働確認 を行えばいい。
そんなに難しい話ではないので、サクッと実施しよう。
実施が終わったら、暫定でマウントしている /mnt/etc/libvirt と /mnt/var/lib/libvirt は外しておくこと。
これで全ての仮想マシンが、aqaurius 上の共有ボリューム上に移動できたはずだ。
次回は、sagittarius 上の不要ボリュームの整理等を行う。
次は残っている稼働中の仮想マシンだ。
(前回 sagittarius からアンマウントしてしまった共有領域は、同じ場所にマウントしておこう。)
現在、稼働中の仮想マシンは以下の3つ。
- pegasus : Windows7 環境
- 貸出1 : Ubuntu Linux環境
- 貸出2 : RedHat Enterprise Linux環境
そのため、本当に稼働中にオンラインで移行したいと思う。
ただ、既に移行は実績有りで、ココの後半の手順に従えばいい。
コマンドを実行するのは sagittarius からで変わらないが、From/To が逆になるため、若干コマンドオプションが変わってくるので注意だ。
(sagittarius) $ virsh \
migrate --live \
--domain (対象の仮想マシン名) \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://(aquariusのIP)/system \
--migrateuri tcp://(aquariusのIP)/ \
--verbose
これでいいはずだ。
残りの pegasus はメインで使っている環境で、ほぼ常時稼働させている。
また、ハードウェアを直接マッピングしているため、ハードウェア構成が異なる aquarius へは移行することが出来ない。(但し、そのハードウェアが無くても、ゲストOSとしては問題なく稼働する。)
そのため、仮想マシン停止→H/Wのマッピング解除→前回の手順でコールド移行→稼働確認 を行えばいい。
そんなに難しい話ではないので、サクッと実施しよう。
実施が終わったら、暫定でマウントしている /mnt/etc/libvirt と /mnt/var/lib/libvirt は外しておくこと。
これで全ての仮想マシンが、aqaurius 上の共有ボリューム上に移動できたはずだ。
次回は、sagittarius 上の不要ボリュームの整理等を行う。
仮想マシンの共有領域への移動(停止状態)
さて、ここまで環境が整ったら、sagittarius 上に配置してある仮想マシンを、共有領域へ配置し直す作業だ。
まずは、停止している環境から移行していく。
その前に、共有領域を sagittarius の一時領域へマウントしておく。
(sagittarius) $ sudo mkdir -p /mnt/etc/libvirt
(sagittarius) $ sudo mkdir -p /mnt/var/lib/libvirt
(sagittarius) $ sudo mount /dev/kvmcluster/etc-libvirt /mnt/etc/libvirt
(sagittarius) $ sudo mount /dev/kvmcluster/var-lib-libvirt /mnt/var/lib/libvirt
(sagittarius) $ df -h
マウントが確認できたら、各仮想マシンの仮想ディスクファイルと(あるのなら)nvramファイルのコピーだ。
以下に1例として、leo という名前の仮想マシン(仮想ディスクファイルは1つ)を移行するコマンドを書いておく。
(sagittarius) $ ls -l /etc/libvirt/qemu/leo.xml
(sagittairus) $ ls -l /var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ sudo ls -l /var/lib/libvirt/images/leo.qcow2
(sagittairus) $ sudo qemu-img info /var/lib/libvirt/images/leo.qcow2
(sagittarius) $ sudo cp -pi /var/lib/libvirt/qemu/nvram/leo_VARS.fd \
/mnt/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ sudo cp -pi --sparse=always \
/var/lib/libvirt/images/leo.qcow2 \
/mnt/var/lib/libvirt/images/leo.qcow2
(sagittarius) $ ls -l /mnt/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ ls -l /mnt/var/lib/libvirt/images/leo.qcow2
(sagittarius) $ sudo qemu-img info /mnt/var/lib/libvirt/images/leo.qcow2
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system vol-list default
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system pool-refresh default
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system vol-list default
必要なファイルがコピーできたら、aquarius 上に当該仮想マシンを登録する。
前回は構成ファイルをダンプした後、相手方にコピー、としてたが、今回は手抜きで実施してみる。
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system list --all
(sagittarius) $ virsh dumpxml leo > leo.xml
(sagittairus) $ virsh -c qemu+ssh://(aquariusのIP)/system \
define leo.xml
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system list --all
(sagittarius) $ rm leo.xml
これで、aquarius 上で leo が動かせるはずだ。
＃スナップショットを使っているマシンは、 /var/lib/libvirt/qemu/snapshot の下にもファイルがあるかもしれない。合わせてコピーしておこう。
#スナップショットの定義もコピーした場合、aquarius 側の libvirt-bin.service は再起動させないと、スナップショット情報が反映されないので要注意。
簡単な動作確認をしてみて欲しい。
…と思ったが、leo は aquarius の上で動かすことが出来なかった。
leo の CPU モデルは Broadwell にしていて第5世代の Intel core に合わせていたはずなのだが、一部機能(rtm,hle)が使えない、とのことで、Broadwell-noTSX を使ってみよ、とのことだった。
CPU モデルを Broadwell-noTSX に変更して稼働させたら、どうやら上手く動いたようだ。
第6世代と第5世代を使っているので、両方で稼働可能な CPU というのは意識しておく必要がありそうだ。
動作確認が終わったら、 sagittarius 上から leo を削除する。
(sagittarius) $ virsh list --all
(sagittairus) $ virsh undefine leo --nvram
(sagittarius) $ virsh list --all
(sagittarius) $ virsh vol-list default
(sagittarius) $ virsh vol-delete leo.qcow2 default
(sagittarius) $ virsh vol-list default
(sagittarius) $ ls -l /etc/libvirt/qemu/leo.xml
(sagittairus) $ ls -l /var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ sudo ls -l /var/lib/libvirt/images/leo.qcow2
これで、停止している仮想マシンの移行は完了だ。
＃スナップショットを持っている環境は、削除がちょっと手間のようだ。virt-manager を使って削除したほうが簡単かもしれない。
存在している仮想マシンのうち、停止している各仮想マシンは同じ手順で移行しておくこと。
また、/var/lib/libvirt の領域不足になると思うので、都度前回の手順で拡張しよう。
移行が終わったら、暫定的にマウントした領域は解除する。
(sagittarius) $ sudo umount /mnt/etc/libvirt
(sagittarius) $ sudo umount /mnt/var/lib/libvirt
(sagittarius) $ sudo df
次回は、稼働中のマシンの移行を行う。
まずは、停止している環境から移行していく。
その前に、共有領域を sagittarius の一時領域へマウントしておく。
(sagittarius) $ sudo mkdir -p /mnt/etc/libvirt
(sagittarius) $ sudo mkdir -p /mnt/var/lib/libvirt
(sagittarius) $ sudo mount /dev/kvmcluster/etc-libvirt /mnt/etc/libvirt
(sagittarius) $ sudo mount /dev/kvmcluster/var-lib-libvirt /mnt/var/lib/libvirt
(sagittarius) $ df -h
マウントが確認できたら、各仮想マシンの仮想ディスクファイルと(あるのなら)nvramファイルのコピーだ。
以下に1例として、leo という名前の仮想マシン(仮想ディスクファイルは1つ)を移行するコマンドを書いておく。
(sagittarius) $ ls -l /etc/libvirt/qemu/leo.xml
(sagittairus) $ ls -l /var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ sudo ls -l /var/lib/libvirt/images/leo.qcow2
(sagittairus) $ sudo qemu-img info /var/lib/libvirt/images/leo.qcow2
(sagittarius) $ sudo cp -pi /var/lib/libvirt/qemu/nvram/leo_VARS.fd \
/mnt/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ sudo cp -pi --sparse=always \
/var/lib/libvirt/images/leo.qcow2 \
/mnt/var/lib/libvirt/images/leo.qcow2
(sagittarius) $ ls -l /mnt/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ ls -l /mnt/var/lib/libvirt/images/leo.qcow2
(sagittarius) $ sudo qemu-img info /mnt/var/lib/libvirt/images/leo.qcow2
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system vol-list default
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system pool-refresh default
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system vol-list default
必要なファイルがコピーできたら、aquarius 上に当該仮想マシンを登録する。
前回は構成ファイルをダンプした後、相手方にコピー、としてたが、今回は手抜きで実施してみる。
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system list --all
(sagittarius) $ virsh dumpxml leo > leo.xml
(sagittairus) $ virsh -c qemu+ssh://(aquariusのIP)/system \
define leo.xml
(sagittarius) $ virsh -c qemu+ssh://(aquariusのIP)/system list --all
(sagittarius) $ rm leo.xml
これで、aquarius 上で leo が動かせるはずだ。
＃スナップショットを使っているマシンは、 /var/lib/libvirt/qemu/snapshot の下にもファイルがあるかもしれない。合わせてコピーしておこう。
#スナップショットの定義もコピーした場合、aquarius 側の libvirt-bin.service は再起動させないと、スナップショット情報が反映されないので要注意。
簡単な動作確認をしてみて欲しい。
…と思ったが、leo は aquarius の上で動かすことが出来なかった。
leo の CPU モデルは Broadwell にしていて第5世代の Intel core に合わせていたはずなのだが、一部機能(rtm,hle)が使えない、とのことで、Broadwell-noTSX を使ってみよ、とのことだった。
CPU モデルを Broadwell-noTSX に変更して稼働させたら、どうやら上手く動いたようだ。
第6世代と第5世代を使っているので、両方で稼働可能な CPU というのは意識しておく必要がありそうだ。
動作確認が終わったら、 sagittarius 上から leo を削除する。
(sagittarius) $ virsh list --all
(sagittairus) $ virsh undefine leo --nvram
(sagittarius) $ virsh list --all
(sagittarius) $ virsh vol-list default
(sagittarius) $ virsh vol-delete leo.qcow2 default
(sagittarius) $ virsh vol-list default
(sagittarius) $ ls -l /etc/libvirt/qemu/leo.xml
(sagittairus) $ ls -l /var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ sudo ls -l /var/lib/libvirt/images/leo.qcow2
これで、停止している仮想マシンの移行は完了だ。
＃スナップショットを持っている環境は、削除がちょっと手間のようだ。virt-manager を使って削除したほうが簡単かもしれない。
存在している仮想マシンのうち、停止している各仮想マシンは同じ手順で移行しておくこと。
また、/var/lib/libvirt の領域不足になると思うので、都度前回の手順で拡張しよう。
移行が終わったら、暫定的にマウントした領域は解除する。
(sagittarius) $ sudo umount /mnt/etc/libvirt
(sagittarius) $ sudo umount /mnt/var/lib/libvirt
(sagittarius) $ sudo df
次回は、稼働中のマシンの移行を行う。
2017年5月19日金曜日
aquarius 上の仮想マシンを sagittarius へ
では、aquarius 上の仮想マシンを、 sagittarius 上へ移動させる。
そろそろ、 sagittarius の仮想マシン領域が枯渇し始めているのではないだろうか？
必要に応じて拡張しておいて欲しい。
さて、aquarius だが、こちらには aries / pisces という2つの仮想マシンの他に、急遽必要になった環境が2つ存在している。
(別件で必要になったもののため、一連の blog には一切記載していない。)
aries / pisces はともに停止状態のため、前回と同様に手作業で移動させる。
問題は、追加の2環境だ。
こちらは稼動状態。いつ使われるか分からないので、出来ればオンラインを維持したい。
幸いにして、こちらの2環境は、仮想ディスク20GBを2つずつ、合計80GB分なので、フルコピー状態でも何とかなるだろう。
そのため、前々回のオンラインマイグレーションを実施してみる。
まずは aries / pisces から。
こちらは uEFI 環境ではないので、*_VARS.fd ファイルは存在しない。
aries 開始(aries と pisces で差異があるところは下線を引いた)
(aquarius) $ virsh dumpxml aries > /tmp/aries.xml
ファイルのアーカイブ
(ディスクの使用量に注意しよう。)
(aquarius) $ cd /
(aquarius) $ sudo tar cSjf /tmp/aries.tbz \
tmp/aries.xml \
var/lib/libvirt/images/aries.qcow2
(aquarius) $ ls -l /tmp/aries.tbz
(aquarius) $ tar tvSjf /tmp/aries.tbz
(aquarius) $ rm /tmp/aries.xml
(aquarius) $ cd
ファイルを sagittarius で取得
(空き容量に注意)
(sagittarius) $ scp (ユーザ名)@(aquariusのIPアドレス):/tmp/aries.tbz \
/tmp/aries.tbz
(sagittarius) $ ls -l /tmp/aries.tbz
(aquarius) $ sudo rm /tmp/aries.tbz
sagittarius 上に展開
(sagittarius) $ ls -l /var/lib/libvirt/images/aries.qcow2
(sagittarius) $ cd /
(sagittarius) $ sudo tar xSjf /tmp/aries.tbz
(sagittarius) $ ls -l /var/lib/libvirt/images/aries.qcow2
(sagittarius) $ cd
仮想ディスクの再認識
(sagittarius) $ virsh vol-list default
(sagittarius) $ virsh pool-refresh default
(sagittarius) $ virsh vol-list default
sagittarius へ aries を登録
(sagittarius) $ ls -l /etc/libvirt/qemu
(sagittarius) $ virsh list --all
(sagittarius) $ virsh define /tmp/aries.xml
(sagittarius) $ virsh list --all
(sagittarius) $ ls -l /etc/libvirt/qemu
起動や動作確認を実施。
動作確認が出来たら余計なファイルを削除
(sagittarius) $ rm /tmp/aries.tbz
(sagittarius) $ rm /tmp/aries.xml
また、aquarius からも aries の定義を消す。
(aquarius) $ virsh list --all
(aquarius) $ virsh undefine aries --nvram
(aquarius) $ virsh list --all
(aquarius) $ ls /etc/libvirt/qemu
(aquarius) $ virsh vol-list default
(aquarius) $ virsh vol-delete aries.qcow2 default
(aquarius) $ virsh vol-list default
aries 終わり。(pisces も同様に実施する。)
ココからは、残りの2環境のオンラインマイグレーション
詳細は抜いて、簡単にオペレーションとコマンドだけ書いておくことにする。
virt-manager を使用して、対象のゲストOSが使用している仮想ディスクのパス、名前、サイズを確認。
sagittarius 上の同じ場所に、同じサイズ、同じ名前で仮想ディスクを作っておくこと。
移行コマンドはざっくりこんな感じ。
(sagittarius) $ virsh -c qemu+ssh://(aqauariusのIP)/system \
migrate --live \
--domain (対象の仮想マシン名) \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://(sagittariusのIP)/system \
--migrateuri tcp://(sagittariusのIP)/ \
--verbose
1環境あたり、20GBの仮想ディスクが2つ(40GB)、大体18分程度で移行が出来た模様。
aquarius 側、仮想ディスクが残ってしまっているので、不要なら削除しておこう。
(virt-manager から削除するのが簡単だ。)
あと、過去に弄った時のゴミファイルが、何故か /var/lib/libvirt/qemu/nvram に残っていたので、不要なら削除してこう。
これで、aquarius 上の仮想環境が空っぽになったぞ。
次は、aquarius に共有用のボリュームを作成するところだ。
そろそろ、 sagittarius の仮想マシン領域が枯渇し始めているのではないだろうか？
必要に応じて拡張しておいて欲しい。
さて、aquarius だが、こちらには aries / pisces という2つの仮想マシンの他に、急遽必要になった環境が2つ存在している。
(別件で必要になったもののため、一連の blog には一切記載していない。)
aries / pisces はともに停止状態のため、前回と同様に手作業で移動させる。
問題は、追加の2環境だ。
こちらは稼動状態。いつ使われるか分からないので、出来ればオンラインを維持したい。
幸いにして、こちらの2環境は、仮想ディスク20GBを2つずつ、合計80GB分なので、フルコピー状態でも何とかなるだろう。
そのため、前々回のオンラインマイグレーションを実施してみる。
まずは aries / pisces から。
こちらは uEFI 環境ではないので、*_VARS.fd ファイルは存在しない。
aries 開始(aries と pisces で差異があるところは下線を引いた)
(aquarius) $ virsh dumpxml aries > /tmp/aries.xml
ファイルのアーカイブ
(ディスクの使用量に注意しよう。)
(aquarius) $ cd /
(aquarius) $ sudo tar cSjf /tmp/aries.tbz \
tmp/aries.xml \
var/lib/libvirt/images/aries.qcow2
(aquarius) $ ls -l /tmp/aries.tbz
(aquarius) $ tar tvSjf /tmp/aries.tbz
(aquarius) $ rm /tmp/aries.xml
(aquarius) $ cd
ファイルを sagittarius で取得
(空き容量に注意)
(sagittarius) $ scp (ユーザ名)@(aquariusのIPアドレス):/tmp/aries.tbz \
/tmp/aries.tbz
(sagittarius) $ ls -l /tmp/aries.tbz
(aquarius) $ sudo rm /tmp/aries.tbz
sagittarius 上に展開
(sagittarius) $ ls -l /var/lib/libvirt/images/aries.qcow2
(sagittarius) $ cd /
(sagittarius) $ sudo tar xSjf /tmp/aries.tbz
(sagittarius) $ ls -l /var/lib/libvirt/images/aries.qcow2
(sagittarius) $ cd
仮想ディスクの再認識
(sagittarius) $ virsh vol-list default
(sagittarius) $ virsh pool-refresh default
(sagittarius) $ virsh vol-list default
sagittarius へ aries を登録
(sagittarius) $ ls -l /etc/libvirt/qemu
(sagittarius) $ virsh list --all
(sagittarius) $ virsh define /tmp/aries.xml
(sagittarius) $ virsh list --all
(sagittarius) $ ls -l /etc/libvirt/qemu
起動や動作確認を実施。
動作確認が出来たら余計なファイルを削除
(sagittarius) $ rm /tmp/aries.tbz
(sagittarius) $ rm /tmp/aries.xml
また、aquarius からも aries の定義を消す。
(aquarius) $ virsh list --all
(aquarius) $ virsh undefine aries --nvram
(aquarius) $ virsh list --all
(aquarius) $ ls /etc/libvirt/qemu
(aquarius) $ virsh vol-list default
(aquarius) $ virsh vol-delete aries.qcow2 default
(aquarius) $ virsh vol-list default
aries 終わり。(pisces も同様に実施する。)
ココからは、残りの2環境のオンラインマイグレーション
詳細は抜いて、簡単にオペレーションとコマンドだけ書いておくことにする。
virt-manager を使用して、対象のゲストOSが使用している仮想ディスクのパス、名前、サイズを確認。
sagittarius 上の同じ場所に、同じサイズ、同じ名前で仮想ディスクを作っておくこと。
移行コマンドはざっくりこんな感じ。
(sagittarius) $ virsh -c qemu+ssh://(aqauariusのIP)/system \
migrate --live \
--domain (対象の仮想マシン名) \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://(sagittariusのIP)/system \
--migrateuri tcp://(sagittariusのIP)/ \
--verbose
1環境あたり、20GBの仮想ディスクが2つ(40GB)、大体18分程度で移行が出来た模様。
aquarius 側、仮想ディスクが残ってしまっているので、不要なら削除しておこう。
(virt-manager から削除するのが簡単だ。)
あと、過去に弄った時のゴミファイルが、何故か /var/lib/libvirt/qemu/nvram に残っていたので、不要なら削除してこう。
これで、aquarius 上の仮想環境が空っぽになったぞ。
次は、aquarius に共有用のボリュームを作成するところだ。
2017年5月18日木曜日
leo を sagittarius へ(オフラインマイグレーション)
じゃぁオフラインではどうだ？
ということで実際に実行してみた。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --offline \
--domain leo \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://192.168.55.130/system \
--migrateuri tcp://192.168.55.130/ \
--verbose
エラー: 要求された操作は有効ではありません: オフラインマイグレーションが非共有ストレージを取り扱えません
はい、エラーになりました。
何だよ…非共有ストレージだと、オフラインマイグレーションは出来ないのかよ…。
書いてあった…。
Currently, copying non-shared storage or other file based storages (e.g. UEFI variable storage) is not supported during offline migration.
はい、終了…。
しかしコレでは、全く目的が達成できない。
なので、力技を使うことにする。
もし、leo がまだ起動状態だったら、停止しておいて欲しい。
で、gemini 上で leo を構成するファイルは以下の 5つだ。
(仮想ディスクを多く割り当てていれば、その分 qcow2 ファイル等が増えるぞ。)
この内の上3つ分が、最低限必要なファイルになる。
「力技」と言ったのは、この3つのファイルを gemini から取り出して、sagittarius の同じ場所に再配置する、という意味だ。
但し、1つ目のファイルは virsh コマンドで取得＆virsh コマンドで取り込み、が正しい手順なので、それに従うことにする。
gemini で構成情報ファイルの作成
(gemini) $ virsh dumpxml leo > /tmp/leo.xml
ファイルのアーカイブ
(ディスクの使用量に注意しよう。)
(gemini) $ cd /
(gemini) $ sudo tar cSjf /tmp/leo.tbz \
tmp/leo.xml \
var/lib/libvirt/images/leo.qcow2 \
var/lib/libvirt/qemu/nvram/leo_VARS.fd
(gemini) $ ls -l /tmp/leo.tbz
(gemini) $ tar tvSjf /tmp/leo.tbz
(gemini) $ rm /tmp/leo.xml
(gemini) $ cd
ファイルを sagittarius で取得
(空き容量に注意)
(sagittarius) $ scp (ユーザ名)@(geminiのIPアドレス):/tmp/leo.tbz \
/tmp/leo.tbz
(sagittarius) $ ls -l /tmp/leo.tbz
(gemini) $ sudo rm /tmp/leo.tbz
sagittarius 上に展開
(sagittarius) $ ls -l /var/lib/libvirt/images/leo.qcow2 \
/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ cd /
(sagittarius) $ sudo tar xSjf /tmp/leo.tbz
(sagittarius) $ ls -l /var/lib/libvirt/images/leo.qcow2 \
/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ cd
仮想ディスクの再認識
(sagittarius) $ virsh vol-list default
(sagittarius) $ virsh pool-refresh default
(sagittarius) $ virsh vol-list default
sagittarius へ leo を登録
(sagittarius) $ ls -l /etc/libvirt/qemu
(sagittarius) $ virsh list --all
(sagittarius) $ virsh define /tmp/leo.xml
(sagittarius) $ virsh list --all
(sagittarius) $ ls -l /etc/libvirt/qemu
これで移行完了のはずだ。
実際に起動や動作確認してみて欲しい。
動作確認が出来たら余計なファイルを削除
(sagittarius) $ rm /tmp/leo.tbz
(sagittarius) $ rm /tmp/leo.xml
また、gemini / cancer からも leo の定義を消しておこう。
(gemini) $ virsh list --all
(gemini) $ virsh undefine leo --nvram
(gemini) $ virsh list --all
(gemini) $ ls /etc/libvirt/qemu
(cancer) $ virsh list --all
(cancer) $ virsh undefine leo --nvram
(cancer) $ virsh list --all
(gemini) $ virsh vol-list default
(gemini) $ virsh vol-delete leo.qcow2 default
(gemini) $ virsh vol-list default
(cancer) $ virsh vol-list default
(cancer) $ virsh pool-refresh default
(cancer) $ virsh vol-list default
これでごみ処理も終わりだ。
この方式なら確実に移行出来るが、メリット・デメリットがある。
メリット
ということで実際に実行してみた。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --offline \
--domain leo \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://192.168.55.130/system \
--migrateuri tcp://192.168.55.130/ \
--verbose
エラー: 要求された操作は有効ではありません: オフラインマイグレーションが非共有ストレージを取り扱えません
はい、エラーになりました。
何だよ…非共有ストレージだと、オフラインマイグレーションは出来ないのかよ…。
書いてあった…。
Currently, copying non-shared storage or other file based storages (e.g. UEFI variable storage) is not supported during offline migration.
はい、終了…。
しかしコレでは、全く目的が達成できない。
なので、力技を使うことにする。
もし、leo がまだ起動状態だったら、停止しておいて欲しい。
で、gemini 上で leo を構成するファイルは以下の 5つだ。
- /etc/libvirt/qemu/leo.xml
- /var/lib/libvirt/images/leo.qcow2
- /var/lib/libvirt/qemu/nvram/leo_VARS.fd
- /var/log/libvirt/qemu/leo.log
- /var/log/libvirt/qemu/leo.log.1
(仮想ディスクを多く割り当てていれば、その分 qcow2 ファイル等が増えるぞ。)
この内の上3つ分が、最低限必要なファイルになる。
「力技」と言ったのは、この3つのファイルを gemini から取り出して、sagittarius の同じ場所に再配置する、という意味だ。
但し、1つ目のファイルは virsh コマンドで取得＆virsh コマンドで取り込み、が正しい手順なので、それに従うことにする。
gemini で構成情報ファイルの作成
(gemini) $ virsh dumpxml leo > /tmp/leo.xml
ファイルのアーカイブ
(ディスクの使用量に注意しよう。)
(gemini) $ cd /
(gemini) $ sudo tar cSjf /tmp/leo.tbz \
tmp/leo.xml \
var/lib/libvirt/images/leo.qcow2 \
var/lib/libvirt/qemu/nvram/leo_VARS.fd
(gemini) $ ls -l /tmp/leo.tbz
(gemini) $ tar tvSjf /tmp/leo.tbz
(gemini) $ rm /tmp/leo.xml
(gemini) $ cd
ファイルを sagittarius で取得
(空き容量に注意)
(sagittarius) $ scp (ユーザ名)@(geminiのIPアドレス):/tmp/leo.tbz \
/tmp/leo.tbz
(sagittarius) $ ls -l /tmp/leo.tbz
(gemini) $ sudo rm /tmp/leo.tbz
sagittarius 上に展開
(sagittarius) $ ls -l /var/lib/libvirt/images/leo.qcow2 \
/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ cd /
(sagittarius) $ sudo tar xSjf /tmp/leo.tbz
(sagittarius) $ ls -l /var/lib/libvirt/images/leo.qcow2 \
/var/lib/libvirt/qemu/nvram/leo_VARS.fd
(sagittarius) $ cd
仮想ディスクの再認識
(sagittarius) $ virsh vol-list default
(sagittarius) $ virsh pool-refresh default
(sagittarius) $ virsh vol-list default
sagittarius へ leo を登録
(sagittarius) $ ls -l /etc/libvirt/qemu
(sagittarius) $ virsh list --all
(sagittarius) $ virsh define /tmp/leo.xml
(sagittarius) $ virsh list --all
(sagittarius) $ ls -l /etc/libvirt/qemu
これで移行完了のはずだ。
実際に起動や動作確認してみて欲しい。
動作確認が出来たら余計なファイルを削除
(sagittarius) $ rm /tmp/leo.tbz
(sagittarius) $ rm /tmp/leo.xml
また、gemini / cancer からも leo の定義を消しておこう。
(gemini) $ virsh list --all
(gemini) $ virsh undefine leo --nvram
(gemini) $ virsh list --all
(gemini) $ ls /etc/libvirt/qemu
(cancer) $ virsh list --all
(cancer) $ virsh undefine leo --nvram
(cancer) $ virsh list --all
(gemini) $ virsh vol-list default
(gemini) $ virsh vol-delete leo.qcow2 default
(gemini) $ virsh vol-list default
(cancer) $ virsh vol-list default
(cancer) $ virsh pool-refresh default
(cancer) $ virsh vol-list default
これでごみ処理も終わりだ。
この方式なら確実に移行出来るが、メリット・デメリットがある。
メリット
- カスタマイズの自由度
仮想マシン定義ファイル(xmlファイル)を取り込む前に、そのファイルをカスタマイズすることで、構成が異なる仮想マシンとして取り込むことが可能になる。
- 移行対象ファイルの抜け漏れのリスク
気をつけないと抜け漏れが発生する。 - 停止時間が延びてしまう
移行開始から移行終了までの時間が長く、途中で切ることが出来ない。
(連続停止時間が長い)
業務用途の場合は、この停止時間がビジネス的に致命傷になりかねない。
その場合は、ディスクの使用効率が悪くなってでも、オンラインストレージマイグレーションを実施するようにすべき。
オンラインマイグレーションなら、停止時間はほぼゼロだからだ。
leo を sagittarius へ(ストレージマイグレーション)
さて、では実際に leo を sagittarius へ移動させてみよう。
…と検証をしていたのだが、問題にぶち当たった。(マタカヨ…)
leo の仮想ディスクは sparse 形式を使用しており、ホスト(gemini)から見ると、実際に使用された量のみが消費される。
現在、leo には 72GB の仮想ディスクを割り当てているが、leo 側で 3GB弱しか使用していないため、gemini から見ると 3GB しかディスク領域が消費されていない状態だ。
(gemini) $ virsh vol-info leo.qcow2 default
名前: leo.qcow2
タイプ: ファイル
容量: 72.00 GiB
割り当て: 2.91 GiB
(gemini) $ sudo qemu-img info /var/lib/libvirt/images/leo.qcow2
image: /var/lib/libvirt/images/leo.qcow2
file format: qcow2
virtual size: 72G (77309411328 bytes)
disk size: 2.9G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
refcount bits: 16
corrupt: false
(gemini) $ sudo du /var/lib/libvirt/images/leo.qcow2
3047356 /var/lib/libvirt/images/leo.qcow2
しかし、オンラインでストレージマイグレーションを実行しようとすると、72GB分まるまるコピーされてしまい、コピー先(sagittarius)で 72GB消費されてしまうようだ。
ディスクの使用効率的に非常にもったいない。
業務用で、ディスクをふんだんに使える環境ならまだしも、個人用途なので sparse を維持したままマイグレーションしたい。
色々試してみたが、どうもダメなようだ。
そのため、
いずれも、leo を停止しないといけないため、後者のやり方を検討していく。
(前者は恐らく、移行後に leo を停止、対象ボリュームファイルに対して qemu-img convert を使用するのか、cp --spase=always か。)
とは言え、試してみたオンライン方式については、以下に記載する。
＃実際には途中で辞めたので、最後まで成功しているかどうかは不明。
まずは、leo の土台である gemini / cancer を起動。gemini 上で leo を起動させよう。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh start gemini
(sagittarius) $ virsh start cancer
(sagittarius) $ virsh list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system start leo
(sagittiarus) $ virsh -c qemu+ssh://192.168.55.136/system list --all
そのまま移動させようとすると、移動先の仮想ディスクの互換性が0.10になってしまうようだ。
移動元は互換性バージョン1.1なので、互換性レベルが下がってしまう(古いバージョンになってしまう)。
というわけで、先に移動先(sagittarius)で、空の仮想ディスクを作ってから移行する。
gemini で仮想ディスクの構成を確認する。
(gemini) $ virsh vol-dumpxml leo.qcow2 default
出力された内容を元に、sagittarius 上で xml ファイルを作成する。
(多分、幾つかのタグは初期設定では不要だと思われる。)
(sagittarius) $ vi leo.qcow2.xml
--ココから
<volume type='file'>
<name>leo.qcow2</name>
<key>/var/lib/libvirt/images/leo.qcow2</key>
<capacity unit='bytes'>77309411328</capacity>
<target>
<path>/var/lib/libvirt/images/leo.qcow2</path>
<format type='qcow2'/>
<permissions>
<mode>0600</mode>
</permissions>
<compat>1.1</compat>
<features>
<lazy_refcounts/>
</features>
</target>
</volume>
--ココまで
作成された xml ファイルを使って、仮想ディスクを作成する。
(sagittarius) $ virsh vol-create --pool default --file leo.qcow2.xml
(sagittarius) $ virsh vol-info leo.qcow2 default
(sagittarius) $ sudo qemu-img info /var/lib/libvirt/images/leo.qcow2
leo が起動したら、別途 teraterm を起動して、leo にログインし、ping を打つ等して放置だ。
(leo) $ ping 192.168.55.130
そしたら、gemini 上で稼働している leo を、sagittarius へ移動させてみる。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://192.168.55.130/system \
--migrateuri tcp://192.168.55.130/ \
--verbose
72G のディスクデータが丸っとコピーされるので、結構な時間がかかる。
＃実際には、この作業を途中で中断しているため、最後まで見届けていない。
多分コレで、マイグレーションは完了するだろう。
leo が継続稼働しているのが確認できたら、sagittarius から停止起動等を確認してみて欲しい。
オンラインストレージマイグレーションは、可能だけど制約がある、ということになったため、次回、オフラインマイグレーションに挑戦してみることにする。
＃しかし、オンラインストレージマイグレーションが出来ることを前提にしていたので、ちょっと厳しくなってきたな…。
＃多分、オフラインも同じ現象になりそうだな…。
…と検証をしていたのだが、問題にぶち当たった。(マタカヨ…)
leo の仮想ディスクは sparse 形式を使用しており、ホスト(gemini)から見ると、実際に使用された量のみが消費される。
現在、leo には 72GB の仮想ディスクを割り当てているが、leo 側で 3GB弱しか使用していないため、gemini から見ると 3GB しかディスク領域が消費されていない状態だ。
(gemini) $ virsh vol-info leo.qcow2 default
名前: leo.qcow2
タイプ: ファイル
容量: 72.00 GiB
割り当て: 2.91 GiB
(gemini) $ sudo qemu-img info /var/lib/libvirt/images/leo.qcow2
image: /var/lib/libvirt/images/leo.qcow2
file format: qcow2
virtual size: 72G (77309411328 bytes)
disk size: 2.9G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
refcount bits: 16
corrupt: false
(gemini) $ sudo du /var/lib/libvirt/images/leo.qcow2
3047356 /var/lib/libvirt/images/leo.qcow2
しかし、オンラインでストレージマイグレーションを実行しようとすると、72GB分まるまるコピーされてしまい、コピー先(sagittarius)で 72GB消費されてしまうようだ。
ディスクの使用効率的に非常にもったいない。
業務用で、ディスクをふんだんに使える環境ならまだしも、個人用途なので sparse を維持したままマイグレーションしたい。
色々試してみたが、どうもダメなようだ。
そのため、
- 移行後に leo を停止して sparse 形式へ変換
- leo を停止して、オフラインで移行
いずれも、leo を停止しないといけないため、後者のやり方を検討していく。
(前者は恐らく、移行後に leo を停止、対象ボリュームファイルに対して qemu-img convert を使用するのか、cp --spase=always か。)
とは言え、試してみたオンライン方式については、以下に記載する。
＃実際には途中で辞めたので、最後まで成功しているかどうかは不明。
まずは、leo の土台である gemini / cancer を起動。gemini 上で leo を起動させよう。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh start gemini
(sagittarius) $ virsh start cancer
(sagittarius) $ virsh list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system start leo
(sagittiarus) $ virsh -c qemu+ssh://192.168.55.136/system list --all
そのまま移動させようとすると、移動先の仮想ディスクの互換性が0.10になってしまうようだ。
移動元は互換性バージョン1.1なので、互換性レベルが下がってしまう(古いバージョンになってしまう)。
というわけで、先に移動先(sagittarius)で、空の仮想ディスクを作ってから移行する。
gemini で仮想ディスクの構成を確認する。
(gemini) $ virsh vol-dumpxml leo.qcow2 default
出力された内容を元に、sagittarius 上で xml ファイルを作成する。
(多分、幾つかのタグは初期設定では不要だと思われる。)
(sagittarius) $ vi leo.qcow2.xml
--ココから
<volume type='file'>
<name>leo.qcow2</name>
<key>/var/lib/libvirt/images/leo.qcow2</key>
<capacity unit='bytes'>77309411328</capacity>
<target>
<path>/var/lib/libvirt/images/leo.qcow2</path>
<format type='qcow2'/>
<permissions>
<mode>0600</mode>
</permissions>
<compat>1.1</compat>
<features>
<lazy_refcounts/>
</features>
</target>
</volume>
--ココまで
作成された xml ファイルを使って、仮想ディスクを作成する。
(sagittarius) $ virsh vol-create --pool default --file leo.qcow2.xml
(sagittarius) $ virsh vol-info leo.qcow2 default
(sagittarius) $ sudo qemu-img info /var/lib/libvirt/images/leo.qcow2
leo が起動したら、別途 teraterm を起動して、leo にログインし、ping を打つ等して放置だ。
(leo) $ ping 192.168.55.130
そしたら、gemini 上で稼働している leo を、sagittarius へ移動させてみる。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--persistent \
--undefinesource \
--compressed \
--copy-storage-all \
--change-protection \
--auto-converge \
--desturi qemu+ssh://192.168.55.130/system \
--migrateuri tcp://192.168.55.130/ \
--verbose
72G のディスクデータが丸っとコピーされるので、結構な時間がかかる。
＃実際には、この作業を途中で中断しているため、最後まで見届けていない。
多分コレで、マイグレーションは完了するだろう。
leo が継続稼働しているのが確認できたら、sagittarius から停止起動等を確認してみて欲しい。
オンラインストレージマイグレーションは、可能だけど制約がある、ということになったため、次回、オフラインマイグレーションに挑戦してみることにする。
＃しかし、オンラインストレージマイグレーションが出来ることを前提にしていたので、ちょっと厳しくなってきたな…。
＃多分、オフラインも同じ現象になりそうだな…。
2017年5月17日水曜日
ボリューム共有化の前に整理
最後に、sagittarius / aquarius 間で、仮想マシン領域を共有、という流れだけど、その前に今の構成を整理しておきたい。
今は、
分かりにくいので絵を描いてみる。
うむ。更に分かりにくいか…。
非常に混乱しそうな状況なのだが、これをマイグレーション機能等を行使しながら共有ボリューム化していきたいと思っている。
まずは leo を sagittarius へ。
仮想マシン on 仮想マシン の状態になっている leo を、sagittarius 上へ移動させたいと思う。
gemini / cancer と sagittarius はボリューム共有をしていないため、これまで試してきたライブマイグレーションは実施出来ないはずだ。
そのため、ディスク移動を含めたマイグレーション(leo稼動状態)を実施してみたい。
それがダメなら、leoを停止させた状態のオフラインマイグレーション、それでもダメなら、仮想マシン定義と仮想ディスクを手作業で移動、という方法。
ここで「ボリューム共有していないサーバ間での仮想マシンの移動」を身に着けておき、下の作業に応用する。
その後、aquarius 上に存在している仮想マシンを、全て sagittarius 上へ移動。
aquarius / sagittiarius 共有のボリュームを作成し、aquarius の単体ボリュームに残ったファイルをコピー、単体ボリュームを削除。
＃この時点では、 aquarius ではマウントするが、sagittairus ではマウントさせない
sagittarius 上に存在している仮想マシンを、全て aquarius 上に移動させる。
この作業で、仮想マシンの環境(仮想マシン定義、仮想マシンディスク)が全て共有ボリューム上に移動するはずだ。
この時、構成上マイグレーション不可能な仮想マシンが最低3つ存在している。
gemini / cancer / pegasus だ。
gemini / cancer は、CPU定義を「ホストCPUの設定をコピーする」にしていて、CPUのジェネレーションが違う sagittarius から aquarius へはオンラインでは移動出来ないはず。(sagittarius:第6世代Core i7、aquarius:第5世代Core i7)
これらは、仮想マシンを停止した状態でのマイグレーション(オフラインマイグレーション)は可能なはずで、移動後に aquarius で起動することも出来ると想定している。
pegasus はその設定上、物理マシン(sagittarius)の持つデバイスを、一部直接マッピングしている。aquarius はそのデバイスを持っていないので、移動出来ないはずだ。
オフラインでなら移動出来ると思うが、移動先(aquarius)では起動出来ないはずなので、予め sagittarius 上で当該デバイスを外しておくことにする。
sagittairus の単体ボリュームを切り離し、共有ボリュームをマウント。
幾つかの仮想マシンの動作テストを行う。
とまぁこんな感じで考えてみた。
実際に出来るかは分からないが、次回以降、この方向で進めていこうと思う。
今は、
- 物理マシンとして sagittarius / aquairus が稼働
- それぞれの上に複数の仮想マシンが稼働
- sagittarius 上の gemini / cancer はボリューム共有をしており、その上に更に仮想マシン(leo)が稼働
分かりにくいので絵を描いてみる。
 |
| 乱立した仮想マシン |
うむ。更に分かりにくいか…。
非常に混乱しそうな状況なのだが、これをマイグレーション機能等を行使しながら共有ボリューム化していきたいと思っている。
まずは leo を sagittarius へ。
仮想マシン on 仮想マシン の状態になっている leo を、sagittarius 上へ移動させたいと思う。
 |
| leoをsagittariusへ |
gemini / cancer と sagittarius はボリューム共有をしていないため、これまで試してきたライブマイグレーションは実施出来ないはずだ。
そのため、ディスク移動を含めたマイグレーション(leo稼動状態)を実施してみたい。
それがダメなら、leoを停止させた状態のオフラインマイグレーション、それでもダメなら、仮想マシン定義と仮想ディスクを手作業で移動、という方法。
ここで「ボリューム共有していないサーバ間での仮想マシンの移動」を身に着けておき、下の作業に応用する。
その後、aquarius 上に存在している仮想マシンを、全て sagittarius 上へ移動。
 |
| aquariusからsagittariusへ |
aquarius / sagittiarius 共有のボリュームを作成し、aquarius の単体ボリュームに残ったファイルをコピー、単体ボリュームを削除。
＃この時点では、 aquarius ではマウントするが、sagittairus ではマウントさせない
 |
| 共有ボリュームを作成 |
sagittarius 上に存在している仮想マシンを、全て aquarius 上に移動させる。
この作業で、仮想マシンの環境(仮想マシン定義、仮想マシンディスク)が全て共有ボリューム上に移動するはずだ。
 |
| sagittairusからaquariusへ |
この時、構成上マイグレーション不可能な仮想マシンが最低3つ存在している。
gemini / cancer / pegasus だ。
gemini / cancer は、CPU定義を「ホストCPUの設定をコピーする」にしていて、CPUのジェネレーションが違う sagittarius から aquarius へはオンラインでは移動出来ないはず。(sagittarius:第6世代Core i7、aquarius:第5世代Core i7)
これらは、仮想マシンを停止した状態でのマイグレーション(オフラインマイグレーション)は可能なはずで、移動後に aquarius で起動することも出来ると想定している。
pegasus はその設定上、物理マシン(sagittarius)の持つデバイスを、一部直接マッピングしている。aquarius はそのデバイスを持っていないので、移動出来ないはずだ。
オフラインでなら移動出来ると思うが、移動先(aquarius)では起動出来ないはずなので、予め sagittarius 上で当該デバイスを外しておくことにする。
sagittairus の単体ボリュームを切り離し、共有ボリュームをマウント。
幾つかの仮想マシンの動作テストを行う。
 |
| sagittairusの単体ボリュームを削除 |
とまぁこんな感じで考えてみた。
実際に出来るかは分からないが、次回以降、この方向で進めていこうと思う。
2017年5月9日火曜日
コマンドラインでのマイグレーション
前回までで、virt-manager を使ったオンラインマイグレーションが実施できた。
で、全然気付かなかったけど、virsh にもマイグレーションのオプションがあった。
ヘルプを見てみよう。(今回はヘルプの中身も引用しておく。)
(sagittarius) $ virsh help migrate
名前
migrate - ドメインの他ホストへのマイグレーション
形式
migrate <domain> <desturi> [--live] [--offline] [--p2p] [--direct] [--tunnelled] [--persistent] [--undefinesource] [--suspend] [--copy-storage-all] [--copy-storage-inc] [--change-protection] [--unsafe] [--verbose] [--compressed] [--auto-converge] [--rdma-pin-all] [--abort-on-error] [--migrateuri <string>] [--graphicsuri <string>] [--listen-address <string>] [--dname <string>] [--timeout <number>] [--xml <string>] [--migrate-disks <string>]
詳細
ドメインを他のホストにマイグレーションします。ライブマイグレーションは --live を付加します。
オプション
[--domain] <string> ドメインの名前、ID または UUID
[--desturi] <string> クライアント（通常のマイグレーション）またはソース（p2p マイグレーション）から見える宛先ホストの接続 URI
--live ライブマイグレーション
--offline オフラインマイグレーション
--p2p ピアツーピア・マイグレーション
--direct ダイレクト・マイグレーション
--tunnelled トンネル・マイグレーション
--persistent 宛先における仮想マシンの永続化
--undefinesource ソースから VM の登録解除
--suspend 宛先ホストにおいてドメインを再開しません
--copy-storage-all 完全なディスクコピーとともに非共有のストレージを用いたマイグレーション
--copy-storage-inc 増分コピーとともに非共有のストレージを用いたマイグレーション（ソースと宛先の間で同じベースイメージを共有します）
--change-protection ドメインへのあらゆる設定変更をマイグレーションが終わる まで防ぎます
--unsafe 安全ではないときにも強制的にマイグレーションする
--verbose マイグレーションの進行状況の表示
--compressed ライブマイグレーション中の連続ページの圧縮
--auto-converge force convergence during live migration
--rdma-pin-all support memory pinning during RDMA live migration
--abort-on-error 移行中にソフトなエラーが発生した場合は中止する
--migrateuri <string> マイグレーション URI（通常は省略可）
--graphicsuri <string> シームレス・グラフィック・マイグレーションのために使用するグラフィック URI
--listen-address <string> listen address that destination should bind to for incoming migration
--dname <string> マイグレーション中に名前の変更（サポートされる場合）
--timeout <number> ライブマイグレーションがタイムアウトするとゲストを強制的に一時停止する（秒単位）
--xml <string> ターゲットの更新した XML を含むファイル名
--migrate-disks <string> comma separated list of disks to be migrated
これを見ると、「一時的な移動」は --parsistent オプションと関係ありそうだ。(恐らく、--parsistent をつけない場合が、「一時的な移動」だろう。)
--undefinesource は、転送元から仮想マシン定義を削除する、ということかな？
オプションを見てみると、virt-manager では出来無さそうだった「ディスクが共有されていない環境でのマイグレーション」も出来そうだ。
何パターンも実装方法がありそうだが、とりあえずは今までやってた「共有環境でのオンラインマイグレーション」を考えてみる。
gemini で動いている leo を、cancer に移動するパターンは以下のようだ。
migrate --live \
--domain leo \
--desturi qemu+ssh://(cancerのIPアドレス)/system \
--migrateuri tcp://(cancerのIPアドレス)/
(cancer のホスト名 cancer が名前解決出来るのなら、恐らく --migrateuri は不要だ。その場合、--desturi も IPアドレスじゃなく、ホスト名指定になるはず。)
これは、from のホストが指定されていないため、gemini 上で実行する必要があると思う。
実際に試してみよう。
(cancer) $ virsh list --all
(gemini) $ virsh list --all
(gemini) $ virsh migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(gemini) $ virsh list --all
(cancer) $ virsh list --all
どうやら上手く行ったようだ。
これを、逆方向(cancer から gemini に)に動かすためには、cancer 上で実行する必要がある。
(cancer) $ virsh migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
これで戻せるはずだ。
(実行ホストに注意)
また、別のホスト (sagittarius) から同じように gemini→cancer や cancer→ gemini にマイグレーションするには、virsh に -c オプションを追加すればいい。
例
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
また、コチラ(外部サイト)を見ると、Xen / VMware / QEMU / VirtualBox は、通常のオプションで移動出来るようだ。
--p2p は QEMU、--tunnelled も QEMU、--direct は Xen のハイパーバイザで対応しているようだ。
とりあえず、コマンドでのマイグレーションも実現できたので、これで目的は達成。
ディスクが共有されていない環境でのマイグレーション(VMware製品だと、Storage vMothion に相当するかな？)は、ドコか別のタイミングで必要に応じて検証することにする。
これで、ココで書いた予定の1つ目はクリア。
2つ目の「dlm/corosync のフェンシング」について、詳細確認することにしよう。
多分かなり時間がかかると思う。
で、全然気付かなかったけど、virsh にもマイグレーションのオプションがあった。
ヘルプを見てみよう。(今回はヘルプの中身も引用しておく。)
(sagittarius) $ virsh help migrate
名前
migrate - ドメインの他ホストへのマイグレーション
形式
migrate <domain> <desturi> [--live] [--offline] [--p2p] [--direct] [--tunnelled] [--persistent] [--undefinesource] [--suspend] [--copy-storage-all] [--copy-storage-inc] [--change-protection] [--unsafe] [--verbose] [--compressed] [--auto-converge] [--rdma-pin-all] [--abort-on-error] [--migrateuri <string>] [--graphicsuri <string>] [--listen-address <string>] [--dname <string>] [--timeout <number>] [--xml <string>] [--migrate-disks <string>]
詳細
ドメインを他のホストにマイグレーションします。ライブマイグレーションは --live を付加します。
オプション
[--domain] <string> ドメインの名前、ID または UUID
[--desturi] <string> クライアント（通常のマイグレーション）またはソース（p2p マイグレーション）から見える宛先ホストの接続 URI
--live ライブマイグレーション
--offline オフラインマイグレーション
--p2p ピアツーピア・マイグレーション
--direct ダイレクト・マイグレーション
--tunnelled トンネル・マイグレーション
--persistent 宛先における仮想マシンの永続化
--undefinesource ソースから VM の登録解除
--suspend 宛先ホストにおいてドメインを再開しません
--copy-storage-all 完全なディスクコピーとともに非共有のストレージを用いたマイグレーション
--copy-storage-inc 増分コピーとともに非共有のストレージを用いたマイグレーション（ソースと宛先の間で同じベースイメージを共有します）
--change-protection ドメインへのあらゆる設定変更をマイグレーションが終わる まで防ぎます
--unsafe 安全ではないときにも強制的にマイグレーションする
--verbose マイグレーションの進行状況の表示
--compressed ライブマイグレーション中の連続ページの圧縮
--auto-converge force convergence during live migration
--rdma-pin-all support memory pinning during RDMA live migration
--abort-on-error 移行中にソフトなエラーが発生した場合は中止する
--migrateuri <string> マイグレーション URI（通常は省略可）
--graphicsuri <string> シームレス・グラフィック・マイグレーションのために使用するグラフィック URI
--listen-address <string> listen address that destination should bind to for incoming migration
--dname <string> マイグレーション中に名前の変更（サポートされる場合）
--timeout <number> ライブマイグレーションがタイムアウトするとゲストを強制的に一時停止する（秒単位）
--xml <string> ターゲットの更新した XML を含むファイル名
--migrate-disks <string> comma separated list of disks to be migrated
これを見ると、「一時的な移動」は --parsistent オプションと関係ありそうだ。(恐らく、--parsistent をつけない場合が、「一時的な移動」だろう。)
--undefinesource は、転送元から仮想マシン定義を削除する、ということかな？
オプションを見てみると、virt-manager では出来無さそうだった「ディスクが共有されていない環境でのマイグレーション」も出来そうだ。
何パターンも実装方法がありそうだが、とりあえずは今までやってた「共有環境でのオンラインマイグレーション」を考えてみる。
gemini で動いている leo を、cancer に移動するパターンは以下のようだ。
migrate --live \
--domain leo \
--desturi qemu+ssh://(cancerのIPアドレス)/system \
--migrateuri tcp://(cancerのIPアドレス)/
(cancer のホスト名 cancer が名前解決出来るのなら、恐らく --migrateuri は不要だ。その場合、--desturi も IPアドレスじゃなく、ホスト名指定になるはず。)
これは、from のホストが指定されていないため、gemini 上で実行する必要があると思う。
実際に試してみよう。
(cancer) $ virsh list --all
(gemini) $ virsh list --all
(gemini) $ virsh migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(gemini) $ virsh list --all
(cancer) $ virsh list --all
どうやら上手く行ったようだ。
これを、逆方向(cancer から gemini に)に動かすためには、cancer 上で実行する必要がある。
(cancer) $ virsh migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
これで戻せるはずだ。
(実行ホストに注意)
また、別のホスト (sagittarius) から同じように gemini→cancer や cancer→ gemini にマイグレーションするには、virsh に -c オプションを追加すればいい。
例
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.137/system \
--migrateuri tcp://192.168.55.137/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system \
migrate --live \
--domain leo \
--desturi qemu+ssh://192.168.55.136/system \
--migrateuri tcp://192.168.55.136/
また、コチラ(外部サイト)を見ると、Xen / VMware / QEMU / VirtualBox は、通常のオプションで移動出来るようだ。
--p2p は QEMU、--tunnelled も QEMU、--direct は Xen のハイパーバイザで対応しているようだ。
とりあえず、コマンドでのマイグレーションも実現できたので、これで目的は達成。
ディスクが共有されていない環境でのマイグレーション(VMware製品だと、Storage vMothion に相当するかな？)は、ドコか別のタイミングで必要に応じて検証することにする。
これで、ココで書いた予定の1つ目はクリア。
2つ目の「dlm/corosync のフェンシング」について、詳細確認することにしよう。
多分かなり時間がかかると思う。
ボリューム共有構成について整理しよう
とりあえず、ボリューム共有の構成について、整理したいと思う。
ここは、JIS規格の「決定表」に従って整理してみる。
HTML の table タグを使うのはちょっとタイヘンなのだが、敢えて使ってみる。
上手く整理出来ないが、ざっとこんな感じか。
ざっとこんな感じだ。
結局、パターン4 が一番良さそうだが、「一時的に移動」フラグを付け忘れると問題になる。
デフォルトで「一時的に移動」にチェックを入れておくことは出来ないものだろうか…？
次回は、virt-manager ではなくコマンドライン(virsh)を用いたマイグレーションにチャンレンジしてみよう。
ここは、JIS規格の「決定表」に従って整理してみる。
HTML の table タグを使うのはちょっとタイヘンなのだが、敢えて使ってみる。
| 1 | 2 | 3 | 4 | |
|---|---|---|---|---|
| 共有状態 | ||||
| 仮想マシン定義 | 独立 | 独立 | 共有 | 共有 |
| 仮想ディスク | 独立 | 共有 | 独立 | 共有 |
| 実行可否 | ||||
| 各ノードで起動 | 不可 | 不可 | 不可 | 可能 |
| マイグレーション | 不可 | 可能 | 不可 | 可能 |
| 「一時的に移動」 | - | 不要 | - | 必要 |
上手く整理出来ないが、ざっとこんな感じか。
- 各ノードで起動
ゲストを、gemini / cancer それぞれで(排他的に)起動可能か？という状態。
ゲストを gemini で稼働させていたが、gemini がダウンした時に、そのゲストを cancer で動かすことが可能か？という観点(HA観点) - マイグレーション
オンライン(ライブ)マイグレーション可能か？という状態。
ゲストを gemini で動かしているが、gemini をメンテナンスしたいので、ゲストを cancer に(稼働させたまま)移動させることが可能か？という観点 - 「一時的に移動」
マイグレーション実施時に、「一時的に移動」のフラグが必要か？という条件
ざっとこんな感じだ。
結局、パターン4 が一番良さそうだが、「一時的に移動」フラグを付け忘れると問題になる。
デフォルトで「一時的に移動」にチェックを入れておくことは出来ないものだろうか…？
次回は、virt-manager ではなくコマンドライン(virsh)を用いたマイグレーションにチャンレンジしてみよう。
オンラインマイグレーションの「一時的に移動」
仮想マシンの定義情報( /etc/libvirt )まで共有した状態だと、ライブマイグレーションがちょっと想定外の挙動を示すことが前回分かった。
これは内部的に、以下のような流れのためだろう。
他に方法は無いか？ということで、virt-manager を使用した移行処理の時、「一時的に移動」というオプションがあることに気付いた。
もしかしてコレじゃないか？ということで、今回試してみようと思う。
leo が停止していたら、起動しておこう。( gemini 上で起動しておく。)
leo の起動が確認できたら、前回までと同様、cancer へ移行を行う。
但し、以下の画面で「一時的に移動」をチェックしておく。
結果、どうなっただろうか？
どうやら、見た目上はすんなり移動したようだ。gemini / cancer 両方とも、定義が消えたような感じには見えない。
じゃぁ、マシン上の定義はどうなっているかな？
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
残っている。
仮想マシンの稼働状況は…
(gemini) $ virsh list --all
(cancer) $ virsh list --all
gemini 上は「シャットオフ」、cancer 上は「実行中」だ。
期待した通りの動きをしてくれた！
leo の再起動して何か変化があるか？(あるはず無いのだが…)
(leo) $ sudo systemctl reboot
(gemini) $ virsh list --all
(cancer) $ virsh list --all
変化なし。
じゃぁこの状態で gemini を再起動すると？
(gemini) $ sudo systemctl reboot
(gemini) $ virsh list --all
(cancer) $ virsh list --all
変化なし。
virt-manager を使って、leo を gemini に戻して(「一時的に移動」して)みても…。
問題なしだ。
「一時的に移動」というオプションフラグは、仮想マシン定義ファイルの移動処理は行わず、libvirt が内部で抱えている仮想マシン情報のみを移動させる、ということか。
これは使えるな。というか、狙っていた挙動そのものだ。
今後、こちら(「一時的に移動」オプションをOn」を使うようにしよう。
これは内部的に、以下のような流れのためだろう。
- gemini 上の leo を一時停止
- leo のメモリ空間に内容を cancer 上にコピー
- gemini 上の leo の定義を、cancer 上にコピー
- cancer 上で、leo の一時停止を解除(再開)
- gemini 上の leo の定義を削除。(共有しているため、cancer 上も削除される。ただし、cancer の libvirt の内部情報としては持っている状態)
他に方法は無いか？ということで、virt-manager を使用した移行処理の時、「一時的に移動」というオプションがあることに気付いた。
もしかしてコレじゃないか？ということで、今回試してみようと思う。
leo が停止していたら、起動しておこう。( gemini 上で起動しておく。)
leo の起動が確認できたら、前回までと同様、cancer へ移行を行う。
但し、以下の画面で「一時的に移動」をチェックしておく。
 |
| 「一時的に移動」にチェックを入れる |
結果、どうなっただろうか？
どうやら、見た目上はすんなり移動したようだ。gemini / cancer 両方とも、定義が消えたような感じには見えない。
 |
| すんなり移動した。定義も消えてないように見える。 |
じゃぁ、マシン上の定義はどうなっているかな？
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
残っている。
仮想マシンの稼働状況は…
(gemini) $ virsh list --all
(cancer) $ virsh list --all
gemini 上は「シャットオフ」、cancer 上は「実行中」だ。
期待した通りの動きをしてくれた！
leo の再起動して何か変化があるか？(あるはず無いのだが…)
(leo) $ sudo systemctl reboot
(gemini) $ virsh list --all
(cancer) $ virsh list --all
変化なし。
じゃぁこの状態で gemini を再起動すると？
(gemini) $ sudo systemctl reboot
(gemini) $ virsh list --all
(cancer) $ virsh list --all
変化なし。
virt-manager を使って、leo を gemini に戻して(「一時的に移動」して)みても…。
問題なしだ。
「一時的に移動」というオプションフラグは、仮想マシン定義ファイルの移動処理は行わず、libvirt が内部で抱えている仮想マシン情報のみを移動させる、ということか。
これは使えるな。というか、狙っていた挙動そのものだ。
今後、こちら(「一時的に移動」オプションをOn」を使うようにしよう。
さて、ではオンラインマイグレーションに挑戦だ
さて、前回は仮想マシンの定義情報( /etc/libvirt )と、仮想マシンの仮想ディスク領域( /var/lib/libvirt )を2つのノード(gemini / cancer)で共有している状態で、両ノードで同時に仮想マシンを起動する、ということをやった。
結果、起動はしてしまい、ファイルシステムが破損するという致命的な状態になったわけで、現実的には実施不可能という結論に達した。当たり前だが。
今回はこの環境のまま、オンラインマイグレーションに挑戦してみたいと思う。
こちら、既に一度試してみて、おかしな状態になることが分かっているため、ココで記載したバックアップが取られていることを確認しておいて欲しい。
さて、前回のままなら、仮想マシン leo は起動している状態のはずだ。もし停止してしまっていたら、起動しておいて欲しい。
gemini 上で leo が起動しているのが確認できたら、コチラの手順に従って、leo を cancer 上に移行してみて欲しい。どうなるだろうか？
マイグレーションはすんなり実施できたと思う。
が、gemini 配下に定義されていた leo が消えてしまったのではないだろうか？
実際に、gemini 上の仮想マシン定義からも、ファイル( leo.xml )が消えてしまっている。
(gemini) $ ls -l /etc/libvirt/qemu
当然、同じ領域を共有している cancer からも、消えてしまっている。
(cancer) $ ls -l /etc/libvirt/qemu
現在は cancer 上で稼働しているが、これを停止させたら、仮想マシン定義が無い以上、leo そのものが消滅してしまうのではないだろうか？
実際に停止させて確認してみよう。
(leo) $ sudo systemctl poweroff
停止直後はまだ残っているが…。試しにこのまま、virt-manager から leo を起動させてみる。
実行は出来るようだ。
この状態で、cancer の libvirt を再読込みしても、virt-manager 上からは、定義が消えない。
(cancer) $ sudo systemctl reload libvirt-bin
virt-manager から一度、cancer への接続を disconnect してから再 connect しても消えない。
定義ファイルは消失しているのに、定義がメモリ上に残っているのだろうか？
コマンドラインから確認してみよう。
(cancer) $ virsh list --all
残っている。
ただし、恐らくこの状態で cancer をOSごと再起動すると、消えてしまうと思われる。
取り急ぎ、このまま一度、leo を起動し、gemini に戻してみる。
表示上は「一時停止中」だが、きちんと稼働はしている。
しかし、仮想マシン定義ファイルは存在しないままだ。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(virt-manager から gemini への接続を一旦 disconnect し、再 connect すれば、「実行中」ステータスに変化する。)
leo の定義ファイルが消えてしまった以上、(今 leo が稼働している) gemini を再起動したら、恐らく leo は消失するだろう。
leo を停止させ、gemini を再起動してみよう。
(leo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
virt-manager から gemini への接続は切れてしまうので、gemini の再起動が完了したら、virt-manager から gemini へ再 connect してみる。
leo が消えてしまったのが確認できる。
コマンド上(virsh上)でも、leo の存在が確認できない。
(gemini) $ virsh list --all
一応、仮想ディスクは残っている。
(gemini) $ sudo ls /var/lib/libvirt/images
このような状態では、
これはあまり美味しく無い。どうしたものだろうか？
とりあえず、消失してしまった leo を復旧させることにしよう。
それには、バックアップから定義を読み込み直せばいい。
(gemini) $ sudo lvchange -a y vg-gfs2/backup
(gemini) $ sudo mount /dev/vg-gfs2/backup /mnt/backup
(gemini) $ ls /mnt/backup/leo.xml
(gemini) $ virsh define /mnt/backup/leo.xml
(gemini) $ virsh list --all
(gemini) $ ls -l /etc/libvirt/qemu
(gemini) $ sudo umount /mnt/backup
(gemini) $ sudo lvchange -a n vg-gfs2/backup
cancer 側は libvirt-bin を再読込すればいいだろう。
(cancer) $ sudo systemctl reload libvirt-bin
とりあえず元に戻すことは出来た。
必要なら、leo を起動させて簡単な動作確認をしてみればいい。
今回はここまで。
次回は、virt-manager を使用しての移行時にある、「一時的に移動」ってのを試してみたい。
結果、起動はしてしまい、ファイルシステムが破損するという致命的な状態になったわけで、現実的には実施不可能という結論に達した。当たり前だが。
今回はこの環境のまま、オンラインマイグレーションに挑戦してみたいと思う。
こちら、既に一度試してみて、おかしな状態になることが分かっているため、ココで記載したバックアップが取られていることを確認しておいて欲しい。
さて、前回のままなら、仮想マシン leo は起動している状態のはずだ。もし停止してしまっていたら、起動しておいて欲しい。
gemini 上で leo が起動しているのが確認できたら、コチラの手順に従って、leo を cancer 上に移行してみて欲しい。どうなるだろうか？
マイグレーションはすんなり実施できたと思う。
が、gemini 配下に定義されていた leo が消えてしまったのではないだろうか？
 |
| gemini から leo が消えた |
実際に、gemini 上の仮想マシン定義からも、ファイル( leo.xml )が消えてしまっている。
(gemini) $ ls -l /etc/libvirt/qemu
当然、同じ領域を共有している cancer からも、消えてしまっている。
(cancer) $ ls -l /etc/libvirt/qemu
現在は cancer 上で稼働しているが、これを停止させたら、仮想マシン定義が無い以上、leo そのものが消滅してしまうのではないだろうか？
実際に停止させて確認してみよう。
(leo) $ sudo systemctl poweroff
 |
| leo の存在は残っている |
停止直後はまだ残っているが…。試しにこのまま、virt-manager から leo を起動させてみる。
実行は出来るようだ。
この状態で、cancer の libvirt を再読込みしても、virt-manager 上からは、定義が消えない。
(cancer) $ sudo systemctl reload libvirt-bin
virt-manager から一度、cancer への接続を disconnect してから再 connect しても消えない。
定義ファイルは消失しているのに、定義がメモリ上に残っているのだろうか？
コマンドラインから確認してみよう。
(cancer) $ virsh list --all
残っている。
ただし、恐らくこの状態で cancer をOSごと再起動すると、消えてしまうと思われる。
取り急ぎ、このまま一度、leo を起動し、gemini に戻してみる。
 |
| 一応、gemini に戻すことは出来た |
表示上は「一時停止中」だが、きちんと稼働はしている。
しかし、仮想マシン定義ファイルは存在しないままだ。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(virt-manager から gemini への接続を一旦 disconnect し、再 connect すれば、「実行中」ステータスに変化する。)
leo の定義ファイルが消えてしまった以上、(今 leo が稼働している) gemini を再起動したら、恐らく leo は消失するだろう。
leo を停止させ、gemini を再起動してみよう。
(leo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
virt-manager から gemini への接続は切れてしまうので、gemini の再起動が完了したら、virt-manager から gemini へ再 connect してみる。
 |
| gemini の再起動で leo の存在が消失 |
leo が消えてしまったのが確認できる。
コマンド上(virsh上)でも、leo の存在が確認できない。
(gemini) $ virsh list --all
一応、仮想ディスクは残っている。
(gemini) $ sudo ls /var/lib/libvirt/images
このような状態では、
- gemini のメンテナンスのために、gemini 上の仮想マシンを cancer 上へ移行
- gemini をメンテナンスし、再起動
- cancer に移行した仮想マシンを gemini に戻す
これはあまり美味しく無い。どうしたものだろうか？
とりあえず、消失してしまった leo を復旧させることにしよう。
それには、バックアップから定義を読み込み直せばいい。
(gemini) $ sudo lvchange -a y vg-gfs2/backup
(gemini) $ sudo mount /dev/vg-gfs2/backup /mnt/backup
(gemini) $ ls /mnt/backup/leo.xml
(gemini) $ virsh define /mnt/backup/leo.xml
(gemini) $ virsh list --all
(gemini) $ ls -l /etc/libvirt/qemu
(gemini) $ sudo umount /mnt/backup
(gemini) $ sudo lvchange -a n vg-gfs2/backup
cancer 側は libvirt-bin を再読込すればいいだろう。
(cancer) $ sudo systemctl reload libvirt-bin
とりあえず元に戻すことは出来た。
必要なら、leo を起動させて簡単な動作確認をしてみればいい。
今回はここまで。
次回は、virt-manager を使用しての移行時にある、「一時的に移動」ってのを試してみたい。
2017年5月8日月曜日
まずは両ノードで起動
さて、これでバックアップの取得は完了したので、検証開始だ。
まずは、leo を gemini / cancer の両ノードで起動してみよう。
ここでは、後から起動した方が「ファイルがロックされてるぜよ」と言われて起動に失敗する、というのを期待していた…、が、なんと！両ノードで起動できてしまった。
とりあえずそれを見てみよう。
(virt-manager を使って、コンソールを見ておこう。)
(gemini) $ virsh start leo
起動できたら ssh でログインして普通に操作可能なことを確認しておく。
(cancer) $ virsh start leo
なんと、cancer 上の leo も起動できてしまった。
そして、gemini→leo にログインしてた sshセッションも切れたはずだ。
gemini→leo も cancer→leo も同じ IPアドレスなので、後から上がってきた cancer→leo が奪ってしまったような格好だ。
それぞれのコンソールからローカルログインして、ping等で他のマシンとの疎通を確認してみよう。cancer→leo がネットワーク疎通出来るはずだ。
しかしコレ、ディスク I/O とか大丈夫なのだろうか…。
gemini→leo 側でディスクに書き込んで、cancer→leo 側で見てみる。
(gemini) $ echo "test" > test.txt
(cancer) $ ls
gemini→leo で作ったファイルは、cancer→leo では確認できない。
逆はどうだろうか？
(cancer) $ echo "test2" > test2.txt
(gemini) $ ls
やっぱり確認できない。
どういうことだろうか…？
おっと？しばらく放置していたら、cancer→leo のコンソールにエラーが。
--
EXT4-fs error (device dm-0): ext4_mb_generate_buddy:758: group 321, block bitmap and bg descriptor inconsistent: 31900 vs 31901 free clusters
Aborting journal on device dm-0-8.
EXT4-fs (dm-0): Remounting filesystem read-only
EXT4-fs error (device dm-0): ext4-journal_check_start:56: Detected aborted journal
--
だそうだ。
更新処理でバッティングが起きて、リードオンリーで再マウントされたっぽいぞ。
(leo) $ grep vg-root /etc/mtab
確かに、ro になっている。
gemini→leo の方はどうだろう？
(leo) $ grep vg-root /etc/mtab
こっちは rw だ。
このままではとても危険な香りがするので停止しよう。
cancer→leo から停止。
(leo) $ sudo systemctl poweroff
続いて、gemini→leo
(leo) $ sudo systemctl poweroff
gemini→leo をもう一度起動して、ファイルの状態を確認してみよう。
(gemini) $ virsh start leo
(leo) $ ls
おっと！？test.txt が作られておらず、test2.txt が作られているな…。
が、中身が空だ。
ssh でログインしたら、先程 cancer→leo で起きたのと同じようなエラーが発生。リードオンリーになってしまった。
再起動して再確認。
(leo) $ sudo systemctl reboot
起動中に fsck が実行された。やはりファイルシステム上に問題が起きたようだ。
しかも、修復できなかったっぽい。
initramfs でコンソールが出てきたので、fsck をかけてみる。
(initramfs) fsck.ext4 -y /dev/mapper/leo--vg-root
成功したら、もう一度再起動。
(initramfs) reboot
なんとか修復されて起動はしてきた。
が、やはり test2.txt が空で存在している。
同時起動は出来てしまうが、ゲストOS のファイルシステムが壊れてしまうようだ。当たり前なんだが…。
逆に、同時起動を禁止するような制御をして欲しかったが…。まだ今の KVM にはその機能が搭載されていないか。将来的にも搭載されるかどうか…。
当面は、2重起動にならないように気をつける、という対策ぐらいしかないな。
とりあえず、ゴミの test2.txt は削除しておこう。
(leo) $ rm test2.txt
この後、ライブマイグレーションに挑戦したいので、leo は起動したままにしておく。
まずは、leo を gemini / cancer の両ノードで起動してみよう。
ここでは、後から起動した方が「ファイルがロックされてるぜよ」と言われて起動に失敗する、というのを期待していた…、が、なんと！両ノードで起動できてしまった。
とりあえずそれを見てみよう。
(virt-manager を使って、コンソールを見ておこう。)
(gemini) $ virsh start leo
起動できたら ssh でログインして普通に操作可能なことを確認しておく。
(cancer) $ virsh start leo
なんと、cancer 上の leo も起動できてしまった。
そして、gemini→leo にログインしてた sshセッションも切れたはずだ。
gemini→leo も cancer→leo も同じ IPアドレスなので、後から上がってきた cancer→leo が奪ってしまったような格好だ。
それぞれのコンソールからローカルログインして、ping等で他のマシンとの疎通を確認してみよう。cancer→leo がネットワーク疎通出来るはずだ。
しかしコレ、ディスク I/O とか大丈夫なのだろうか…。
gemini→leo 側でディスクに書き込んで、cancer→leo 側で見てみる。
(gemini) $ echo "test" > test.txt
(cancer) $ ls
gemini→leo で作ったファイルは、cancer→leo では確認できない。
逆はどうだろうか？
(cancer) $ echo "test2" > test2.txt
(gemini) $ ls
やっぱり確認できない。
どういうことだろうか…？
おっと？しばらく放置していたら、cancer→leo のコンソールにエラーが。
--
EXT4-fs error (device dm-0): ext4_mb_generate_buddy:758: group 321, block bitmap and bg descriptor inconsistent: 31900 vs 31901 free clusters
Aborting journal on device dm-0-8.
EXT4-fs (dm-0): Remounting filesystem read-only
EXT4-fs error (device dm-0): ext4-journal_check_start:56: Detected aborted journal
--
だそうだ。
更新処理でバッティングが起きて、リードオンリーで再マウントされたっぽいぞ。
(leo) $ grep vg-root /etc/mtab
確かに、ro になっている。
gemini→leo の方はどうだろう？
(leo) $ grep vg-root /etc/mtab
こっちは rw だ。
このままではとても危険な香りがするので停止しよう。
cancer→leo から停止。
(leo) $ sudo systemctl poweroff
続いて、gemini→leo
(leo) $ sudo systemctl poweroff
gemini→leo をもう一度起動して、ファイルの状態を確認してみよう。
(gemini) $ virsh start leo
(leo) $ ls
おっと！？test.txt が作られておらず、test2.txt が作られているな…。
が、中身が空だ。
ssh でログインしたら、先程 cancer→leo で起きたのと同じようなエラーが発生。リードオンリーになってしまった。
再起動して再確認。
(leo) $ sudo systemctl reboot
起動中に fsck が実行された。やはりファイルシステム上に問題が起きたようだ。
しかも、修復できなかったっぽい。
initramfs でコンソールが出てきたので、fsck をかけてみる。
(initramfs) fsck.ext4 -y /dev/mapper/leo--vg-root
成功したら、もう一度再起動。
(initramfs) reboot
なんとか修復されて起動はしてきた。
が、やはり test2.txt が空で存在している。
同時起動は出来てしまうが、ゲストOS のファイルシステムが壊れてしまうようだ。当たり前なんだが…。
逆に、同時起動を禁止するような制御をして欲しかったが…。まだ今の KVM にはその機能が搭載されていないか。将来的にも搭載されるかどうか…。
当面は、2重起動にならないように気をつける、という対策ぐらいしかないな。
とりあえず、ゴミの test2.txt は削除しておこう。
(leo) $ rm test2.txt
この後、ライブマイグレーションに挑戦したいので、leo は起動したままにしておく。
2017年5月6日土曜日
仮想ディスク領域が共有されている状態でのライブマイグレーション
さて、多分これで、gemini 上で動いている leo を、稼働させたまま cancer へ移すことが出来るのではないか？
これを行うためには、gemini / cancer に接続可能なマシン上で virt-manager を動かすのが都合がいい。
やり方としては
今回は3番目を試してみることにする。
まずは、sagittarius 上で virt-manager を起動しよう。
(sagittarius) $ virt-manager
起動したら、メニューバーの「ファイル」から「接続を追加」だ。
出てきたダイアログを、以下の図のように設定。
ユーザー名は、gemini 上のOSアカウント名だ。
また、ホスト名は gemini の IPアドレスを入れよう。
接続ボタンを押すと、すぐには反応が無いはず。
この場合、 gemini に接続している teraterm を見てみよう。
「エージェント転送要求を受け入れますか？」というダイアログが出てきていたら、「はい」と答えよう。
無事に gemini への接続が行われ、leo が稼働しているのが分かるはずだ。
同じ手順で、 cancer にも接続しておこう。
もし、一連の作業が上手く行かなかったら、sagittarius から gemini / cancer へ ssh 接続してみよう。今回の設定は、ssh を使って接続しているので、そもそも ssh が利用できなかったら接続できない。
また、「エージェント転送を受け入れますか？」に関しては、 teraterm の設定で無条件に受け入れるようにすることも可能だ。セキュリティ的にどうかと思うが、面倒くさかったら自動受け入れにしてもいいだろう。teraterm.ini の ForwardAgentConfirm というパラメータだと思う。
ちなみにこの先、ちょっとオペレーションするたびに、「エージェント転送を受け入れますか？」と聞かれる。マジで鬱陶しい。teraterm.ini を書き換えたら、teraterm を再起動する必要があるので要注意だ。
さて、実際にライブマイグレーションする前に、状況を確認しておこう。
本当に稼働中かどうかを確認するために、leo へログインしておく。
gemini / cancer の仮想マシン状態をチェックしておこう。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(gemini) $ virsh list --all
(cancer) $ virsh list --all
また、gemini / cancer 両ノードから、 leo へ ping を打ち続けておこう。
(gemini) $ ping 192.168.55.138
(cancer) $ ping 192.168.55.138
先程起動した virt-manager の gemini の中にある leo を右クリック、表示されたコンテキストメニューから「移行」を選択だ。
出てきたダイアログに対し、「移行先のホスト」は cancer の接続設定を、モードは「ダイレクト」と「トンネル」があるが、今回は「ダイレクト」を選んでみた。「トンネル」では、条件が整わずに実行エラーになった。こちらは別途調査。移行先のアドレスは、まだ名前解決が出来ないので、cancer の IP アドレスを直接入力。
これで「マイグレーション」を押すと…
(例によって「エージェント転送を許可しますか？」と聞かれるので「はい」だ)
少し(10秒程度？)で、移行が完了したことが分かる。
(先程まで gemini にあった leo が、cancer の方に移動していることが分かる。)
ping も途切れていないし、leo へログインしていたセッションも切れていないはずだ。
では、gemini / cancer の状態を確認。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(gemini) $ virsh list --all
(cancer) $ virsh list --all
gemini から leo の定義ファイル(/etc/libvirt/qemu/leo.xml)が消えて、cancer に移っているのが確認でき、更に leo が cancer 側で動いているのが確認できる。
ライブマイグレーションはこのように実施できるのが確認できた。
cancer 上で leo の起動停止も出来るはずだ。
合わせて確認してみて欲しい。
次は、/etc/libvirt まで共有化し、その上でライブマイグレーションが可能かどうか？を確認したい。
それに備えて、先程の手順と同様に、leo を gemini に戻し、leo を停止させておこう。
(leo を停止してから移動、つまりオフラインマイグレーションはこの手順では出来ないようだ。)
今回はココまで。
これを行うためには、gemini / cancer に接続可能なマシン上で virt-manager を動かすのが都合がいい。
やり方としては
- gemini 上で virt-manager を起動し、cancer への追加接続する
- cancer 上で virt-manager を起動し、gemini への追加接続する
- sagittarius 上で virt-manager を起動し、gemini / cancer 両ノードへ追加接続する
今回は3番目を試してみることにする。
まずは、sagittarius 上で virt-manager を起動しよう。
(sagittarius) $ virt-manager
起動したら、メニューバーの「ファイル」から「接続を追加」だ。
出てきたダイアログを、以下の図のように設定。
ユーザー名は、gemini 上のOSアカウント名だ。
また、ホスト名は gemini の IPアドレスを入れよう。
接続ボタンを押すと、すぐには反応が無いはず。
この場合、 gemini に接続している teraterm を見てみよう。
「エージェント転送要求を受け入れますか？」というダイアログが出てきていたら、「はい」と答えよう。
無事に gemini への接続が行われ、leo が稼働しているのが分かるはずだ。
同じ手順で、 cancer にも接続しておこう。
もし、一連の作業が上手く行かなかったら、sagittarius から gemini / cancer へ ssh 接続してみよう。今回の設定は、ssh を使って接続しているので、そもそも ssh が利用できなかったら接続できない。
また、「エージェント転送を受け入れますか？」に関しては、 teraterm の設定で無条件に受け入れるようにすることも可能だ。セキュリティ的にどうかと思うが、面倒くさかったら自動受け入れにしてもいいだろう。teraterm.ini の ForwardAgentConfirm というパラメータだと思う。
ちなみにこの先、ちょっとオペレーションするたびに、「エージェント転送を受け入れますか？」と聞かれる。マジで鬱陶しい。teraterm.ini を書き換えたら、teraterm を再起動する必要があるので要注意だ。
さて、実際にライブマイグレーションする前に、状況を確認しておこう。
本当に稼働中かどうかを確認するために、leo へログインしておく。
gemini / cancer の仮想マシン状態をチェックしておこう。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(gemini) $ virsh list --all
(cancer) $ virsh list --all
また、gemini / cancer 両ノードから、 leo へ ping を打ち続けておこう。
(gemini) $ ping 192.168.55.138
(cancer) $ ping 192.168.55.138
先程起動した virt-manager の gemini の中にある leo を右クリック、表示されたコンテキストメニューから「移行」を選択だ。
出てきたダイアログに対し、「移行先のホスト」は cancer の接続設定を、モードは「ダイレクト」と「トンネル」があるが、今回は「ダイレクト」を選んでみた。「トンネル」では、条件が整わずに実行エラーになった。こちらは別途調査。移行先のアドレスは、まだ名前解決が出来ないので、cancer の IP アドレスを直接入力。
これで「マイグレーション」を押すと…
(例によって「エージェント転送を許可しますか？」と聞かれるので「はい」だ)
少し(10秒程度？)で、移行が完了したことが分かる。
(先程まで gemini にあった leo が、cancer の方に移動していることが分かる。)
ping も途切れていないし、leo へログインしていたセッションも切れていないはずだ。
では、gemini / cancer の状態を確認。
(gemini) $ ls -l /etc/libvirt/qemu
(cancer) $ ls -l /etc/libvirt/qemu
(gemini) $ virsh list --all
(cancer) $ virsh list --all
gemini から leo の定義ファイル(/etc/libvirt/qemu/leo.xml)が消えて、cancer に移っているのが確認でき、更に leo が cancer 側で動いているのが確認できる。
ライブマイグレーションはこのように実施できるのが確認できた。
cancer 上で leo の起動停止も出来るはずだ。
合わせて確認してみて欲しい。
次は、/etc/libvirt まで共有化し、その上でライブマイグレーションが可能かどうか？を確認したい。
それに備えて、先程の手順と同様に、leo を gemini に戻し、leo を停止させておこう。
(leo を停止してから移動、つまりオフラインマイグレーションはこの手順では出来ないようだ。)
今回はココまで。
2017年5月4日木曜日
kvmで使用する共有ファイルシステムの検討
とりあえず、共有ファイルシステムは gfs2 を使用することに決定。
で、これから検討したいのは、kvm の領域のドコを共有ファイルシステムにするか？という点。
具体的には…
(/var/log/libvirt は単なる稼動ログなので、共有させる必要は無いと考えている。)
仮想マシンに関する定義が /etc/libvirt/qemu に格納されていて、gemini / cancer のどちらでも同じ仮想マシンを起動できるようにするには、最低でも /etc/libvirt/qemu と仮想マシンのイメージファイルが格納されている /var/lib/libvirt/images は共有させる必要があると思う。
けど、オンラインマイグレーションを想定した場合、/etc/libvirt/qemu が共有されていていいのだろうか？
また、仮想マシンのスナップショットは、/var/lib/libvirt/qemu/snapshot に格納されるっぽい。これらも共有しなくていいのか？(外部スナップショットではなく、内部スナップショットなら、同じディスクイメージにスナップショットが作られるので、この点は確認不要だ。)
更には、共有しようとしているディレクトリに、ホスト固有の情報が記録されていないだろうか？
等など、検討しないといけないことはたくさん有り、そもそも共有出来るのかどうか…。
今回検討したいのは、主に
スナップショット等の情報もそのまま引き継げればベスト。
というわけで、次回から環境を作っていこう。
で、これから検討したいのは、kvm の領域のドコを共有ファイルシステムにするか？という点。
具体的には…
- /var/lib/libvirt を共有する
- /etc/libvirt、/var/lib/libvirt を共有する
- /var/lib/libvirt/images、/var/lib/libvirt/qemu を共有する
- /etc/libvirt、/var/lib/libvirt/images、/var/lib/libvirt/qemu を共有する
(/var/log/libvirt は単なる稼動ログなので、共有させる必要は無いと考えている。)
 |
| パターン1の例 |
 |
| パターン2の例 |
仮想マシンに関する定義が /etc/libvirt/qemu に格納されていて、gemini / cancer のどちらでも同じ仮想マシンを起動できるようにするには、最低でも /etc/libvirt/qemu と仮想マシンのイメージファイルが格納されている /var/lib/libvirt/images は共有させる必要があると思う。
けど、オンラインマイグレーションを想定した場合、/etc/libvirt/qemu が共有されていていいのだろうか？
また、仮想マシンのスナップショットは、/var/lib/libvirt/qemu/snapshot に格納されるっぽい。これらも共有しなくていいのか？(外部スナップショットではなく、内部スナップショットなら、同じディスクイメージにスナップショットが作られるので、この点は確認不要だ。)
更には、共有しようとしているディレクトリに、ホスト固有の情報が記録されていないだろうか？
等など、検討しないといけないことはたくさん有り、そもそも共有出来るのかどうか…。
今回検討したいのは、主に
- 片方のノードがダウンした時に、ダウンしていた方のノードで稼働していた仮想マシンが、生きている方のノードで起動できるか？
- 稼働している仮想マシンを、動かしたままもう片方のノードへ移動できるか？(ライブマイグレーション)
スナップショット等の情報もそのまま引き継げればベスト。
というわけで、次回から環境を作っていこう。
登録:
投稿 (Atom)