pmsuspend

ちょっと pmsuspend(pm-suspend) と hibernate について調べてたんだけど、どうも上手く動かない。
suspend は実施出来るが、復帰後はコンソールが乱れてしまい、入力が出来ない。
また、hibernate は落とした後、正常起動してこない。
ちょっと放置かな…？

とりあえず、「ホストを停止させる時に、ゲストも自動的に停止させる」件、物理ホストである aquarius / sagittarius に反映させようかな…。

ホスト停止時にゲストを停止

さて、これまで何度も、仮想マシンが動いているホストを 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 をもう少しツッコんで見る。

続いて、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 化するのはこれでオシマイ。

autofs 設定を aquarius に

前回、gemini で無事に検証が出来た、cifs 領域の autofs。
今回は aquarius に適用してみる。
というのも、sagittarius 上では 仮想マシンが複数動いているが、aqaurisu 上では仮想マシンを動かしておらず、OS 再起動検証が可能だからだ。

というわけで早速…。
(手順は前回と全く同じだぞ)
(aquarius) $ sudo apt-get update
(aquarius) $ sudo apt-get install autofs

(aquarius) $ sudo mkdir /etc/auto.master.d
(aquarius) $ sudo vi /etc/auto.master.d/mnt.autofs

--ココから
/mnt /etc/auto.master.d/auto.mnt --timeout=60 --ghost
--ココまで

(aquarius) $ sudo vi /etc/auto.master.d/auto.mnt
--ココから
iso-os -fstype=cifs,guest ://(NASのIP)/(共有フォルダ)
--ココまで

(aquarius) $ sudo systemctl stop /mnt/iso-os
(aquarius) $ sudo systemctl restart autofs
(aquarius) $ df /mnt/iso-os
(aquarius) $ ls /mnt/iso-os
(aquarius) $ sleep 60
(aquarius) $ df /mnt/iso-os

(aquarius) $ sudo vi /etc/fstab
--fstab の当該行のコメント化(内容省略)
(aquarius) $ sudo systemctl daemon-reload

(aquarius) $ sudo systemctl reboot
(aquarius) $ ls /mnt/iso-os

大丈夫そうだ。
次は、sagittairus 上で稼働している仮想マシンを、全て aquarius にオンラインマイグレーションした後に、sagittarius 上で同じ作業を実施する。

とりあえず、cifs マウントを autofs 管理に(検証)

NAS を cifs マウントしているんだけど、NAS 側の省電力機能で、暫くアクセスが無いと sleep してしまう。
で、sleep した状態からアクセスしようとすると、エラーになってしまう。
これを防ぎたいんだけど、NAS の省電力機能は有効にしておきたい。
なので、autofs が利用できないか検討してみよう。

で、まずは検証。
検証用の gemini / cancer のウチ、cancer はちょっと故障してしまったので、gemini で実施する。

gemini を起動し、autofs をインストールしてみる。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install autofs

パッケージ内に含まれるファイルの一覧を確認。
(gemini) $ dpkg -L autofs
どうやら、auto.master 等はパッケージに含まれているわけではなく、インストール時に自動的に作成されるようだ。

