/var/lib/libvirt を cancer でマウント

続いて、gemini 側で作成した /var/lib/libvirt を、cancer 側でもマウントするようにしよう。
cancer が初めから持っている /var/lib/libvirt は、バックアップ目的でリネームしておく方向で。

(cancer) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo mv /var/lib/libvirt /var/lib/libvirt.orig
(cancer) $ sudo mkdir /var/lib/libvirt
(cancer) $ sudo mount /dev/vg-gfs2/var-lib-libvirt /var/lib/libvirt
(cancer) $ df /var/lib/libvirt

この状態で、仮想ディスク状態を見てみよう。
(cancer) $ virsh pool-list --all
(cancer) $ virsh pool-refresh default
(cancer) $ virsh vol-list default
これで、leo.qcow2 が見えるようになった。

virt-manager からも確認が可能だ。

確認できたら、cancer 側も gemini と同様に、自動アクティベートと自動マウントを施す。
(cancer) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
auto_activation_volume_list = [ "cancer-vg" ]
↓
auto_activation_volume_list = [ "cancer-vg", "vg-gfs2" ]
--ココまで

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

んで、設定を反映させ、再起動を含めた確認を行う。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl stop /var/lib/libvirt
(cancer) $ df /var/lib/libvirt
(cancer) $ sudo systemctl start /var/lib/libvirt
(cancer) $ df /var/lib/libvirt

(cancer) $ sudo systemctl reboot

(cancer) $ df /var/lib/libvirt
(cancer) $ virsh pool-list --all
(cancer) $ virsh vol-list default

どうやら問題無さそうだ。
次回は、この状態でのライブマイグレーションを確認してみる。

/var/lib/libvirt を共有FS(gfs2)化

というわけで前回の続き。

とりあえず gemini 上で動く仮想マシン(leo)とゲストOS(leo)の作成が完了したところで、とりあえずはその leo の仮想ディスクが入っている /var/lib/libvirt を gemini / cancer で共有しているディスク領域に移すことにする。

ココで既に、/dev/mapper/gfs2-001 という共有領域を作成しているはずなので、これを利用しよう。

ザザッと書いていく。(前回記載した通り、leoは停止しておくこと。)
(gemini) $ sudo pvdisplay /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo lvcreate -L 20G -n var-lib-libvirt vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2

(gemini) $ sudo mkfs.gfs2 -t mycluster:virt-disk \
-p lock_dlm \
-j 2 \
/dev/vg-gfs2/var-lib-libvirt
(gemini) $ sudo tunegfs2 -l /dev/vg-gfs2/var-lib-libvirt

(gemini) $ sudo mkdir /mnt/libvirt
(gemini) $ sudo mount /dev/vg-gfs2/var-lib-libvirt /mnt/libvirt
(gemini) $ df /mnt/libvirt
(gemini) $ ls -a /mnt/libvirt
(lost+found は存在しないことに注意)

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

(gemini) $ sudo systemctl stop /var/lib/libvirt
(gemini) $ sudo umount /mnt/libvirt
(gemini) $ sudo mount /dev/vg-gfs2/var-lib-libvirt /var/lib/libvirt
(gemini) $ sudo df /mnt/libvirt

この状態で、leo が起動、操作、停止出来ることを確認しておこう。
leo の動作確認がざっと完了したら、leo は停止しておくこと。

続いて、通常マウントを変更する。
(gemini) $ sudo vi /etc/fstab
--ココから
/var/lib/libvirt のマウントを変更しよう。
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
↓
/dev/mapper/vg--gfs2-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo systemctl stop /var/lib/libvirt
(gemini) $ df /var/lib/libvirt
(gemini) $ sudo systemctl start /var/lib/libvirt
(gemini) $ df /var/lib/libvirt

あと、vg-gfs2 は OS 起動時に自動アクティベートする設定になっていないので、自動アクティベートするように設定を施す。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
        auto_activation_volume_list = [ "gemini-vg", "vg-kvm" ]
↓
        auto_activation_volume_list = [ "gemini-vg", "vg-kvm", "vg-gfs2" ]
--ココまで

