リソースが勝手に再起動する

謎な挙動が2つ見つかっているが、そのうち1つが「vm-leo が稼働してない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう」というものだ。

vm-leo が sagittarius で稼働している状態で、leo にログインしたセッションを作り、sagittairus/aquarius のいずれかで以下のコマンドを実行するとわかる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

で、どのタイミングで vm-leo が再起動するのかを調べるために、以下のように設定した。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

つまり、aquarius では、vm-leo 以外のすべてのリソースの自動起動を停止した。
(vm-leo 自体は、前提となる pool-default-clone が起動しないと起動しないし、そもそも sagittarius 上で起動しているので、aquarius が起動しても影響ないはずなのだが…)

その状態で、まず aquarius のクラスタの停止・起動を実行する。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

なんと、aquarius のクラスタ起動だけで、vm-leo が再起動してしまう。

ということは、クラスタパラメータが関係しているということだ。

$ sudo pcs property show --all

それっぽいパラメータは、enable-startup-probes か。
デフォルト値は true なので、 false に設定してみよう。

$ sudo pcs property set enable-startup-probes=false
$ sudo pcs property show --all

これで aquarius のクラスタ停止・起動を実行してみる。

$ sudo pcs cluster stop aquarius
$ sudo pcs cluster start aquarius

vm-leo は再起動しなかったと思う。

続いて、リソースを一つずつ許可してみよう。
まずは dlm-clone

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY

大丈夫のようだ。
次は clvmd-clone

$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

ここで vm-leo が再起動してしまう。
更に先を確認するために、vm-leo が復帰したら、shared-pool-clone も確認しておこう。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

ここでも vm-leo が再起動してしまう。
最後に、pool-default-clone だ。vm-leo が復帰してから試してみよう。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

ここでは vm-leo の再起動は発生しない。

vm-leo の基盤となるリソースのうち、clvmd-clone と shared-pool-clone のリソースが起動すると、vm-leo が再起動する。

corosync.log をチェックしてみたら、clvmd-clone が起動すると、なぜか pool-default-clone と vm-leo が restart していた。
clvmd-clone と pool-default-clone の間には、shared-pool-clone が入っているが、そちらは restart になっていない。
う～ん。ということは、clone リソースに何か違いが？
と調べてみたら、いくつか違いがあった。

• dlm-clone
• interleave=true
• ordered=true
• clvmd-clone
• interleave=true
• ordered=true
• shared-pool-clone
• interleave=true
• ordered=(未設定:false)
• pool-default-clone
• interleave=(未設定:false)
• ordered=(未設定:false)

コレ、clone リソース固有のパラメータのようだ。
っていうか、interleave パラメータが関係あるんじゃないか？
というわけで設定してみよう。

$ sudo pcs resource update pool-default-clone meta interleave=true
$ sudo pcs resource show pool-default-clone

そしてもう一度テスト。

$ sudo pcs constraint location pool-default-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location shared-pool-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location clvmd-clone prefers aquarius=-INFINITY
$ sudo pcs constraint location dlm-clone prefers aquarius=-INFINITY

$ sudo pcs constraint remove location-dlm-clone-aquarius--INFINITY
$ sudo pcs constraint remove location-clvmd-clone-aquarius--INFINITY

先程はここで vm-leo が再起動してしまったが、今回は大丈夫のようだ。

$ sudo pcs constraint remove location-shared-pool-clone-aquarius--INFINITY

今回、ここでも大丈夫のようだ。

$ sudo pcs constraint remove location-pool-default-clone-aquarius--INFINITY

こちらは問題なし。

というわけで、interleave=true の設定が必要だった。
振り返って過去の設定を見てみたら、ちゃんと interleave=true の設定を入れていた。
ちゃんと設定項目の意味を理解してれば、こんなに悩まなかったのに…。

リソースが勝手に再起動する問題はこれで解決かな？

