リソースの稼働先(優先度)を指定

前回、testip というリソースを作成した。

この testip 、起動時には gemini / cancer のいずれのノードで稼働するかは不定だ。
(どうも、cancer で起動しようとするようだ…。)

これを、

• 通常時は gemini で稼働
• gemini が停止している時は cancer で稼働

という具合に固定化させてみたい。

やり方はそんなに難しくない。
リソースの稼働優先度を付ければいい。
(前回、stonith リソースの稼働先を指定したコマンドとほぼ同じだ。)

まずは testip の停止
$ sudo crm resource show testip
$ sudo crm resource stop testip
$ sudo crm resource show testip

testip のリソースに対して、 gemini:100 cancer:50 の優先度をつける
$ sudo crm configure show
$ sudo crm configure \
location testip_loc testip \
rule 100: \#uname eq gemini \
rule 50: \#uname eq cancer
$ sudo crm configure show
$ sudo crm configure show testip_loc

これで、gemini の方が優先度が高くなったため、gemini が稼働中であれば、testip は gemini で起動してくるはずだ。
試してみよう。
$ sudo crm resource show testip
$ sudo crm resource start testip
$ sudo crm resource show testip

start / stop を繰り返してみたり、cancer のコマンドラインから start を仕掛けてみて、毎回必ず gemini 側で起動することを確認しよう。

gemini 側で起動することが確認できたら、手作業でフェイルオーバー(厳密にはテイクオーバー)させてみよう。
自動的に、cancer 側で動き出すはずだ。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
$ sudo crm configure show
フェイルオーバーさせたら、
location cli-ban-testip-on-gemini testip role=Started -inf: gemini
というルールが追加されたと思う。
前回の解説の通り、「このリソースは gemini では動かさないよ」というものだ。

この状態で、もう一度 migrate 仕掛けてみよう。
$ sudo crm resource migrate testip
$ sudo crm resource show testip
testip は停止している。
$ sudo crm configure show
location cli-ban-testip-on-cancer testip role=Started -inf: cancer
というルールも追加された。
gemini / cancer の2つしかノードが無いので、このルールによって、稼働可能なノードが無くなり、リソース停止になったわけだ。
＃イメージとしては、gemini がシステムダウンをし、cancer 側でサービスを継続していたが、gemini を復旧させる前に cancer もダウンしてしまった、という状態だ。

さて、では元に戻すにはどうすればいい？
単純に起動させてみると…
$ sudo crm resource start testip
$ sudo crm resource show testip
動いていない。

やはり unmigrate なのだろうか？
$ sudo crm resource unmigrate testip
$ sudo crm resource show testip
おっと！gemini で動き出した。
状態は…？
$ sudo crm configure show
追加された2つのルールは削除されている。これによって gemini で稼働し始めたか。

さて今度は、本当に障害を発生させてみよう。
gemini を載せているホストマシン sagittarius から、gemini を強制的に停止させてみる。
これで testip が cancer 側に移ってくれれば、期待した動きと言える。
(sagittarius) $ virsh destroy gemini

10秒ほどで、cancer に移動したようだ。
(cancer) $ sudo crm resource show testip
(cancer) $ sudo crm configure show
っと、例の「gemini では動かしちゃダメだよ」ルールが追加されていない。
crm migrate を実施した時と若干挙動が違うな…。そういうものなのか？

もしかして、gemini が復旧したら、リソースが自動的に gemini に戻る？
確認してみよう。
(sagittarius) $ virsh start gemini
(gemini) $ sudo crm resource show testip
なんと！？gemini 側に戻ってきている！

これはちょっとよろしく無いな…。
プライマリノードがダウンした場合、スレーブノード(待機系)で自動的にサービス再開する、というのはHAクラスタとしては理想の動き。
だけど、プライマリノードが復旧したら、サービスが自動的にプライマリノードに戻る、というのは良くない。
戻る時、スレーブノードでサービスが停止し、プライマリノードでサービスが起動する、という動きになるため、一時的にサービスが止まってしまう。
サービスが止まることが予め予想出来るのなら、業務影響の少ない夜間の特定時間帯に戻す、という要求が出て当然だ。
大抵の業務クラスタはそうなっている。
＃自動フェイルバック禁止、というような表現だ。