マウント出来ることが確認できたら、gemini を再起動してみる。
(gemini) $ sudo systemctl reboot

再起動後、/var/lib/libvirt がマウントされているようなら、もう一度 leo の起動、動作確認をしてみよう。

問題無さそうなら、そのまま継続だ。(leo は今回停止させない。)

まずは gemini 上で仮想マシンを

取り急ぎ、まずは gemini 上で動く仮想マシンを作ろう。
今までの手順通りに作ればいいはず。
構成は…

• ホスト名はleo
• CPUは1コア2スレッド
• メモリは2GB
• 仮想ディスクは1つ、72GB(/var/lib/libvirt/images/leo.qcow2)
• ディスクレイアウトはOSお任せ
• インストールは最小構成+SSH
• IPアドレスは192.168.55.138
• OpenvSwitchでブリッジ

というまぁ最小構成だ。

作成出来たら、gemini / cancer / aquarius / sagittarius からログイン出来ることは確認しておこう。
作成終了したら、leo は一旦シャットダウン。

次回は、/var/lib/libvirt 領域を共有FS化する。

kvmで使用する共有ファイルシステムの検討

とりあえず、共有ファイルシステムは gfs2 を使用することに決定。
で、これから検討したいのは、kvm の領域のドコを共有ファイルシステムにするか？という点。
具体的には…

1. /var/lib/libvirt を共有する
2. /etc/libvirt、/var/lib/libvirt を共有する
3. /var/lib/libvirt/images、/var/lib/libvirt/qemu を共有する
4. /etc/libvirt、/var/lib/libvirt/images、/var/lib/libvirt/qemu を共有する

等だ。
(/var/log/libvirt は単なる稼動ログなので、共有させる必要は無いと考えている。)

パターン1の例

パターン2の例

仮想マシンに関する定義が /etc/libvirt/qemu に格納されていて、gemini / cancer のどちらでも同じ仮想マシンを起動できるようにするには、最低でも /etc/libvirt/qemu と仮想マシンのイメージファイルが格納されている /var/lib/libvirt/images は共有させる必要があると思う。
けど、オンラインマイグレーションを想定した場合、/etc/libvirt/qemu が共有されていていいのだろうか？
また、仮想マシンのスナップショットは、/var/lib/libvirt/qemu/snapshot に格納されるっぽい。これらも共有しなくていいのか？(外部スナップショットではなく、内部スナップショットなら、同じディスクイメージにスナップショットが作られるので、この点は確認不要だ。)
更には、共有しようとしているディレクトリに、ホスト固有の情報が記録されていないだろうか？
等など、検討しないといけないことはたくさん有り、そもそも共有出来るのかどうか…。

今回検討したいのは、主に

1. 片方のノードがダウンした時に、ダウンしていた方のノードで稼働していた仮想マシンが、生きている方のノードで起動できるか？
2. 稼働している仮想マシンを、動かしたままもう片方のノードへ移動できるか？(ライブマイグレーション)

の2点だ。
スナップショット等の情報もそのまま引き継げればベスト。

というわけで、次回から環境を作っていこう。

とりあえず、対策を gemini にも

前回までで、(全てではないにしても)問題がある程度解消出来た。
cancer に対して実施していたので、gemini にも同様の対処を施すことにする。