仮想マシンのクラスタリソース化その2

とりあえず vm-leo が動くところまで行った。
今度はこのリソースを細かく設定する。

まず、リソースの実行順。
vm-leo 自体は、default プールを使用している。そのため、vm-leo の起動の前提条件として、 default プールの有効化、つまり pool-default-clone を前提にする必要がありそうだ。
それを設定する。

$ sudo pcs constraint order start shared-pool-clone then vm-leo

続いて、リソースの実行条件。
当然、shared-pool の起動に成功したノードと同じノードでないと、vm-leo を動かすわけにはいかない。
その制約をつける。

$ sudo pcs constraint colocation add vm-leo with shared-pool-clone

このままでもいいんだけど、何故かいつも aquarius から起動しようとしてしまう。
gemini/cancer でクラスタ組んで、簡単なリソーステストを行っていた時も、 gemini をプライマリノードにしたいのに、なぜか cancer から起動しようとしてた。
多分、ノード名のアルファベット順で若い方を優先してしまうのではないか？と思っている。
で、vm-leo は sagittarius をプライマリノード、aquarius をスレーブノードとして定義したい。
(sagittarius に問題が無ければ sagittarius で起動、問題がある場合は aquarius で起動、みたいな)
以下のように実行する。

$ sudo pcs resource cleanup vm-leo
$ sudo pcs constraint location vm-leo prefers sagittarius=100 aquarius=50
$ sudo pcs resource enable vm-leo
$ sudo pcs status

どうだろう？ vm-leo は sagittarius で起動してきたのではないだろうか？

今回は一旦ココまでにするが、まだ問題が2つ残っている。

1. vm-leo が稼働していない方のノードのクラスタを停止・起動すると、vm-leo が再起動してしまう
2. vm-leo が稼働しているノードを再起動しようとすると、dlm がハングしてしまう

の2点だ。
ちょっと調べたがまだ解決していない。
解決できるか分からないが、次回からちょっと調査をする。

ホスト側のpacemaker化の前に

pacemakerでgfs2を運用する方法がある程度見えてきたので、メインマシンのホスト(sagittarius/aquarius)のpacemaker化を進めたい。
が、その前にやっておかなきゃいけないことがある。

今、KVMホストであるsagittarius/aquariusの2台は、/etc/libvirtと/var/lib/libvirtの2箇所をgfs2で共有している。
が、調べてみたら/etc/libvirtはやはり、共有化してはいけないことが分かった。

というわけで、両サーバとも/etc/libvirtをローカル化(内蔵ディスク化)することにする。
サイズは1GBもあれば十分。
空き領域を確認する。
$ sudo vgdisplay vg-root
Free PE / Size が数十GB空いていればOKだ。(システムバックアップ取得のために、スナップショット領域を必要とするので、1GBきっちりしか空いてなかったらダメだぞ)

$ sudo lvcreate -L 1G -n lv-etc-libvirt vg-root
$ sudo mkfs.ext4 /dev/vg-root/lv-etc-libvirt
暫定のマウントポイントを作成する。
$ sudo mkdir /mnt/libvirt
マウント
$ sudo mount /dev/vg-root/lv-etc-libvirt /mnt/libvirt

そしたら、ファイルをコピーする。
$ cd /etc
$ sudo tar cSf - libvirt | (cd /mnt ; sudo tar xSf -)
$ sudo ls -alR /etc/libvirt > /tmp/etc-libvirt-gfs2.list
$ sudo ls -alR /mnt/libvirt > /tmp/etc-libvirt-ext4.list
$ diff -w /tmp/etc-libvirt-gfs2.list /tmp/etc-libvirt-ext4.list
ディレクトリのサイズ差が若干あるのは、gfs2とext4のファイルシステムの違いによるものだ。lost+foundの有無も同様。

ファイルコピーが終わったら、一時マウントを解除し、暫定マウントポイントを削除する。
$ sudo umount /mnt/libvirt
$ sudo rmdir /mnt/libvirt