さて、その自動フェイルバックを禁止する方法だけど…。
これについては次回にして、今回はココまでにしよう。

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

さて、これまで何度も、仮想マシンが動いているホストを 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 化するのはこれでオシマイ。

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

とりあえず、停止している仮想マシンを共有領域へ移動させることは完了した。
次は残っている稼働中の仮想マシンだ。
(前回 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

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

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

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

dlmのフェンシング(その4:fence_all /bin/true)

続いて、enable_fencing は 1 だけど、fence_all を /bin/true にする形を検証する。
前回と同様、gemini / cancer の /etc/dlm/dlm.conf を書き換えるところから。

(gemini) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=0
↓1に書き戻す
enable_fencing=1

1行追加する。
fence_all /bin/true
--ココまで

cancer も同様に。
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=0
↓1に書き戻す
enable_fencing=1

1行追加する
fence_all /bin/true
--ココまで

どうも、dlm.service の再起動が上手く行かなったので、leo を停止し、gemini / cancer は再起動する。
(leo) $ sudo systemctl poweroff
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot

状態確認だ。
(gemini) $ dlm_tool status
(cancer) $ dlm_tool status
(gemini) $ dlm_tool ls
(cancer) $ dlm_tool ls

前回のテスト前半部分はすっ飛ばして、leo を起動してテストする。

既に gemini 上で leo が動いていると思うので、前回の後半部分、仮想マシンの起動からテストする。
(gemini) $ virsh list --all
(gemini) $ virsh start leo
(gemini) $ virsh list --all

leo にログインし、ping を打ち続ける。
(leo) $ ping 192.168.55.130

leo を cancer へ移動。(今回は sagittarius から実行する。対象ホストに注意。)
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(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.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

gemini を強制再起動
(sagittarius) $ virsh reset gemini
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

(gemini の再起動が確認できたら) leo を gemini に移動。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(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/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

問題無いな…。
というわけで、この設定をそのまま採用しよう。

と思ったけど、dlm_controld がダウンする現象が発生した。
多分、その他のフェンシング設定が関係している気がする…。
enable_fencing=0 の方では発生しないっぽい…。

ちょっと調べたけど分からなかったので、当面は「その3」で記載した方法で進めていくことにする。
将来的に pacemaker を使う時に、もう一度検討することになると思う。

dlmのフェンシング(その3:enable_fencing=0)

というわけで、dlm.conf の enable_fencing を 0 に書き換えて試してみよう。
gemini / cancer の両ノードを起動して、dlm.conf を書き換える。

(gemini) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=1
↓
enable_fencing=0
--ココまで

cancer も同様に。
(cancer) $ sudo vi /etc/dlm/dlm.conf
--ココから
enable_fencing=1
↓
enable_fencing=0
--ココまで

dlm.conf は、dlm.service だけが参照していると思うので、dlm.service の設定を読み直す。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl restart dlm.service
(gemini) $ sudo systemctl status dlm.service

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl restart dlm.service
(cancer) $ sudo systemctl status dlm.service

(gemini) $ dlm_tool status
(cancer) $ dlm_tool status
(gemini) $ dlm_tool ls
(cancer) $ dlm_tool ls

きちんと動いてそうなら、ココと同様にテストしてみる。
ホスト側から cancer の強制停止。
(sagittarius) $ date ; virsh destroy cancer

プロセスの確認
(gemini) $ ps -ef | grep dlm_controld | grep -v grep
プロセスは死んでない。

dlm の状態確認
(gemini) $ dlm_tool status
(gemini) $ dlm_tool ls

共有ファイルシステムの確認
(gemini) $ grep -e /etc/libvirt -e /var/lib/libvirt /etc/mtab
rw モードでマウントされていることを確認。

(gemini) $ sudo bash -c "sync;sync;sync"
(gemini) $ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"

(gemini) $ ls -l /etc/libvirt
(gemini) $ ls -l /var/lib/libvirt
ちゃんと読める。

cancer を起動したら、自動的に組み込まれるか？
(sagittarius) $ virsh start cancer
(gemini) $ dlm_tool status
(gemini) $ dlm_tool ls
自動的に組み込まれた。

どうやら上手く行ってるようだ。
なら今度は、仮想マシンのオンラインマイグレーションを含めた挙動確認してみるか。

流れとしては、

1. gemini 上で leo を起動
2. leo を cancer 上へ移動
3. gemini を強制再起動
4. leo を gemini へ移動

かな？

というわけで、gemini 上で leo を起動。
(gemini) $ virsh list --all
(gemini) $ virsh start leo
(gemini) $ virsh list --all

leo にログインし、ping を打ち続ける。
(leo) $ ping 192.168.55.130

leo を cancer へ移動。(今回は sagittarius から実行する。対象ホストに注意。)
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(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.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

gemini を強制再起動
(sagittarius) $ virsh reset gemini
(cancer) $ dlm_tool status
(cancer) $ dlm_tool ls

(gemini の再起動が確認できたら) leo を gemini に移動。
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all
(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/
(sagittarius) $ virsh -c qemu+ssh://192.168.55.136/system list --all
(sagittarius) $ virsh -c qemu+ssh://192.168.55.137/system list --all

全然問題無さそうだ。

enable_fencing=0 のパターンはコレで終了かな？
次回は、enable_fencing=1 and fence_all /bin/true を試してみよう。

コマンドラインでのマイグレーション

前回までで、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 のフェンシング」について、詳細確認することにしよう。
多分かなり時間がかかると思う。

スナップショットを使おう その5(内部スナップショットの破棄-停止状態)

というわけで、スナップショットの破棄のパターンをテストしてみる。

これまで色々いじってきた内容と基本的には被るわけだが、整理だと思ってくれい。
とりあえず、内部スナップショット-停止状態のパターンを書く。

piscesが稼動していたら停止させよう
(aquarius) $ virsh list --all

内部スナップショットの作成だ。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1.....
(aquarius) $ virsh snapshot-list pisces

piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all

仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2

piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1

piscesのスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh list --all
停止した状態でスナップショットを作成したので、停止した状態に戻るかと思ったんだが、起動したままになっている。

スナップショットの状態を確認
(aquarius) $ virsh snapshot-list pisces
スナップショットは削除されている。

piscesのファイルの状態は？
(pisces) $ ls -l 1
スナップショット作成後に作成したファイル、残っている。

ということは、この手順は、スナップショットは消えるが、スナップショットに対して行った作業は、ベースのディスクに反映されるってことか。

手順間違えた。もう一度実施だ。
まずは、pisces上のごみファイル(1)を削除する。
(pisces) $ rm 1
(pisces) $ ls -l

piscesはシャットダウンしておく。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh list --all

もう一度、内部スナップショットを作成する。(piscesにスナップショットが無いことが前提だ。)
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1
(aquarius) $ virsh snapshot-list pisces

piscesを起動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all

仮想ディスクの状態の確認
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2

piscesにダミーファイルを作成してみる。
(pisces) $ touch 1
(pisces) $ ls -l 1

piscesをスナップショットまで戻してみる。
(aquarius) $ virsh snapshot-revert --domain pisces pisces-1
(aquarius) $ virsh list --all
この時点で、piscesは停止する。(もともと停止状態で取得したスナップショットに戻ったわけだから、正常な挙動だ。)

スナップショットの確認
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは残っている。

この状態でスナップショットを削除する。
(aquarius) $ virsh snapshot-delete --domain pisces pisces-1
(aquarius) $ virsh snapshot-list pisces
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
スナップショットは削除された。

本当に元に戻ったか、piscesを起動して確認だ。
(aquarius) $ virsh start pisces
(pisces) $ ls -l 1
ファイルが存在していない。スナップショット取得前に戻った状態だ。

これで、

• スナップショットを破棄する。(スナップショット取得前に戻す。)
• スナップショットは停止状態で取得する。
• スナップショット形式は「内部スナップショット」。

のパターンの検証と手順の確立は完了だ。

次は、同様のパターンで「起動状態でスナップショットを取得する」の手順の確立を実施してみたい。

と、途中まで書いていたが、ちょっとスナップショット関連は停止。
まだまだ色々やりたいことがあるので、色んなことやってく過程で、またスナップショットは記載する。

スナップショットを使おう その4(仮想マシンスナップショットの目的整理)

スナップショット、色々試しているけど、ちょっと混乱してきた。
というわけで、まずはスナップショットを使う目的を整理しよう。

1. ソフトウェアの導入検証
2. ソフトウェア・OSのバージョンアップ検証
3. ソフトウェア・OSの設定変更検証
4. 同一ソフトウェアの異なるバージョンの検証

が主目的ではないだろうか？

1～3までは、「スナップショット作成→検証→元に戻す」を繰り返し、納得がいく状態になったらコミットする、という流れになる。
通常であれば、「バックアップ→検証→リストア」という手順になるが、バックアップおよびリストアは結構手間がかかる。それに比べ、仮想環境で取得可能なスナップショットは非常に短い時間、少ない手間で処理できるので、とても便利だ。

4は、「あるベースイメージから複数のスナップショットを作成→それぞれのスナップショットに異なるバージョンのソフトウェアを導入・検証→元に戻す」を繰り返し、問題ないバージョン(スナップショット)をベースイメージにコミットする、ということになるかと思う。
4に関しては、「ベースイメージを複数コピー→検証→破棄」という流れでも実施可能だ。このパターンなら、複数の仮想マシンに分かれるので、IPアドレス等がバッティングしなければ、同時に複数の仮想マシンを起動可能だ。
ただし、IPアドレスの変更は意外と影響範囲が大きく、思わぬところで躓く可能性があるため、十分注意する必要があるだろう。

というわけで、まずは1～3を目的としたスナップショットの操作手順をおさらいしていこう。

図にすると以下のような感じだ。

スナップショットの破棄パターン

スナップショットのコミットパターン

次回以降にそれぞれ記載していく。

今回はここまで。

スナップショットを使おう その3

というわけで、今回はスナップショットの差分情報を仮想ディスクの内部ではなく、外部に持てないか？という検証。
(VMware Workstation ProやESXiと同じような。)

とりあえず、まだスナップショットが残っていると思うので、削除しておこう。
(aquarius) $ virsh snapshot-delete pisces pisces-1

仮想ディスクにスナップショットの情報が残ってないことを確認しておこう。
(aquarius) $ virsh vol-info pisces.qcow2 default
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2
(aquarius) $ virsh snapshot-list pisces

では、ベースとなる仮想マシンを稼動させよう。
(aquarius) $ virsh start pisces
(aquarius) $ virsh list --all

スナップショットを作成する前に、pisces上にダミーファイルを一つ作っておこう。
(pisces) $ touch snap-1

さて、この状態でスナップショットを作るのだが、メモリ情報やディスクのスナップショット情報を外出しにするにはどうすればいいのだろうか？
どうやら、メモリ情報を外出しにするには--memspecというオプション、ディスクは--diskspecというオプションらしい。しかも、--diskspecでファイルをスナップショットファイルを指定する場合、フルパスでないといけないようだ。(メモリは相対パスでもいける)
どこに配置するのが綺麗なのか判らないので、とりあえず仮想ディスクファイルが存在する場所を指定する。
(aquarius) $ virsh snapshot-create-as \
--domain pisces \
--name pisces-1 \
--memspec file=/var/lib/libvirt/images/pisces-1.mem,snapshot=external \
--diskspec vda,snapshot=external,file=/var/lib/libvirt/images/pisces-1.vda.qcow2

これで作れたっぽい。
確認してみよう。
(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.mem
-rw------- 1 root root 183578840 12月 4 18:51 /var/lib/libvirt/images/pisces-1.mem

(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 198144 12月 4 18:51 /var/lib/libvirt/images/pisces-1.vda.qcow2

それぞれファイルが出来上がっている。

メモリファイルの方をチェック。
(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.mem
/var/lib/libvirt/images/pisces-1.mem: Libvirt QEMU Suspend Image, version 2, XML length 3980, running

QEMU Suspend Imageとなっているってことは、仮想マシンを一時的にSuspend状態にして、その瞬間のメモリ情報が格納されているんだろうな。
ってことは、もしかしたら単純に仮想マシンをSuspendさせる時も、同じように--memspecオプションがあるかも。後日調べてみよう。

仮想ディスクファイルのチェック。
(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.vda.qcow2
/var/lib/libvirt/images/pisces-1.vda.qcow2: QEMU QCOW Image (v3), has backing file (path /var/lib/libvirt/images/pisces.qcow2), 77309411328 bytes

backing fileとして、元の仮想ディスクファイルが指定されている。
ということはきっと、元の仮想ディスクファイル(pisces.qcow2)からの差分情報が、このファイル(pisces-1.vda.qcow2)に格納されているんだろう。

だとすれば、仮想マシンの定義と、メモリファイル、ベースとなっている仮想ディスクファイル(pisces.qcow2)をバックアップしたら、仮想マシンそのもののバックアップになるのだろうか？
これも後日確認だな。

スナップショットの定義確認。
(aquarius) $ virsh snapshot-info pisces pisces-1
名前: pisces-1
ドメイン: pisces
カレント: はい (yes)
状態: running
場所: 外部
親: -
子: 0
子孫: 0
メタデータ: はい (yes)

お、「場所」の項目が「外部」になっているから、期待した動きのようだ。

前回と同様、仮想ディスクファイル(元の仮想ディスクファイル)を確認してみる。
(aquarius) $ virsh vol-info pisces.qcow2 default

スナップショットの情報は出てこなかった。

qemu-imgコマンドでも確かめてみる。
(aquarius) $ sudo qemu-img snapshot -l /var/lib/libvirt/images/pisces.qcow2

何も出てこない。

ってことは、元の仮想ディスクファイルには、スナップショットの情報は記録されておらず、新しい差分ファイル(pisces-1.vda.qcow2)の方にのみ、情報が記録されているってことだな。

一応、差分ファイルの方をqemu-imgコマンドで確認してみよう。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.vda.qcow2
image: /var/lib/libvirt/images/pisces-1.vda.qcow2
file format: qcow2
virtual size: 72G (77309411328 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/pisces.qcow2
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false

backing fileの定義がある。やっぱりそうみたいだ。

ついでに、仮想メモリファイルの方も確認してみよう。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.mem
image: /var/lib/libvirt/images/pisces-1.mem
file format: raw
virtual size: 175M (183579136 bytes)
disk size: 175M

ん？今、piscesにはメモリ128MByteしか割り当てて無いはずだから、175Mってのはちょっと大きいな…。何でやろ？

続いて、仮想マシンの定義を見てみよう。
(aquarius) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

仮想ディスクが、pisces-1.vda.qcow2になって、そのbackingStoreとして、pisces.qcow2と定義されている。

pisces-1.vda.qcow2が更新され、今まで使ってたpisces.qcow2は更新されずに参照のみ、ということになるんだろう。

ファイルの状態を見てみる。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu 3525 f.... (libvirt-qemu)qemu-system-x86

(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces-1.vda.qcow2:
libvirt-qemu 3525 F.... (libvirt-qemu)qemu-system-x86

pisces.qcow2の方は、ACCESSフラグが"f"で、pisces-1.vda.qcow2の方のACCESSフラグは"F"だ。

man fuserによると、
f open file. f is omitted in default display mode.
F open file for writing. F is omitted in default display mode.
とのことで、やはりpisces.qcow2の方はread onlyなのだろう。

さて、では作ったスナップショットを消してみよう。
(aquarius) $ virsh snapshot-delete pisces pisces-1
エラー: スナップショット pisces-1 の削除に失敗しました
エラー: サポートされない設定: 1 個の外部ディスクスナップショットの削除はまだサポートされていません

おや？削除できない。
ディスクを外部に持たせたタイプのスナップショットは削除できないのか？それじゃスナップショットのメリットが無いなぁ。

だったら、スナップショットに戻すのは？
(aquarius) $ virsh snapshot-revert pisces pisces-1
エラー: サポートされない設定: revert to external snapshot not supported yet

あらま、これもサポートされないって…。

どうやら、外部ディスクにスナップショットを取得していた場合は、スナップショットを削除するには--metadataというオプションが必要らしい。
(aquarius) $ virsh snapshot-delete pisces pisces-1 --metadata
ドメインのスナップショット pisces-1 が削除されました

本当に削除されたのだろうか？
(aquarius) $ virsh snapshot-list pisces
名前 作成時間 状態
------------------------------------------------------------

何もリストに出てこない。無事に削除されたようだ。

スナップショットが削除されたのなら、外部スナップショットファイルとメモリファイルはどうなった？
(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.mem
-rw------- 1 root root 183578840 12月 4 18:51 /var/lib/libvirt/images/pisces-1.mem

(aquarius) $ sudo ls -l /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 198144 12月 4 18:51 /var/lib/libvirt/images/pisces-1.vda.qcow2

どちらも存在している。削除はされないようだ。

ファイルの定義も確認しておくが…変わってないようだ。
(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.mem
/var/lib/libvirt/images/pisces-1.mem: Libvirt QEMU Suspend Image, version 2, XML length 3980, running

(aquarius) $ sudo file /var/lib/libvirt/images/pisces-1.vda.qcow2
/var/lib/libvirt/images/pisces-1.vda.qcow2: QEMU QCOW Image (v3), has backing file (path /var/lib/libvirt/images/pisces.qcow2), 77309411328 bytes

ファイルのオープン状態は？
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces-1.vda.qcow2:
libvirt-qemu 3525 F.... (libvirt-qemu)qemu-system-x86

Read/WriteモードでOpenしているようだ…な。

(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu 3525 f.... (libvirt-qemu)qemu-system-x86

ベースファイルの方は、Read Onlyか…。この辺りも変わってないな。

(aquarius) $ sudo fuser -fv /var/lib/libvirt/images/pisces-1.mem
あれ？こちらは誰もOpenしていない。

(aquarius) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

相変わらず、外部スナップショットファイルを使用しているように見えるぞ。
う～ん。ちょっと期待した動作と違うなぁ…。

一応、qemuコマンドで確認してみる。
(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.vda.qcow2
image: /var/lib/libvirt/images/pisces-1.vda.qcow2
file format: qcow2
virtual size: 72G (77309411328 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/pisces.qcow2
backing file format: qcow2
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false

(aquarius) $ sudo qemu-img info /var/lib/libvirt/images/pisces-1.mem
image: /var/lib/libvirt/images/pisces-1.mem
file format: raw
virtual size: 175M (183579136 bytes)
disk size: 175M

変わったようには見えないなぁ。

ちょっとpiscesにダミーファイルを作って、先に作ったダミーファイルを削除してみるか。
(pisces) $ touch hogefuga
(pisces) $ rm snap-1

仮想ディスクファイルのタイムスタンプはどうなった？
(aquarius) $ date; sudo ls -l /var/lib/libvirt/images/pisces.qcow2 /var/lib/libvirt/images/pisces-1.vda.qcow2
2016年 12月 4日 日曜日 19:04:31 JST
-rw------- 1 libvirt-qemu kvm 458752 12月 4 19:04 /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 2917203968 12月 4 18:51 /var/lib/libvirt/images/pisces.qcow2

外部スナップショットファイルの方が更新されたな。

じゃぁこの状態でpiscesを停止してみる。
(pisces) $ sudo shutdown -h now

停止したら、仮想ディスクのタイムスタンプをもう一度確認してみる。
(aquarius) $ date; sudo ls -l /var/lib/libvirt/images/pisces.qcow2 /var/lib/libvirt/images/pisces-1.vda.qcow2
2016年 12月 4日 日曜日 19:05:45 JST
-rw------- 1 root root 3276800 12月 4 19:05 /var/lib/libvirt/images/pisces-1.vda.qcow2
-rw------- 1 libvirt-qemu kvm 2917203968 12月 4 18:51 /var/lib/libvirt/images/pisces.qcow2

やっぱり、外部スナップショットの方が更新された。
どうやら、一度外部スナップショットファイルを作成すると、基本的にはソレが更新対象になるようだ。
スナップショットを削除しても、ベースの方にI/Oが行われるようになるわけではないようだ。

念のため、piscesの定義も確認してみる。
(aquarius) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

piscesが停止していると、<backingStore>定義が見えなくなるのか…。

う～ん。再びpiscesを起動してみるか…。
(aquarius) $ virsh start pisces

さっき作成したダミーファイルは残っているんかいな？
(pisces) $ ls hogefuga
存在しているねぇ。

もう一度、ディスク定義を見てみる。
(pisces) $ virsh dumpxml pisces
(一部抜粋)
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/home/uramoto/pisces-1.vda.qcow2'/>
<backingStore type='file' index='1'>
<format type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
</backingStore>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

やっぱり、pisces.qcow2とpisces-1.vda.qcow2の両方を使っているように見えるなぁ。

もう一度、ディスクの使用状況を…。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces-1.vda.qcow2:
libvirt-qemu 3820 F.... (libvirt-qemu)qemu-system-x86
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu   3820 f.... (libvirt-qemu)qemu-system-x86

変わってない…。う～ん…。

piscesを停止させてから考えよう…。
(pisces) $ sudo shutdown -h now

なんか、virsh restoreってのがあるみたいだけど、これ使うとどうなるんやろ？
(aquarius) $ virsh restore /var/lib/libvirt/images/pisces-1.mem
ドメインが /var/lib/libvirt/images/pisces-1.mem から復元されました

ちょっ、マジか…。
普通に起動してスナップショットを取得した瞬間の状態になった！

ちょっとログインして、ダミーファイルを確認してみよう…。
(pisces) $ ls hogefuga snap-1
スナップショットを取得する前に作成したファイル(snap-1)は残ってて、スナップショット作成後に作ったファイル(hogefuga)は存在していない！
スナップショットを取った瞬間に戻った…のか？

例によって、ファイルのオープン状態を確認してみよう。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces-1.vda.qcow2
オープンされていない。
(aquarius) $ sudo fuser -fuv /var/lib/libvirt/images/pisces.qcow2
USER PID ACCESS COMMAND
/var/lib/libvirt/images/pisces.qcow2:
libvirt-qemu   3915 F.... (libvirt-qemu)qemu-system-x86

オープンされてる。しかもR/Wモードだ。

メモリファイルの方は…
(aquarius) $ sudo fuser -fv /var/lib/libvirt/images/pisces-1.mem

オープンされてない。

仮想マシンの構成情報は？
(aquarius) $ virsh dumpxml pisces
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
<backingStore/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

元に戻ってる！！！

piscesを一回停止させて、もう一度起動したら、どの状態になるんだろう？
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh dumpxml pisces
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>

あ…あれ？…？？？どういうことだ？？？
外部スナップショットファイルが指定されてる…ぞ？
ベースのファイルが更新されているから、これだと起動しないんじゃないか？

(aquarius) $ virsh start pisces
立ち上がってくるなぁ…。
普通に立ち上がってくるし、ダミーファイル(hogefuga)も存在している。
良く分からんぞ…。
(これ、たまたま起動したんだと思う。ベースファイルが大きく書き換わっていた場合、差分ファイルとの整合性が合わなくなる。ベースファイルの更新が少なかったから、なんとかなったのではないだろうか？)

さっきの流れ的には、多分メモリファイルから復帰させた後、構成ファイルを書き換えれば完全に元に(スナップショット前に)戻せるだろう。
とりあえずそれをやってみよう。
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh restore /var/lib/libvirt/images/pisces-1.mem
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh edit pisces
<source file='/var/lib/libvirt/images/pisces-1.vda.qcow2'/>
↓
<source file='/var/lib/libvirt/images/pisces.qcow2'/>
(aquarius) $ virsh start pisces
(aquarius) $ virsh dumpxml pisces
(pisces) $ sudo shutdown -h now
(aquarius) $ virsh dumpxml pisces
(aquarius) $ sudo rm /var/lib/libvirt/images/pisces-1.mem /var/lib/libvirt/images/pisces-1.vda.qcow2

これで、元に戻ったかな？

今回の実験は、色々な情報がモリモリになっていて、自分でもちょっと理解し切れていない。
一旦はここで切って、次回、情報を整理したい。

というわけで今回は以上。