(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(gemini) $ sudo vi open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(gemini) $ cd

(gemini) $ sudo systemctl daemon-reload
(gemini) $ sudo vgchange -asy vg-gfs2
(gemini) $ sudo systemctl start /mnt/gfs2

(gemini) $ cd /lib/systemd/system
(gemini) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(gemini) $ sudo systemctl daemon-reload

(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6
↓
ExecStart=/bin/sleep 10
--ココまで
(gemini) $ sudo systemctl daemon-reload

再起動して確認
(gemini) $ sudo systemctl reboot

おしまい。

o2cb.serviceの起動失敗

o2cb.service の起動が上手くいかない件に関して、以下のように調査をしたんだけど、結局上手く行かず。
原因が良くわからない。(以下の手順を実施すると、OpenvSwitch / networking の起動がダメになる。)
この件は保留にして、ocfs2 関連はステの方向で進めることにしよう。gfs2 が使えるからね。
ちなみに、設定は元に戻してある。
--------------------------------------------------------------------------------
さて、続いて o2cb.service の起動が上手くいかない問題だ。
正直言って、あまり対処する必要が無い気がするが…。

とりあえず、OS 起動後に o2cb.service をリスタートすることで正常起動することは分かっている。
であれば、起動処理を少し後ろにずらせばいいのではないだろうか？

ただしコイツ、systemd の起動スクリプトが無く、/etc/init.d の下のものを systemd-generetor によって自動的に作っている代物。
このままだと、起動処理の制御は難しい。

だったら、自動生成されたものをベースに、/lib/systemd/system の下に作ってしまったらどうだろうか？

というわけでやってみる。
ocfs2.service も同時に処理しておく。

(cancer) $ sudo systemctl stop o2cb
(cancer) $ sudo systemctl disable o2cb.service
(cancer) $ sudo systemctl stop ocfs2
(cancer) $ sudo systemctl disable ocfs2.service

(cancer) $ sudo cp -pi /run/systemd/generator.late/o2cb.service \
/lib/systemd/system/
(cancer) $ ls -l /lib/systemd/system/o2cb.service
(cancer) $ sudo vi /lib/systemd/system/o2cb.service
--ココから
先頭付近の SourcePath 宣言をコメントアウトする
SourcePath=/etc/init.d/o2cb
↓
#SourcePath=/etc/init.d/o2cb

After宣言に、openvswitch-switch.service を追加する。
After=network-online.target
↓
After=network-online.target openvswitch-switch.service

Wants宣言にも。
Wants=network-online.target
↓
Wants=network-online.target openvswitch-switch.service

末尾に[Install]セクションとインストール先を追加する。
[Install]
WantedBy=multi-user.target
--ココまで

(cancer) $ sudo systemctl daemon-reload

(cancer) $ sudo cp -pi /run/systemd/generator.late/ocfs2.service \
/lib/systemd/system/
(cancer) $ ls -l /lib/systemd/system/ocfs2.service
(cancer) $ sudo vi /lib/systemd/system/ocfs2.service
--ココから
先頭付近の SourcePath 宣言をコメントアウトする
SourcePath=/etc/init.d/o2cb
↓
#SourcePath=/etc/init.d/o2cb

末尾に[Install]セクションとインストール先を追加する。
[Install]
WantedBy=multi-user.target
--ココまで

(cancer) $ sudo systemctl daemon-reload

(cancer) $ sudo systemctl enable o2cb.service
(cancer) $ sudo systemctl enable ocfs2.service
(cancer) $ sudo systemctl status o2cb
(cancer) $ sudo systemctl status ocfs2

(cancer) $ sudo systemctl start o2cb.service
(cancer) $ sudo systemctl start ocfs2.service
(cancer) $ sudo systemctl status o2cb
(cancer) $ sudo systemctl status ocfs2

再起動して確認
(cancer) $ sudo systemctl reboot
(cancer) $ systemctl status
(cancer) $ systemctl status o2cb
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2

シャットダウン時に刺さる現象(その2)

調べてみると、iSCSIターゲットにログインする処理は、open-iscsi.service というサービスが担っているようだ。
(cancer) $ systemctl --no-pager -l status open-iscsi.service

更に、このサービスの停止処理を追いかけていくと、どうやら iSCSI領域のファイルシステムアンマウントも実行している模様。
実際に、iSCSI領域をマウントしている状態で、このサービスの停止を仕掛けてみると、ファイルシステムのアンマウントやiSCSIターゲットからのログアウトも自動的にやってくれている。

ということは、このサービスの前提に、openvswitch-switch.service を付けてやればいいんじゃないか？
というわけで試してみる。
(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi open-iscsi.service open-iscsi.service.orig
(cancer) $ sudo vi open-iscsi.service
--ココから
Wants=network-online.target remote-fs-pre.target iscsid.service
After=network-online.target iscsid.service
↓(前提条件に openvswitch-switch.service を追加)
Wants=network-online.target remote-fs-pre.target iscsid.service openvswitch-switch.serivce
After=network-online.target iscsid.service openvswitch-switch.service
--ココまで
(cancer) $ cd

設定を読み込み
(cancer) $ sudo systemctl daemon-reload

ディスク類をマウントしてしまおう。
(まだ、o2cbの問題は解決していないので、o2cbの再起動も実施)
(cancer) $ sudo systemctl restart o2cb.service
(cancer) $ sudo vgchange -asy vg-ocfs2
(cancer) $ sudo vgchange -asy vg-gfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/gfs2

ここで再起動を実施するんだけど、刺さったかどうかはコンソールを見ておく必要がある。
virt-viewerを使って、コンソールから再起動させよう。
(cancer) $ sudo systemctl reboot

あれ？刺さった。
--------------------------------------------------------------------------------
どうやら、刺さる要因は2つあったようだ。

1つは「iSCSIターゲットからログアウトする前に、OpenvSwitchが停止してしまう」という現象。
こちらは、上で対処済み。

もう1つは ocfs2 絡みのようだ。
どうも絞り込んでいくと、ocfs2 ファイルシステムがマウントされている時に刺さる現象が起きているようだ。
ocfs2 ファイルシステムのアンマウントに時間がかかっていることが原因じゃないだろうか？
どうする？gfs2 が使えるので、ocfs2 は使わないようにすればいいのだが…。一応、もう少し調べてみよう。(o2cbサービスが正常起動出来ない点も含めて)

ちなみに、今KVMホストとして使っている aquarius/sagittarius は、ocfs2 関連の環境は一切作っていないため、刺さる現象は OpenvSwitch + iSCSI によるモノだ。

色々試してみたが、以下の組み合わせの時に発生するようだ。

• OpenvSwitch を使用
• OpenvSwitch の仮想スイッチを経由した iSCSI LUN
• その LUN を multipathd でデバイスマッピング
• そのデバイスマッピングで ocfs2 ファイルシステムを使用
• そのファイルシステムをマウント

これらの条件が1つでも外れていると、再発しない様子。

どうも、iSCSIターゲットからログアウトする前に、OpenvSwitch が停止しているように見える。
もしそうだとしたら、gfs2 でも同じ事象が起きそうなものだが、gfs2 では同じ事象は発生しない。
これは、gfs2 / ocfs2 のアンマウントにかかる時間が違うからのようだ。
gfs2 は一瞬でアンマウントされるが、 ocfs2 はアンマウントに時間がかかる。
どうもそれが原因のようだ。

さてどうしよう。選択肢は2つ。

• もっと原因と対策を追求する
• ocfs2 を捨てる

出来れば、原因と対策を見つけ出した上で、ocfs2 を捨てて gfs2 オンリーにする、という形にしたい。今はまだ gfs2 では現象発生していないけど、gfs2 で発生する可能性もあるからだ。

というわけで、もう少し調査…。

色々調べていった結果、 lvm2-cluster-activation.service の停止処理に sleep を入れることで、再発率が大幅に下がることが分かった。
20秒の sleep で再現せず、5秒の sleep では時々再発。10秒の sleep で再現性がほぼ無くなったようだ。
ちょっと原因は分からないが、とりあえずこれで逃げることにしよう。

(cancer) $ cd /lib/systemd/system
(cancer) $ sudo vi lvm2-cluster-activation.service
--ココから
[Service]セクションに1行追加
ExecStopPost=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload

これでヨサゲ。

ついでに、 openvswitch-switch.service の起動時の処理に6秒の sleep を入れていたが、これも 10秒程度に延ばしておいた方が良さそうだ。
どうも、ウチの NAS の性能が良くなく、 iSCSI ログイン/ログアウトに(少し)時間がかかるのが直接の原因じゃないか？という疑い。
合わせて修正しておこう。

(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/sleep 6
↓
ExecStart=/bin/sleep 10
--ココまで
(cancer) $ sudo systemctl daemon-reload

これでとりあえず大丈夫だろう。
詳細がつかめたら、合わせて本対処するが、原因不明のため、このまま行くことにする。