続いて、既存の/etc/libvirtをアンマウントし、/etc/fstabを書き換え、新しい/etc/libvirtをマウントする。
$ sudo systemctl stop /etc/libvirt
$ sudo vi /etc/fstab
-----
/etc/libvirtのマウント行をコメント化し、以下の行を追加する。
/dev/mapper/vg--root-lv--etc--libvirt /etc/libvirt ext4 defaults 0 2
-----

マウントする
$ sudo systemctl daemon-reload
$ sudo systemctl start /etc/libvirt
$ df /etc/libvirt
$ grep /etc/libvirt /etc/mtab
新しいファイルシステムの方(vg-rootの方)がマウントされていたら、念の為libvirt-binをリロードする。
$ sudo systemctl reload libvirt-bin
$ virsh list --all

システムバックアップの対象ボリュームが増えたので、定義ファイルを追加しておく。
$ sudo -i
# cd ~/backup/etc/fsconfig
# vi 0030_lv-etc-libvirt
-----
#
# USELVM:
# Area to be backed up or LVM region, simple partition of the flag.
# Specify a Yes in the case of LVM of LVOL area.
#
USELVM=Yes

#
# VOLNAME:
# You want to specify the volume device name of the target volume.
# For simple partition, sda1 and sda2 like.
# You can easily find LVM of LVOL area, specify the LVOL name (lvol1, etc.).
#
VOLNAME=lv-etc-libvirt

#
# MOUNTPOINT:
# Specify the mount point of the target area.
#
MOUNTPOINT=/etc/libvirt

#
# SNAPSIZE:
# If the area of interest was the LVM region, we want to create
# a LVM Snapshot.
# It will specify the capacity of the Snapshot area.
# ex.
#   SNAPSIZE=32M
#   SNAPSIZE=320M
# If you specify a larger size than the capacity of the backup target,
# it will be the same capacity as the size of the backup target.
#
SNAPSIZE=32M
-----

定義ファイルが作成できたら、バックアップを取っておこう。
# cd ~/backup/bin
# ./0000_backup
# exit

sagittarius/aquariusの両方で実施すること。
kvmclusterの方のetc-libvirt(旧/etc/libvirt)は念のために暫く残しておこう。

この後は、sagittarius/aquairusにpacemakerを導入し、gfs2をpacemakerで運用するための設定だ。
そして、1804へのアップグレードも控えている。
うまく進むといいけどな。

あれ？libvirt-binとか、pacemakerのリソースにしないとアカン？

gfs2をpacemakerで使用するための前提を色々調査していたけど…。

gfs2を複数ノードで使用するためには、clvmdとdlmが必要。

gfs2はKVMの仮想ディスク領域で使用。

ということは、KVMの構成要素であるlibvirt-binとかもpacemakerのクラスタリソースに入れて、gfs2より後に起動しないとアカンのかな？

いや、でも仮想マシンが起動していない限り、特に仮想ディスク領域を使用している様子は無いな…。

pacemakerのリソースには入れずに実行してみて、ダメだったらリソースに入れるか。

gpuパススルー

ゲストにWindows10を導入し、ホストにPCI-Eで接続しているグラボ(nVidia GeForce GTX 1060)をPCIブリッジでゲストに渡し、ゲストのWindows10で3Dゲームとか楽しもうと思ってる。
で、色々試してたんだけど、結局NGだった。

とりあえず、
https://uramocha02.blogspot.jp/2017/01/pciiommu.html
https://uramocha02.blogspot.jp/2017/01/pcigpu.html
https://uramocha02.blogspot.jp/2017/01/pci.html
この辺りの作業の後、以下の作業を実施。
---------------------------------------
/etc/modules に以下の行を追加
--内容
#PCI pass through
pci_stub
vfio-pci
--ココまで