マウント用の設定ファイルは /etc/auto.master だけど、このファイルは、 /etc/auto.master.d/*.autofs を取り込んでいるようだ。
ということは、/etc/auto.master.d/mnt.autofs とかを作ればいいのかな？

とりあえずやってみる。
(gemini) $ sudo mkdir /etc/auto.master.d
(gemini) $ sudo vi /etc/auto.master.d/mnt.autofs
--ココから
/mnt /etc/auto.master.d/auto.mnt --timeout=60 --ghost
--ココまで

(gemini) $ sudo vi /etc/auto.master.d/auto.mnt
--ココから
iso-os -fstype=cifs,guest ://(NASのIP)/(共有フォルダ)
--ココまで

(gemini) $ sudo systemctl stop /mnt/iso-os
(gemini) $ sudo systemctl restart autofs
(gemini) $ df /mnt/iso-os
(gemini) $ ls /mnt/iso-os
(gemini) $ sleep 60
(gemini) $ df /mnt/iso-os

これでいいのかな？

後は、マウントが重ならないように、/etc/fstab の当該行の先頭に#を付与してコメントにしておこう。
(gemini) $ sudo vi /etc/fstab
--内容省略
(gemini) $ sudo systemctl daemon-reload

再起動して確認
(gemini) $ sudo systemctl reboot
(gemini) $ ls /mnt/iso-os
マウントはされている。これでいいのだろうか？

暫くこれで運用。
--20170529修正
ファイル名を間違えていたので修正。

corosync が落ちる？

とりあえず、gfs2 を復旧させて、2台のPC(aquarius / sagittairus)を起動しておいたんだけど、aquarius の corosync がクラッシュしてた…。

まだ corosync / dlm が不安定だな…。何が原因だろう…。

Intel AMT

どうやら、ウチの2台のPCは、Intel AMTをサポートしていないようだ。
ザンネン。しょうがないか。

pegasus と cancerの仮想ディスクが…

dlm のクラッシュで、無理やりホストマシンを再起動繰り返してたら、/var/lib/libvirt の gfs2 領域がおかしくなったみたい。

で、アンマウントして fsck.gfs2 を実行。
かなり壊れていて、やっと復旧できたと思ったら、pegasus と cancer の仮想ディスクが消えてしまった…。
pegasus はバックアップがあったので、これから復旧してみるけど、cancer はバックアップ取ってない。
ま、cancer は実験環境だし、gemini とセットで作り直すツモリだからいいんだけどね。

みんなもゲストOS のバックアップ忘れないように…。

ホストを停止させる時にゲストを停止させたい

そうそう、ホストマシンをシャットダウンさせる時、その上で稼働しているゲストを停止させたい。
ホストマシンのシャットダウンで刺さる現象の一つだ。
で、それも自動停止出来るような設定を入れたい。

課題だ。

Intel AMTというキーワード

なんか、Intel AMT というキーワードを知った。
ウチの環境で利用できるか分からない。確認しておこう。

まだ色々不具合が…

次のアクションとしては、NASのCIFS領域のマウントに autofs を使用してみよう、というプランがあったんだけど…。
それ以前にまだ、起動停止時の不具合が残っているし、仮想マシンを稼働させたまま、ホストマシンを停止させてしまうと不具合が起きる事象、それに合わせて反対側(aquarius を停止させたのなら sagittarius側)でも dlm 関連のトラブルが起きる…。

これらのトラブルの発生要因を整理し、修正しないと全然利用出来ないな…。

シャットダウン時に刺さる現象再び！

シャットダウン・リブート時にハングする現象、ココで暫定対策を施しておいたんだけど、また再発した。
遠隔からリブート仕掛けたらハングしてしまったので、何が起きたのかは分からず。
帰宅後にコンソールを見てみてもよく分からなかった。

ただ、どうも dlm 絡みのような気がしてならない。
問題が起きたから dlm がトラブったのか、dlm がトラブったから問題が発生したのか、どちらが主要因かは分からない。

何せ、再現性に乏しいのが辛いところ。

とりあえず、lvm2-cluster-activation.service の停止処理の sleep 10 と、openvswitch-switch.service の起動処理の sleep 10 を、sleep 20 に伸ばしてみた。
直接の原因が分からないので、これが効果あるのかどうかも分からない。

取り急ぎ、これで逃げておくことにする。

sagittarius の整理

これでようやく sagittarius の仮想マシンがゼロになった。
sagittarius の整理をしよう。

とは言っても、大きく「ログファイルの移動」と「専用ディスクの排除」「共有ボリュームのマウント」の3点だろう。

ログファイルの移動は、既にココの後半部で aquarius にて実施済み。
その手順をなぞればいい。

専用ディスクの排除は、今まで kvm 仮想マシンが載っていたディスク領域を排除することだが、まずはアンマウント状態にしておいて、後日削除、でいいだろう。
共有ボリュームのマウントと合わせて、やはりココの後半部で実施済みだ。

そのため、ざっとコマンドだけ並べておくことにする。

まずはログファイルの移動
(sagittarius) $ cd /var/log
(sagittarius) $ sudo tar cvf libvirt.tar libvirt
(sagittarius) $ sudo systemctl stop /var/log/libvirt
(sagittarius) $ sudo chmod 755 /var/log/libvirt
(sagittarius) $ sudo chown root:root /var/log/libvirt
(sagittarius) $ sudo tar xvf libvirt.tar
(sagittarius) $ sudo rmdir libvirt/lost+found
(sagittarius) $ ls libvirt
(sagittarius) $ sudo rm libvirt.tar
(sagittarius) $ cd

続いて、専用ディスクの取り外しと共有ディスクのマウント(/etc/fstab も書き換え)
(sagittarius) $ sudo systemctl stop /etc/libvirt
(sagittarius) $ sudo systemctl stop /var/lib/libvirt
(sagittarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで

(sagittarius) $ sudo systemctl daemon-reload
(sagittarius) $ sudo systemctl start /etc/libvirt
(sagittarius) $ grep /etc/libvirt /etc/mtab
(sagittarius) $ sudo systemctl start /var/lib/libvirt
(sagittarius) $ grep /var/lib/libvirt /etc/mtab

(sagittarius) $ ls /etc/libvirt
(sagittarius) $ ls /var/lib/libvirt

多分この状態では、まだ共有仮想マシンが認識できていないと思う。
libvirt-bin を再起動することで認識させることが可能だ。
(sagittarius) $ virsh list --all
(sagittarius) $ sudo systemctl restart libvirt-bin.service
(sagittarius) $ virsh list --all

必要に応じて、sagittarius を再起動して、共有領域が正しく認識・マウントされるか確認しておこう。

仮想マシンの共有領域への移動(稼働状態)

とりあえず、停止している仮想マシンを共有領域へ移動させることは完了した。
次は残っている稼働中の仮想マシンだ。
(前回 sagittarius からアンマウントしてしまった共有領域は、同じ場所にマウントしておこう。)

現在、稼働中の仮想マシンは以下の3つ。

• pegasus : Windows7 環境
• 貸出1 : Ubuntu Linux環境
• 貸出2 : RedHat Enterprise Linux環境

貸出1/2の2つは知り合いに貸し出していて、いつログインされるか分からない。
そのため、本当に稼働中にオンラインで移行したいと思う。
ただ、既に移行は実績有りで、ココの後半の手順に従えばいい。

コマンドを実行するのは 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

次回は、稼働中のマシンの移行を行う。

/etc/passwdと/etc/groupが…

ちょっとタイヘンなことに気付いた。
aquarius と sagittarius 、2台のマシンで /etc/passwd と /etc/group が合っていない。
そのせいで、仮想マシン環境の共有が出来ないという問題が発覚。

今は sagittarius 側で仮想マシンが動いており、ちょっといじるのはきついので、aquarius 側を変更するようにする。

2台の間で /etc/passwd と /etc/group を突き合わせ、差分を確認する。
差異が見つかったら、それらの所有のファイルを確認する。
例えば…
(aquarius) $ sudo find / -group messagebus -print
(aquarius) $ sudo find / -user messagebus -print
等だ。

で、その後、それらのファイルのグループ・オーナーを変更し、/etc/passwd、/etc/group を書き換える。
詳細は端折るが、こんなコマンドで。
(aquarius) $ sudo chgrp lpadmin /dev/kvm
：
：
(aquarius) $ sudo vigr
(aquarius) $ sudo vipw

最後に、再起動して結果を確認してオシマイだ。
(aquarius) $ sudo systemctl reboot

/var/lib/libvirt の拡張

さて続いて、/var/lib/libvirt の領域の拡張方法を記載しておく。
LVMに詳しいのなら、特に気にしなくても大丈夫だ。

一つだけ注意点がある。
ext4 系のファイルシステムなら、一度拡張しても、縮小することは出来る。が、gfs2 ファイルシステムは一度拡張したら、縮小することが出来ない。拡張は簡単だが、縮小が出来ないため、拡張が必要な場合は十分に検討して拡張するように。

また、前回作成したVGは、わざと20GBほど残している。これは将来、このVGからスナップショットを作ることを想定してのことだ。LVMではボリューム管理が楽なので、わざと多少残しておいておくのがベターだぞ。

---

まずは、iSCSI領域から新しいLUN(100GB)を作成し、kvmtargetターゲットに接続しよう。
この時、LUNの名前は kvm002 にしておこう。(数が増えれば、当然末尾の数字は増やす。)

---

続いて、aquarius / sagittarius で iSCSI LUN の確認をしよう。
$ dmesg
aquarius では /dev/sdc、sagittarius では /dev/sdj として認識された。
(この辺は、マシンの環境でデバイス名が変わるぞ)

---

今度は、確認できたLUNを、multipath 管理下にする。
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdj
$ sudo cat /etc/multipath/wwids

bindings ファイルへ反映(下線部は、上記コマンドで見つかった wwid にすること)
$ sudo cat /etc/multipath/bindings
$ sudo bash -c "echo kvm002 23661323765323131 >> /etc/multipath/bindings"
$ sudo cat /etc/multipath/bindings

multipath コマンドで反映＆確認
$ sudo multipath -ll
(aquarius) $ sudo multipath -r /dev/sdc
(sagittarius) $ sudo multipath -r /dev/sdj
$ sudo multipath -ll

これで、追加ディスクを /dev/mapper/kvm002 として取り扱うことが出来るようになった。

---

次は LVM 関連の操作。
$ sudo pvdisplay /dev/mapper/kvm002
(aquarius) $ sudo pvcreate /dev/mapper/kvm002
$ sudo pvdisplay /dev/mapper/kvm002

$ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgextend kvmcluster /dev/mapper/kvm002
$ sudo vgdisplay -v kvmcluster

今回は、 /var/lib/libvirt 用に 100GB 拡張する。
(実際には、追加した 100GB の LUN は、LVM管理情報等が入るため、100GB から若干少ない容量になるのだが、あまり細かい計算はしない)
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt
(aquarius) $ sudo lvextend -L +100G kvmcluster/var-lib-libvirt
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt

$ sudo vgdisplay -v kvmcluster

これで、kvmcluster/var-lib-libvirt の領域が 180GB まで拡張されたはずだ。

---

今度は、ファイルシステムの拡張。
(aquarius) $ df -h /var/lib/libvirt
(aqaurius) $ sudo gfs2_grow -T /var/lib/libvirt
(aquarius) $ sudo gfs2_grow /var/lib/libvirt
(aquarius) $ df -h /var/lib/libvirt

この時、どうやら当該領域をマウントしている全てのノードで gfs2_grow を実施しないといけないようだ…。
今回は aquarius でしかマウントしていないため、特に気にする必要はなかった。
次回気をつけよう。

ファイルシステムのマウントはこれで一旦終了。
必要に応じてこの手順を繰り返して、必要量に拡張してくれ。

aquarius / sagittarius 用の共有ボリュームの作成

今度は、KVM の共有ボリュームの作成だ。
殆どは、これまで実施してきた作業の応用なので、そんなに説明はいらないだろう。

---

まずはストレージ装置で、iSCSIターゲットを新たに作成する。
名前は kvmtarget とでもしておこう。

---

で、aquarius / sagittarius からのみアクセス可能にする。(アクセス権限は R/W)
aquarius / sagittarius の iSCSIイニシエータのIQNが必要だが、それは /etc/iscsi/initiatorname.iscsi を見れば分かるぞ。
$ sudo cat /etc/iscsi/initiatorname.iscsi

---

そしたら、ストレージ装置側でボリュームを作成し、今作成した iSCSIターゲット へ割り当てよう。
LUNの作成方針としては、各自で自由に決めてもらっていいけど、自分は 100GB ずつ作成、という方針にしている。
まずは 100GB を1つ、kvm001 という名前で作成した。

---

この状態で、aquairus / sagittarius から iSCSIターゲット へログインする。
$ sudo iscsiadm -m discovery -t sendtargets -p (NASのIPアドレス)
$ sudo iscsiadm -m node --targetname (NASのIQN名) --login
(NAS の IQN名 は、ストレージ装置側で確認しよう。)

そうしたら、新たなディスクが見えてきたはずだ。
$ dmesg
(aquarius では /dev/sdc、sagittarius では /dev/sdi で見えてきた。)

合わせて、OS 起動時にiSCSIターゲットに自動的にログインするようにしよう。
$ sudo iscsiadm --mode node \
--targetname=(iSCSIターゲットのIQN名) \
--op=update \
--name=node.startup \
--value=automatic

---

このディスクを multipathd 管理にする。
$ lsblk
$ sudo multipath -ll
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdi
(aquarius / sagittarius どちらも同じ wwid が追加されたはず。)

$ sudo vi /etc/multipath/bindings
先程見えてきた wwid を、kvm001 という名前にする。
具体的には以下の行を追記する。(下線部は見えてきた wwid にすること)
kvm001 23565633034613838

multipathd でデバイスを認識する
$ sudo multipath -ll
$ sudo multipath -r
$ sudo multipath -ll
これで、/dev/mapper/kvm001 というデバイスファイル名でアクセス出来るようになるはずだ。

$ lsblk
mpath名 kvm001 が存在していることが確認できる。

---

続いて、そのボリュームを使って仮想マシン領域を作成する。
/etc/libvirt と /var/lib/libvirt の2つとし、/var/log/libvirt は OS ディスク領域をそのまま使うことにする。

また /etc/libvirt は、そんなに頻繁に書き換わるわけではないため、ジャーナルサイズはデフォルトの128MBから大きく下げて、最低の 8MByte にする。
2017/05/22 修正
ジャーナルサイズを最低の 8MByte にしたら、aquarius と sagittarius で同時マウントすることが出来なかった。原因は分からないが、デフォルトの 128MByte とする。
2017/05/22 修正ココまで

ディスクは、mbr/gpt パーティションを作らず、そのまま LVM-PV に使用する。

その他諸々の設定は、以下のコマンドから読み取ってくれぃ。

(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(aquarius) $ sudo pvcreate /dev/mapper/kvm001
(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(sagittarius) $ sudo pvdisplay /dev/mapper/kvm001

(aquarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgcreate -c y kvmcluster /dev/mapper/kvm001
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster

(aquarius) $ sudo lvcreate -L 32M -n etc-libvirt kvmcluster
2017/05/22 修正
ジャーナルサイズをデフォルトの 128MByte にする関係で、この領域のサイズは 32MByte では足りなくなる。そのため、1GByte にした。
(aquarius) $ sudo lvcreate -L 1G -n etc-libvirt kvmcluster
2017/05/22 修正ココまで
(aquarius) $ sudo lvcreate -L 80G -n var-lib-libvirt kvmcluster
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster

(aquarius) $ sudo lvchange -asy kvmcluster/etc-libvirt
(aquarius) $ sudo lvchange -asy kvmcluster/var-lib-libvirt

(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:etc-libvirt \
-p lock_dlm \
-J 8 \
-j 2 \
/dev/kvmcluster/etc-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt

(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:var-lib-libvirt \
-p lock_dlm \
-j 2 \
/dev/kvmcluster/var-lib-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt

---

領域を作ったら、今の仮想マシン環境情報を新しい領域に移し、マウントし直す。

(aquarius) $ sudo mkdir /mnt/libvirt

(aquarius) $ sudo mount /dev/kvmcluster/etc-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt

(aquarius) $ sudo -i
(aquarius) # cd /etc
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit

(aquarius) $ sudo umount /mnt/libvirt

(aquarius) $ sudo mount /dev/kvmcluster/var-lib-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt

(aquarius) $ sudo -i
(aquarius) # cd /var/lib
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit

(aquarius) $ sudo umount /mnt/libvirt

(aquarius) $ sudo rmdir /mnt/libvirt

/var/log/libvirt は、専用のボリュームを作らず、/var/log に配置する。
aquarius / sagittarius 両方で実施したいが、sagittarius 上では仮想マシンが稼働しているため、実施できない。
そのため、sagittarius 上では別途実施する。
(aquarius) $ cd /var/log
(aquarius) $ sudo tar cvf libvirt.tar libvirt
(aquarius) $ sudo systemctl stop /var/log/libvirt
(aquarius) $ sudo chmod 755 /var/log/libvirt
(aquarius) $ sudo chown root:root /var/log/libvirt
(aquarius) $ sudo tar xvf libvirt.tar
(aquarius) $ sudo rmdir libvirt/lost+found
(aquarius) $ ls libvirt
(aquarius) $ sudo rm libvirt.tar
(aquarius) $ cd

/etc/libvirt、/var/lib/libvirt のマウント情報を書き換え、/var/log/libvirt のマウント情報を削除する
(aquarius) $ sudo systemctl stop /etc/libvirt
(aquarius) $ sudo systemctl stop /var/lib/libvirt
(aquarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで

(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl start /etc/libvirt
(aquarius) $ grep /etc/libvirt /etc/mtab
(aquairus) $ sudo systemctl start /var/lib/libvirt
(aquarius) $ grep /var/lib/libvirt /etc/mtab

(aquarius) $ ls /etc/libvirt
(aquarius) $ ls /var/lib/libvirt

---

これで、共有領域の作成は完了だ。
(出来ればこのタイミングで、aquarius を再起動して、キチンとマウントされるか確認しておいたほうが良いが…。)

次は仮想マシンを共有領域へ移動、だが、その前に明らかに仮想ディスク領域( /var/lib/libvirt )が足りない。
その為、次回はまず、仮想ディスク領域を拡張する手順を作る。
＃コレ以降、仮想ディスク領域の拡張は、特に書かないツモリ…。

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 に共有用のボリュームを作成するところだ。

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つだ。

• /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

(最後の2つのログファイルは、状態によっては1つだったり2つ以上だったりする。)
(仮想ディスクを多く割り当てていれば、その分 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ファイル)を取り込む前に、そのファイルをカスタマイズすることで、構成が異なる仮想マシンとして取り込むことが可能になる。

デメリット

• 移行対象ファイルの抜け漏れのリスク
  気をつけないと抜け漏れが発生する。
• 停止時間が延びてしまう
  移行開始から移行終了までの時間が長く、途中で切ることが出来ない。
  (連続停止時間が長い)
  業務用途の場合は、この停止時間がビジネス的に致命傷になりかねない。
  その場合は、ディスクの使用効率が悪くなってでも、オンラインストレージマイグレーションを実施するようにすべき。
  オンラインマイグレーションなら、停止時間はほぼゼロだからだ。

次回は、aquarius 上に置いてある仮想マシン環境を、全て sagittairus に移行する。

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 を停止して 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 から停止起動等を確認してみて欲しい。

オンラインストレージマイグレーションは、可能だけど制約がある、ということになったため、次回、オフラインマイグレーションに挑戦してみることにする。
＃しかし、オンラインストレージマイグレーションが出来ることを前提にしていたので、ちょっと厳しくなってきたな…。
＃多分、オフラインも同じ現象になりそうだな…。

ボリューム共有化の前に整理

最後に、sagittarius / aquarius 間で、仮想マシン領域を共有、という流れだけど、その前に今の構成を整理しておきたい。

今は、

• 物理マシンとして 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の単体ボリュームを削除

とまぁこんな感じで考えてみた。
実際に出来るかは分からないが、次回以降、この方向で進めていこうと思う。

続いて CLVM

続いて、CLVM(Clustered LVM) か。

こちらも過去の作業をまとめて記載する。
例によって、プロンプトの前にホスト名が無い場合は、sagittarius / aquarius 両方で共通の作業だ。

まずはパッケージの導入

$ sudo apt-get update
$ sudo apt-get install clvm
$ dpkg -L clvm
$ systemctl --no-pager -l status lvm2-clvmd.service
$ systemctl --no-pager -l status lvm2-cluster-activation.service

lvmconf の変更(これはもしかしたら、起動停止処理の変更の後の方が良かったかも)

$ sudo sudo lvmconf --enable-cluster --services --startstopservices
$ systemctl --no-pager -l status lvm2-clvmd.service
$ systemctl --no-pager -l status lvm2-cluster-activation.service

起動停止処理の変更

$ cd /lib/systemd/system
$ sudo cp -pi lvm2-cluster-activation.service \
lvm2-cluster-activation.service.orig
$ sudo cp -pi lvm2-clvmd.service \
lvm2-clvmd.service.orig

$ sudo vi lvm2-cluster-activation.service
--ココから
After=lvm2-clvmd.service lvm2-cmirrord.service
↓(コメント化して、lvm2-cmirrord.serviceを削除した行を作成)
#After=lvm2-clvmd.service lvm2-cmirrord.service
After=lvm2-clvmd.service

EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd

[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで

$ sudo vi lvm2-clvmd.service
--ココから
EnvironmentFile=-${prefix}/etc/sysconfig/clvmd
↓(コメント化)
#EnvironmentFile=-${prefix}/etc/sysconfig/clvmd

ExecStart=/sbin/clvmd $CLVMD_OPTS
↓(この行はコメントにし、パスを/usr/sbin/clvmdにした行を作成
#ExecStart=/sbin/clvmd $CLVMD_OPTS
ExecStart=/usr/sbin/clvmd $CLVMD_OPTS
--ココまで

設定の反映と起動

$ sudo systemctl daemon-reload

$ systemctl --no-pager -l status lvm2-cluster-activation.service
$ systemctl --no-pager -l status lvm2-clvmd.service
$ sudo systemctl start lvm2-cluster-activation.service
$ systemctl --no-pager -l status lvm2-cluster-activation.service
$ systemctl --no-pager -l status lvm2-clvmd.service

/etc/init.d/clvm の無効化

$ systemctl --no-pager -l status clvm.service
$ systemctl is-enabled clvm.service
$ sudo systemctl disable clvm.service
$ systemctl is-enabled clvm.service
$ systemctl is-active clvm.service
$ systemctl --no-pager -l status clvm.service

$ cd

おしまい。

corosync / dlm / gfs2

というわけで、corosync / dlm / gfs2 か。
この辺からの作業だ。
結構苦労した記憶があるので、今回も手こずるんだろうな…。
記憶を呼び戻しながら、整理しながら記載していくことにする。

まずは corosync の導入。
$ sudo apt-get update
$ sudo apt-get install corosync

$ sudo cp -pi /etc/corosync/corosync.conf \
/etc/corosync/corosync.conf.orig
$ sudo vi /etc/corosync/corosync.conf

一部修正
--ココから
totem {
cluster_name: debian
↓
cluster_name: kvmcluster

interface {
bindnetaddr: 127.0.0.1
↓
bindnetaddr: 192.168.55.0
}
}
quorum {
    (2行追加)
two_node: 1
wait_for_all: 0
}
--ココまで
今回は、クラスタ名を「kvmclulster」にした。かっこ悪いか？

corosync の起動順変更
$ cd /lib/systemd/system
$ sudo cp -pi corosync.service corosync.service.orig

$ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで

$ sudo systemctl daemon-reload
$ sudo systemctl restart corosync.service
$ systemctl --no-pager -l status corosync.service

$ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
$ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓
ExecStart=/bin/sleep 10
--ココまで
$ sudo systemctl daemon-reload
$ cd

dlm の導入だ。
$ sudo apt-get update
$ sudo apt-get install dlm

$ systemctl -l status dlm.service

$ sudo mkdir /etc/dlm
$ sudo bash -c "/usr/sbin/dlm_tool dump_config > /etc/dlm/dlm.conf"
$ cat /etc/dlm/dlm.conf
--以下の内容になっていた
daemon_debug=0
foreground=1
log_debug=0
timewarn=0
protocol=detect
debug_logfile=0
enable_fscontrol=0
enable_plock=1
plock_debug=0
plock_rate_limit=0
plock_ownership=0
drop_resources_time=10000
drop_resources_count=10
drop_resources_age=10000
post_join_delay=30
enable_fencing=1
enable_concurrent_fencing=0
enable_startup_fencing=1
enable_quorum_fencing=1
enable_quorum_lockspace=1
help=-1
version=-1
--ココまで

$ sudo vi /etc/dlm/dlm.conf
--以下の内容
enable_fencing=1
↓この行を以下のように書き換え
enable_fencing=0
--ココまで

$ sudo systemctl restart dlm
$ systemctl --no-pager -l status dlm

$ dlm_tool ls
$ dlm_tool status

gfs2 の導入
$ sudo apt-get update
$ sudo apt-get install gfs2-utils

とりあえずはこんなもんかね。
次は CLVM の導入か…。