/etc/modprobe.d/vfio.conf を新規作成
--内容
options vfio-pci ids=10de:1c03,10de:10f1,1912:0014
--ココまで

lsmod | grep -i vfio
dmesg | grep -i vfio
lspci -nnk -d 10de:1c03
lspci -nnk -d 10de:10f1

vi /etc/initramfs-tools/modules
--
pci_stub ids=10de:1c03,10de:10f1,1912:0014
--
lspci -nnk -d 1912:0014
---------------------------------------
それでも、上手くゲストにブリッジ出来ずに悩んでた。

で、どうやら、nVidiaのグラボをPCIパススルーするためには、libvirtのバージョンが1.3.3以上でないとダメのようだ。(AMDのグラボなら可能っぽい)
Ubuntu 16.04 の libvirt は 1.3.1 のようなので、微妙に機能が足りない。

新しい libvirt をビルドするという手もあるし、Ubuntu 18.04 を待たずに、17.10 にアップグレードするという手もあるにはあるけど、18.04 はあと3ヶ月弱でリリースなので、それまで待つことにしよう…。

ちなみに、参考にしてた URL は以下。
Re: [vfio-users] No Signal: GTX 680 or GTS 450 on passthrough
Re: [vfio-users] No Signal: GTX 680 or GTS 450 on passthrough
ハイパーバイザの作り方～ちゃんと理解する仮想化技術～ 第１５回 PCIパススルーその１「PCIパススルーとIOMMU」
Libvirt: Domain XML format
QEMU-KVMでGPUと光学ドライブをパススルーしてWindowsゲストを快適に走らせる
GPU passthrough: gaming on Windows on Linux
HOW-TO make dual-boot obsolete using kvm VGA passthrough
Linux and Windows running simultaneously with GPU passthrough
PCI passthrough via OVMF
Ubuntu日本語フォーラム / ubuntu14.04上にlibvirt1.3.3 以上をインストールしたい。

Ubuntu 18.04 がリリースされたら、もう一度見直して挑戦しよう。

Windows ゲストの CPU 使用率

ずっと気になっていたことがある。
Windows ゲストを使用していると、ゲストのタスクマネージャで見る限りぜんぜん CPU を使っていないのに、ホスト側で top を実行すると CPU 消費率が高い、という状態が続いてた。
色々な原因はあるけど、どうやらゲストの定義に
<input type='tablet' bus='usb'/>
というのがあると、USB ポーリングが激しく動いて、ホスト側から見た kvm プロセスの CPU 消費が高くなる、らしい。

virt-manager 等でゲストを作る時、ゲストOSにWindowsを指定するとデフォルトで入る定義のようだ。
但し、この定義を消してゲストを起動すれば、CPU使用率は落ち着くが、virt-viewer/Remote viewer でマウスカーソルの動きがおかしくなるようだ。

で、いつも使っているゲスト:pegasus(Windows 7)もこの設定が入っている。
このゲストで試してみようと思う。

まずは、設定が入っているかを確認。
(sagittarius) $ virsh dumpxml pegasus | grep tablet

設定が入っているのを確認したら、そのままゲストを起動する。
(sagittarius) $ virsh start pegasus

合わせて、top コマンドで CPU 使用率を見てみよう。
(sagittarius) $ top -d 1
(終了させるには、キーボードから q を入力すればいい)

起動したら、端末側の Remote viewer で接続してみよう。

Windows ゲストにログオンしていないウチは、ホストから見たゲストの CPU 使用率は 20%弱のようだ。(sagittarius は 8論理CPU なので、全体では2%～3%程度)
ところが、Windows ゲストにログオンすると、途端にCPU使用率が100%を超える。
Windows としては何のアプリ起動せず、全然負荷をかけていないにも関わらず、だ。

では、先程の <input type='tablet' bus='usb'/> を消したらどうなるだろう？

Windows ゲストをシャットダウンさせ、実際に消してみよう。
(sagittarius) $ virsh shutdown pegasus
(sagittarius) $ virsh edit pegasus
--
<input type='tablet' bus='usb'/>
の行を消す
--

削除が終わったら、先程と同様に起動とCPU使用率の確認だ。
(sagittarius) $ virsh start pegasus
(sagittarius) $ top -d 1

先程は、ログオン前で大体20%程消費していたCPUが、今度は10%前後まで落ちたようだ。(時々跳ね上がるが…)
ログオンしてみるとどうだろうか…。
CPU 使用率は少し下がった。100%をちょっと下回る状態だ。(時々、100%を超えるが…)
但し、Remote Viewer にフォーカスを当てたマウスカーソルが、マウス操作だけではフォーカスを外すことが出来なくなり、更に ゲストWindows 内のマウスカーソルと、端末側のマウスカーソルの2重表示になってしまった。
(フォーカスを外すには、左Ctrl＋左Alt の同時押し)

Remote Viewer をフルスクリーン表示してみたらどうだろうか…。
やはり、マウスカーソルの2重表示が消えない。
ちょっと使いにくいが、コンソールを使うことってあまり無さそうだから大丈夫かな？

試しに、リモートデスクトップ接続で CPU 使用率等を確認してみよう。
…う～ん。CPU 使用率は 100% を少し上回るなぁ。
あまり改善された感じはしないけど、少しはマシか…。

頻繁に使う pegasus はこのままにして、他の Windows ゲスト定義は <input type='tablet' bus='usb'/> の定義は残しておくことにしよう…。

--2020/11/17追記
どうやら、別の宣言で解決できそうだ。
とりあえずコチラに記載しておいた。

新仮想マシン virgo 誕生！

更に実験をすすめるため、新たな仮想マシン virgo を作成した。
構成は leo と同じ。
配置は、sagittarius / aquarius クラスタではなく、その上で稼働している gemini / cancer の上だ。
これも leo と同じ。
OS も leo と同じ、Ubuntu 16.04 だ。
物理マシン sagittarius / aquarius をセットで操作、仮想マシン gemini / cancer をセットで操作するのと同じように、仮想マシン上の仮想マシン leo / virgo をセットで動かす想定だ。
サクッと作って、まずは普通に動くようにしてくれ。

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 上の不要ボリュームの整理等を行う。

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 へ(ストレージマイグレーション)

さて、では実際に 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の単体ボリュームを削除

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

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

ボリューム共有構成について整理しよう

とりあえず、ボリューム共有の構成について、整理したいと思う。
ここは、JIS規格の「決定表」に従って整理してみる。
HTML の table タグを使うのはちょっとタイヘンなのだが、敢えて使ってみる。

	1	2	3	4
共有状態
仮想マシン定義	独立	独立	共有	共有
仮想ディスク	独立	共有	独立	共有
実行可否
各ノードで起動	不可	不可	不可	可能
マイグレーション	不可	可能	不可	可能
「一時的に移動」	-	不要	-	必要

上手く整理出来ないが、ざっとこんな感じか。

• 各ノードで起動
  ゲストを、gemini / cancer それぞれで(排他的に)起動可能か？という状態。
  ゲストを gemini で稼働させていたが、gemini がダウンした時に、そのゲストを cancer で動かすことが可能か？という観点(HA観点)
• マイグレーション
  オンライン(ライブ)マイグレーション可能か？という状態。
  ゲストを gemini で動かしているが、gemini をメンテナンスしたいので、ゲストを cancer に(稼働させたまま)移動させることが可能か？という観点
• 「一時的に移動」
  マイグレーション実施時に、「一時的に移動」のフラグが必要か？という条件

ざっとこんな感じだ。
結局、パターン4 が一番良さそうだが、「一時的に移動」フラグを付け忘れると問題になる。
デフォルトで「一時的に移動」にチェックを入れておくことは出来ないものだろうか…？

次回は、virt-manager ではなくコマンドライン(virsh)を用いたマイグレーションにチャンレンジしてみよう。

オンラインマイグレーションの「一時的に移動」

仮想マシンの定義情報( /etc/libvirt )まで共有した状態だと、ライブマイグレーションがちょっと想定外の挙動を示すことが前回分かった。

これは内部的に、以下のような流れのためだろう。

1. gemini 上の leo を一時停止
2. leo のメモリ空間に内容を cancer 上にコピー
3. gemini 上の leo の定義を、cancer 上にコピー
4. cancer 上で、leo の一時停止を解除(再開)
5. 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 が消えた

実際に、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

このような状態では、

1. gemini のメンテナンスのために、gemini 上の仮想マシンを cancer 上へ移行
2. gemini をメンテナンスし、再起動
3. 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 を使用しての移行時にある、「一時的に移動」ってのを試してみたい。

まずは両ノードで起動

さて、これでバックアップの取得は完了したので、検証開始だ。

まずは、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 は起動したままにしておく。

/etc/libvirt を共有化

前回に続いて、今度は /etc/libvirt を gemini / cancer で共有化してみよう。

複雑なことは無いので、ザクッと。
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo lvcreate -n etc-libvirt -L 320M vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo mkfs.gfs2 -t mycluster:virt-define \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/etc-libvirt
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/etc-libvirt

(gemini) $ sudo mount /dev/vg-gfs2/etc-libvirt /mnt/libvirt
(gemini) $ df /mnt/libvirt

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

(gemini) $ sudo systemctl stop /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo mount /dev/vg-gfs2/etc-libvirt /etc/libvirt
(gemini) $ df /etc/libvirt

これで、leo の起動停止を確認しておく。
動作確認が終わったら、leo は停止しておこう。

(gemini) $ sudo vi /etc/fstab
--ココから
1行書き換え
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
↓
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl stop /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo systemctl start /etc/libvirt
(gemini) $ df /etc/libvirt

ここまで来たら、gemini を再起動させ、再起動後に /etc/libvirt がマウントされていることと、leo の起動停止が出来ることを確認しておこう。
(leo は停止しておくこと)

続いて、cancer 側で同ボリュームのマウント。
(cancer) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo lvchange -asy vg-gfs2/etc-libvirt
(cancer) $ sudo lvdisplay vg-gfs2/etc-libvirt
(cancer) $ ls -ld /etc/libvirt
(cancer) $ sudo mv /etc/libvirt /etc/libvirt.orig
(cancer) $ sudo mkdir /etc/libvirt
(cancer) $ sudo mount /dev/vg-gfs2/etc-libvirt /etc/libvirt
(cancer) $ df /etc/libvirt
(cancer) $ ls -ld /etc/libvirt

(cancer) $ sudo vi /etc/fstab
--ココから
1行追加
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl stop /etc/libvirt
(cancer) $ df /etc/libvirt
(cancer) $ sudo systemctl start /etc/libvirt
(cancer) $ df /etc/libvirt

この状態で一度、virt-manager から cancer の配下を見てみよう。
っと、この状態ではどうやら leo の存在は認識できてないようだ。
libvirt-bin の reload ではどうだろう？
(cancer) $ virsh list --all
(cancer) $ sudo systemctl reload libvirt-bin
(cancer) $ virsh list --all
お、leo が出てきた。
leo のステータスはシャットオフだ。まぁ、gemini 側でも起動していないし。

とりあえず、 cancer を再起動して、もう一度マウント状態と vm の認識状態は確認しておこう。

これで、gemini / cancer 同士で /etc/libvirt を共有することが出来た。
今回はココまでにして、次回以降で leo が gemini / cancer で排他的に起動が可能なこと(同時起動は出来なくて当然)、gemini で稼働中に cancer にオンラインマイグレーション出来るか？等を確認していくことにする。