続いて、lvmconfコマンド。
これは以前、この辺りで書いてた内容を、新しい gemini / cancer で実行するだけのお話。
さっそくやってみよう。
(gemini) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(gemini) $ sudo lvmconf --enable-cluster
(gemini) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
locking_type が 3に、use_lvmetad が 0 に更新された。
同じように cancer も。
(cancer) $ sudo cp -pi /etc/lvm/lvm.conf /etc/lvm/lvm.conf.orig
(cancer) $ sudo lvmconf --enable-cluster
(cancer) $ diff -c /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
はて、lvmetadは可動しっぱなしだけど、OS再起動とか lvm2-lvmetad.service の停止は不要なのかの？
2018年9月4日火曜日
2018年4月14日土曜日
1804でGFS2(失敗)
1804のリリース前バージョンのバージョンアップ方法が分かったところで、sagittarius をバージョンアップしてみた。
結論、バージョンアップに失敗。
バージョンアップ自体は問題なく出来たが、共有ファイルシステムのgfs2がマウント出来ないという問題に当たった。
仮想マシンを配置する場所を全てgfs2にしているため、マウント出来ないのは致命的だ。
また、共有せずにローカルでgfs2を作成してもマウント出来なかった。
原因が判明しなかったため、事前に取得しておいた1604のバックアップでリストアし、元の環境に戻してある。
gfs2かLVMの問題だと考えられるため、仮想マシン上でgfs2を作成、マウント確認することで原因調査することにする。
調べてる時間あるかなぁ…。
結論、バージョンアップに失敗。
バージョンアップ自体は問題なく出来たが、共有ファイルシステムのgfs2がマウント出来ないという問題に当たった。
仮想マシンを配置する場所を全てgfs2にしているため、マウント出来ないのは致命的だ。
また、共有せずにローカルでgfs2を作成してもマウント出来なかった。
原因が判明しなかったため、事前に取得しておいた1604のバックアップでリストアし、元の環境に戻してある。
gfs2かLVMの問題だと考えられるため、仮想マシン上でgfs2を作成、マウント確認することで原因調査することにする。
調べてる時間あるかなぁ…。
2017年5月21日日曜日
/var/lib/libvirt の拡張
さて続いて、/var/lib/libvirt の領域の拡張方法を記載しておく。
LVMに詳しいのなら、特に気にしなくても大丈夫だ。
一つだけ注意点がある。
ext4 系のファイルシステムなら、一度拡張しても、縮小することは出来る。が、gfs2 ファイルシステムは一度拡張したら、縮小することが出来ない。拡張は簡単だが、縮小が出来ないため、拡張が必要な場合は十分に検討して拡張するように。
また、前回作成したVGは、わざと20GBほど残している。これは将来、このVGからスナップショットを作ることを想定してのことだ。LVMではボリューム管理が楽なので、わざと多少残しておいておくのがベターだぞ。
まずは、iSCSI領域から新しいLUN(100GB)を作成し、kvmtargetターゲットに接続しよう。
この時、LUNの名前は kvm002 にしておこう。(数が増えれば、当然末尾の数字は増やす。)
続いて、aquarius / sagittarius で iSCSI LUN の確認をしよう。
$ dmesg
aquarius では /dev/sdc、sagittarius では /dev/sdj として認識された。
(この辺は、マシンの環境でデバイス名が変わるぞ)
今度は、確認できたLUNを、multipath 管理下にする。
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdj
$ sudo cat /etc/multipath/wwids
bindings ファイルへ反映(下線部は、上記コマンドで見つかった wwid にすること)
$ sudo cat /etc/multipath/bindings
$ sudo bash -c "echo kvm002 23661323765323131 >> /etc/multipath/bindings"
$ sudo cat /etc/multipath/bindings
multipath コマンドで反映＆確認
$ sudo multipath -ll
(aquarius) $ sudo multipath -r /dev/sdc
(sagittarius) $ sudo multipath -r /dev/sdj
$ sudo multipath -ll
これで、追加ディスクを /dev/mapper/kvm002 として取り扱うことが出来るようになった。
次は LVM 関連の操作。
$ sudo pvdisplay /dev/mapper/kvm002
(aquarius) $ sudo pvcreate /dev/mapper/kvm002
$ sudo pvdisplay /dev/mapper/kvm002
$ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgextend kvmcluster /dev/mapper/kvm002
$ sudo vgdisplay -v kvmcluster
今回は、 /var/lib/libvirt 用に 100GB 拡張する。
(実際には、追加した 100GB の LUN は、LVM管理情報等が入るため、100GB から若干少ない容量になるのだが、あまり細かい計算はしない)
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt
(aquarius) $ sudo lvextend -L +100G kvmcluster/var-lib-libvirt
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt
$ sudo vgdisplay -v kvmcluster
これで、kvmcluster/var-lib-libvirt の領域が 180GB まで拡張されたはずだ。
今度は、ファイルシステムの拡張。
(aquarius) $ df -h /var/lib/libvirt
(aqaurius) $ sudo gfs2_grow -T /var/lib/libvirt
(aquarius) $ sudo gfs2_grow /var/lib/libvirt
(aquarius) $ df -h /var/lib/libvirt
この時、どうやら当該領域をマウントしている全てのノードで gfs2_grow を実施しないといけないようだ…。
今回は aquarius でしかマウントしていないため、特に気にする必要はなかった。
次回気をつけよう。
ファイルシステムのマウントはこれで一旦終了。
必要に応じてこの手順を繰り返して、必要量に拡張してくれ。
LVMに詳しいのなら、特に気にしなくても大丈夫だ。
一つだけ注意点がある。
ext4 系のファイルシステムなら、一度拡張しても、縮小することは出来る。が、gfs2 ファイルシステムは一度拡張したら、縮小することが出来ない。拡張は簡単だが、縮小が出来ないため、拡張が必要な場合は十分に検討して拡張するように。
また、前回作成したVGは、わざと20GBほど残している。これは将来、このVGからスナップショットを作ることを想定してのことだ。LVMではボリューム管理が楽なので、わざと多少残しておいておくのがベターだぞ。
まずは、iSCSI領域から新しいLUN(100GB)を作成し、kvmtargetターゲットに接続しよう。
この時、LUNの名前は kvm002 にしておこう。(数が増えれば、当然末尾の数字は増やす。)
続いて、aquarius / sagittarius で iSCSI LUN の確認をしよう。
$ dmesg
aquarius では /dev/sdc、sagittarius では /dev/sdj として認識された。
(この辺は、マシンの環境でデバイス名が変わるぞ)
今度は、確認できたLUNを、multipath 管理下にする。
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdj
$ sudo cat /etc/multipath/wwids
bindings ファイルへ反映(下線部は、上記コマンドで見つかった wwid にすること)
$ sudo cat /etc/multipath/bindings
$ sudo bash -c "echo kvm002 23661323765323131 >> /etc/multipath/bindings"
$ sudo cat /etc/multipath/bindings
multipath コマンドで反映＆確認
$ sudo multipath -ll
(aquarius) $ sudo multipath -r /dev/sdc
(sagittarius) $ sudo multipath -r /dev/sdj
$ sudo multipath -ll
これで、追加ディスクを /dev/mapper/kvm002 として取り扱うことが出来るようになった。
次は LVM 関連の操作。
$ sudo pvdisplay /dev/mapper/kvm002
(aquarius) $ sudo pvcreate /dev/mapper/kvm002
$ sudo pvdisplay /dev/mapper/kvm002
$ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgextend kvmcluster /dev/mapper/kvm002
$ sudo vgdisplay -v kvmcluster
今回は、 /var/lib/libvirt 用に 100GB 拡張する。
(実際には、追加した 100GB の LUN は、LVM管理情報等が入るため、100GB から若干少ない容量になるのだが、あまり細かい計算はしない)
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt
(aquarius) $ sudo lvextend -L +100G kvmcluster/var-lib-libvirt
$ sudo lvdisplay -v kvmcluster/var-lib-libvirt
$ sudo vgdisplay -v kvmcluster
これで、kvmcluster/var-lib-libvirt の領域が 180GB まで拡張されたはずだ。
今度は、ファイルシステムの拡張。
(aquarius) $ df -h /var/lib/libvirt
(aqaurius) $ sudo gfs2_grow -T /var/lib/libvirt
(aquarius) $ sudo gfs2_grow /var/lib/libvirt
(aquarius) $ df -h /var/lib/libvirt
この時、どうやら当該領域をマウントしている全てのノードで gfs2_grow を実施しないといけないようだ…。
今回は aquarius でしかマウントしていないため、特に気にする必要はなかった。
次回気をつけよう。
ファイルシステムのマウントはこれで一旦終了。
必要に応じてこの手順を繰り返して、必要量に拡張してくれ。
aquarius / sagittarius 用の共有ボリュームの作成
今度は、KVM の共有ボリュームの作成だ。
殆どは、これまで実施してきた作業の応用なので、そんなに説明はいらないだろう。
まずはストレージ装置で、iSCSIターゲットを新たに作成する。
名前は kvmtarget とでもしておこう。
で、aquarius / sagittarius からのみアクセス可能にする。(アクセス権限は R/W)
aquarius / sagittarius の iSCSIイニシエータのIQNが必要だが、それは /etc/iscsi/initiatorname.iscsi を見れば分かるぞ。
$ sudo cat /etc/iscsi/initiatorname.iscsi
そしたら、ストレージ装置側でボリュームを作成し、今作成した iSCSIターゲット へ割り当てよう。
LUNの作成方針としては、各自で自由に決めてもらっていいけど、自分は 100GB ずつ作成、という方針にしている。
まずは 100GB を1つ、kvm001 という名前で作成した。
この状態で、aquairus / sagittarius から iSCSIターゲット へログインする。
$ sudo iscsiadm -m discovery -t sendtargets -p (NASのIPアドレス)
$ sudo iscsiadm -m node --targetname (NASのIQN名) --login
(NAS の IQN名 は、ストレージ装置側で確認しよう。)
そうしたら、新たなディスクが見えてきたはずだ。
$ dmesg
(aquarius では /dev/sdc、sagittarius では /dev/sdi で見えてきた。)
合わせて、OS 起動時にiSCSIターゲットに自動的にログインするようにしよう。
$ sudo iscsiadm --mode node \
--targetname=(iSCSIターゲットのIQN名) \
--op=update \
--name=node.startup \
--value=automatic
このディスクを multipathd 管理にする。
$ lsblk
$ sudo multipath -ll
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdi
(aquarius / sagittarius どちらも同じ wwid が追加されたはず。)
$ sudo vi /etc/multipath/bindings
先程見えてきた wwid を、kvm001 という名前にする。
具体的には以下の行を追記する。(下線部は見えてきた wwid にすること)
kvm001 23565633034613838
multipathd でデバイスを認識する
$ sudo multipath -ll
$ sudo multipath -r
$ sudo multipath -ll
これで、/dev/mapper/kvm001 というデバイスファイル名でアクセス出来るようになるはずだ。
$ lsblk
mpath名 kvm001 が存在していることが確認できる。
続いて、そのボリュームを使って仮想マシン領域を作成する。
/etc/libvirt と /var/lib/libvirt の2つとし、/var/log/libvirt は OS ディスク領域をそのまま使うことにする。
また /etc/libvirt は、そんなに頻繁に書き換わるわけではないため、ジャーナルサイズはデフォルトの128MBから大きく下げて、最低の 8MByte にする。
2017/05/22 修正
ジャーナルサイズを最低の 8MByte にしたら、aquarius と sagittarius で同時マウントすることが出来なかった。原因は分からないが、デフォルトの 128MByte とする。
2017/05/22 修正ココまで
ディスクは、mbr/gpt パーティションを作らず、そのまま LVM-PV に使用する。
その他諸々の設定は、以下のコマンドから読み取ってくれぃ。
(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(aquarius) $ sudo pvcreate /dev/mapper/kvm001
(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(sagittarius) $ sudo pvdisplay /dev/mapper/kvm001
(aquarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgcreate -c y kvmcluster /dev/mapper/kvm001
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo lvcreate -L 32M -n etc-libvirt kvmcluster
2017/05/22 修正
ジャーナルサイズをデフォルトの 128MByte にする関係で、この領域のサイズは 32MByte では足りなくなる。そのため、1GByte にした。
(aquarius) $ sudo lvcreate -L 1G -n etc-libvirt kvmcluster
2017/05/22 修正ココまで
(aquarius) $ sudo lvcreate -L 80G -n var-lib-libvirt kvmcluster
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo lvchange -asy kvmcluster/etc-libvirt
(aquarius) $ sudo lvchange -asy kvmcluster/var-lib-libvirt
(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:etc-libvirt \
-p lock_dlm \
-J 8 \
-j 2 \
/dev/kvmcluster/etc-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt
(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:var-lib-libvirt \
-p lock_dlm \
-j 2 \
/dev/kvmcluster/var-lib-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt
領域を作ったら、今の仮想マシン環境情報を新しい領域に移し、マウントし直す。
(aquarius) $ sudo mkdir /mnt/libvirt
(aquarius) $ sudo mount /dev/kvmcluster/etc-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt
(aquarius) $ sudo -i
(aquarius) # cd /etc
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo mount /dev/kvmcluster/var-lib-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt
(aquarius) $ sudo -i
(aquarius) # cd /var/lib
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo rmdir /mnt/libvirt
/var/log/libvirt は、専用のボリュームを作らず、/var/log に配置する。
aquarius / sagittarius 両方で実施したいが、sagittarius 上では仮想マシンが稼働しているため、実施できない。
そのため、sagittarius 上では別途実施する。
(aquarius) $ cd /var/log
(aquarius) $ sudo tar cvf libvirt.tar libvirt
(aquarius) $ sudo systemctl stop /var/log/libvirt
(aquarius) $ sudo chmod 755 /var/log/libvirt
(aquarius) $ sudo chown root:root /var/log/libvirt
(aquarius) $ sudo tar xvf libvirt.tar
(aquarius) $ sudo rmdir libvirt/lost+found
(aquarius) $ ls libvirt
(aquarius) $ sudo rm libvirt.tar
(aquarius) $ cd
/etc/libvirt、/var/lib/libvirt のマウント情報を書き換え、/var/log/libvirt のマウント情報を削除する
(aquarius) $ sudo systemctl stop /etc/libvirt
(aquarius) $ sudo systemctl stop /var/lib/libvirt
(aquarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで
(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl start /etc/libvirt
(aquarius) $ grep /etc/libvirt /etc/mtab
(aquairus) $ sudo systemctl start /var/lib/libvirt
(aquarius) $ grep /var/lib/libvirt /etc/mtab
(aquarius) $ ls /etc/libvirt
(aquarius) $ ls /var/lib/libvirt
これで、共有領域の作成は完了だ。
(出来ればこのタイミングで、aquarius を再起動して、キチンとマウントされるか確認しておいたほうが良いが…。)
次は仮想マシンを共有領域へ移動、だが、その前に明らかに仮想ディスク領域( /var/lib/libvirt )が足りない。
その為、次回はまず、仮想ディスク領域を拡張する手順を作る。
＃コレ以降、仮想ディスク領域の拡張は、特に書かないツモリ…。
殆どは、これまで実施してきた作業の応用なので、そんなに説明はいらないだろう。
まずはストレージ装置で、iSCSIターゲットを新たに作成する。
名前は kvmtarget とでもしておこう。
で、aquarius / sagittarius からのみアクセス可能にする。(アクセス権限は R/W)
aquarius / sagittarius の iSCSIイニシエータのIQNが必要だが、それは /etc/iscsi/initiatorname.iscsi を見れば分かるぞ。
$ sudo cat /etc/iscsi/initiatorname.iscsi
そしたら、ストレージ装置側でボリュームを作成し、今作成した iSCSIターゲット へ割り当てよう。
LUNの作成方針としては、各自で自由に決めてもらっていいけど、自分は 100GB ずつ作成、という方針にしている。
まずは 100GB を1つ、kvm001 という名前で作成した。
この状態で、aquairus / sagittarius から iSCSIターゲット へログインする。
$ sudo iscsiadm -m discovery -t sendtargets -p (NASのIPアドレス)
$ sudo iscsiadm -m node --targetname (NASのIQN名) --login
(NAS の IQN名 は、ストレージ装置側で確認しよう。)
そうしたら、新たなディスクが見えてきたはずだ。
$ dmesg
(aquarius では /dev/sdc、sagittarius では /dev/sdi で見えてきた。)
合わせて、OS 起動時にiSCSIターゲットに自動的にログインするようにしよう。
$ sudo iscsiadm --mode node \
--targetname=(iSCSIターゲットのIQN名) \
--op=update \
--name=node.startup \
--value=automatic
このディスクを multipathd 管理にする。
$ lsblk
$ sudo multipath -ll
$ sudo cat /etc/multipath/wwids
(aquarius) $ sudo multipath -a /dev/sdc
(sagittarius) $ sudo multipath -a /dev/sdi
(aquarius / sagittarius どちらも同じ wwid が追加されたはず。)
$ sudo vi /etc/multipath/bindings
先程見えてきた wwid を、kvm001 という名前にする。
具体的には以下の行を追記する。(下線部は見えてきた wwid にすること)
kvm001 23565633034613838
multipathd でデバイスを認識する
$ sudo multipath -ll
$ sudo multipath -r
$ sudo multipath -ll
これで、/dev/mapper/kvm001 というデバイスファイル名でアクセス出来るようになるはずだ。
$ lsblk
mpath名 kvm001 が存在していることが確認できる。
続いて、そのボリュームを使って仮想マシン領域を作成する。
/etc/libvirt と /var/lib/libvirt の2つとし、/var/log/libvirt は OS ディスク領域をそのまま使うことにする。
2017/05/22 修正
ジャーナルサイズを最低の 8MByte にしたら、aquarius と sagittarius で同時マウントすることが出来なかった。原因は分からないが、デフォルトの 128MByte とする。
2017/05/22 修正ココまで
ディスクは、mbr/gpt パーティションを作らず、そのまま LVM-PV に使用する。
その他諸々の設定は、以下のコマンドから読み取ってくれぃ。
(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(aquarius) $ sudo pvcreate /dev/mapper/kvm001
(aquarius) $ sudo pvdisplay /dev/mapper/kvm001
(sagittarius) $ sudo pvdisplay /dev/mapper/kvm001
(aquarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo vgcreate -c y kvmcluster /dev/mapper/kvm001
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster
2017/05/22 修正
ジャーナルサイズをデフォルトの 128MByte にする関係で、この領域のサイズは 32MByte では足りなくなる。そのため、1GByte にした。
(aquarius) $ sudo lvcreate -L 1G -n etc-libvirt kvmcluster
2017/05/22 修正ココまで
(aquarius) $ sudo lvcreate -L 80G -n var-lib-libvirt kvmcluster
(aquarius) $ sudo vgdisplay -v kvmcluster
(sagittarius) $ sudo vgdisplay -v kvmcluster
(aquarius) $ sudo lvchange -asy kvmcluster/etc-libvirt
(aquarius) $ sudo lvchange -asy kvmcluster/var-lib-libvirt
(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:etc-libvirt \
-p lock_dlm \
-j 2 \
/dev/kvmcluster/etc-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/etc-libvirt
(aquarius) $ sudo mkfs.gfs2 -t kvmcluster:var-lib-libvirt \
-p lock_dlm \
-j 2 \
/dev/kvmcluster/var-lib-libvirt
(aquarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt
(sagittarius) $ sudo tunegfs2 -l /dev/kvmcluster/var-lib-libvirt
領域を作ったら、今の仮想マシン環境情報を新しい領域に移し、マウントし直す。
(aquarius) $ sudo mkdir /mnt/libvirt
(aquarius) $ sudo mount /dev/kvmcluster/etc-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt
(aquarius) $ sudo -i
(aquarius) # cd /etc
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo mount /dev/kvmcluster/var-lib-libvirt /mnt/libvirt
(aquarius) $ grep /mnt/libvirt /etc/mtab
(aquarisu) $ ls -al /mnt/libvirt
(aquarius) $ sudo -i
(aquarius) # cd /var/lib
(aquarius) # tar cSf - libvirt | ( cd /mnt ; tar xSf - )
(aquarius) # ls -alR /mnt/libvirt
(aquarius) # rmdir /mnt/libvirt/lost+found
(aquarius) # exit
(aquarius) $ sudo umount /mnt/libvirt
(aquarius) $ sudo rmdir /mnt/libvirt
/var/log/libvirt は、専用のボリュームを作らず、/var/log に配置する。
aquarius / sagittarius 両方で実施したいが、sagittarius 上では仮想マシンが稼働しているため、実施できない。
そのため、sagittarius 上では別途実施する。
(aquarius) $ cd /var/log
(aquarius) $ sudo tar cvf libvirt.tar libvirt
(aquarius) $ sudo systemctl stop /var/log/libvirt
(aquarius) $ sudo chmod 755 /var/log/libvirt
(aquarius) $ sudo chown root:root /var/log/libvirt
(aquarius) $ sudo tar xvf libvirt.tar
(aquarius) $ sudo rmdir libvirt/lost+found
(aquarius) $ ls libvirt
(aquarius) $ sudo rm libvirt.tar
(aquarius) $ cd
/etc/libvirt、/var/lib/libvirt のマウント情報を書き換え、/var/log/libvirt のマウント情報を削除する
(aquarius) $ sudo systemctl stop /etc/libvirt
(aquarius) $ sudo systemctl stop /var/lib/libvirt
(aquarius) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
↓
/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで
(aquarius) $ sudo systemctl daemon-reload
(aquarius) $ sudo systemctl start /etc/libvirt
(aquarius) $ grep /etc/libvirt /etc/mtab
(aquairus) $ sudo systemctl start /var/lib/libvirt
(aquarius) $ grep /var/lib/libvirt /etc/mtab
(aquarius) $ ls /etc/libvirt
(aquarius) $ ls /var/lib/libvirt
これで、共有領域の作成は完了だ。
(出来ればこのタイミングで、aquarius を再起動して、キチンとマウントされるか確認しておいたほうが良いが…。)
次は仮想マシンを共有領域へ移動、だが、その前に明らかに仮想ディスク領域( /var/lib/libvirt )が足りない。
その為、次回はまず、仮想ディスク領域を拡張する手順を作る。
＃コレ以降、仮想ディスク領域の拡張は、特に書かないツモリ…。
2017年4月24日月曜日
まずはiSCSIボリュームでocfs2/gfs2共有領域を
とりあえず、共有領域を作ろう。
以前、ココで100GBの ocfs2 用のボリュームは用意した。
とりあえず、コレを使って ocfs2 用の領域を作ろう。
multipath が正しく動いていれば、 /dev/mapper/ocfs2-001 というデバイスファイル名で見えているはずだ。(シンボリックリンクだけど、普通にデバイスファイルとして扱える。)
これを、クラスタマークを付与した /dev/vg-ocfs2 に追加し、既に存在するファイルシステムを pvmove で /dev/mapper/ocfs2-001 に移してしまう。
アクティベートされていないと思うので、アクティベートしておこう。
(gemini) $ sudo vgchange -asy vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
/dev/mapper/ocfs2-001 を vg-ocfs2 に追加。
これまでは、parted による gptパーティション を作っていたが、今回はディスクデバイスごと追加してしまう。
(gemini) $ sudo pvcreate /dev/mapper/ocfs2-001
(gemini) $ sudo pvdisplay /dev/mapper/ocfs2-001
(gemini) $ sudo vgextend vg-ocfs2 /dev/mapper/ocfs2-001
(gemini) $ sudo vgdisplay -v vg-ocfs2
ここまで出来たら、cancer 側でも確認。
(cancer) $ sudo vgdisplay -v vg-ocfs2
ちょっと試しに、両ノードでマウントしておこう。
(gemini) $ sudo systemctl start /mnt/ocfs2
あ…あれ？マウント出来ねぇ…。
なんか、クラスタサービスがどうのこうの…
ヨクワカランが、o2cbサービスの再起動をしておく。
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo systemctl restart o2cb
(cancer) $ sudo systemctl restart o2cb
(gemini) $ sudo vgchange -asy vg-ocfs2
再びマウント
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
マウント出来ているのが確認できたら、vdb1 から ocfs2-001 へ移動。
(gemini) $ sudo pvmove /dev/vdb1 /dev/mapper/ocfs2-001
Cannot move in clustered VG vg-ocfs2, clustered mirror (cmirror) not detected and LVs are activated non-exclusively.
おや？どうやら、排他モードでアクティベートしていないと、pvmove は出来ないらしい。知らんかった。
(clusterd mirror というのを動かしておけばいいようだ。これも要調査だな。)
というわけで、一旦排他モードにする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -an vg-ocfs2
(gemini) $ sudo vgchange -aey vg-ocfs2
(gemini) $ sudo systemctl start /mnt/ocfs2
そしたら今度こそ pvmove 。
(gmeini) $ sudo pvmove /dev/vdb1 /dev/mapper/ocfs2-001
う～ん。排他モードでないとダメなのかなぁ？他にやり方ありそうだけど…。
pvmoveが完了したら、状況を確認してみよう。
(gemini) $ ls /mnt/ocfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo pvdisplay -v /dev/vdb1
(gemini) $ sudo pvdisplay -v /dev/mapper/ocfs2-001
vgdisplayのタイミングで、vg構成のバックアップが行われたようだ。
本来なら、vgcfgbackup を実行する必要がありそうだな。(今回は自動で実行されたので不要だが)
cancer側でも確認。
(cancer) $ sudo vgcfgbackup vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo pvdisplay -v /dev/vdb1
(cancer) $ sudo pvdisplay -v /dev/mapper/ocfs2-001
/dev/vdb1 の Allocated PE がゼロになっているのが確認できたら、この /dev/vdb1 は不要になったので、vg-ocfs2 から切り離そう。
(gemini) $ sudo vgreduce vg-ocfs2 /dev/vdb1
(gemini) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
/dev/vdb1 の PVヘッダ(pvcreate コマンドでディスク上に付けられる管理情報)も削除しておこう。
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo pvremove /dev/vdb1
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
パーティションテーブルも削除。
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb rm 1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
削除が終わったら、/dev/vdb 自体をOSから外してしまおう。
(gemini) $ ls -l /sys/block/vdb/device
virtio4 へのシンボリックリンクのようだ。
(gemini) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdb*
(gemini) $ lsblk
cancerも。
(cancer) $ ls -l /sys/block/vdb/device
こちらも virtio4 へのシンボリックリンクのようだ。
(cancer) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdb*
(cancer) $ lsblk
そしたら、virt-manager を使って、仮想マシン gemini/cancer から当該仮想ディスクを外しておこう。
あっと、vg-ocfs2 は今、排他モードになっているはず。
共有モードに切り替えておこう。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -asy vg-ocfs2
マウント出来るか確認。
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
構成をいじったので、再起動して反映されているか確認しておこう。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ lsblk
(cancer) $ lsblk
(gemini) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
ここまで問題なし。
(gemini) $ sudo vgchange -asy vg-ocfs2
(gemini) $ sudo systemctl start /mnt/ocfs2
やっぱりマウントで失敗する。どうやら、o2cb の起動処理に問題がありそうだ。
別途調査。
取り急ぎ、o2cb の再起動で逃げよう。
(gemini) $ sudo systemctl restart o2cb
(cancer) $ sudo systemctl restart o2cb
も一回マウント
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
マウント出来た。
これで、iSCSI共有領域のみで ocfs2 のファイルシステムを用意できた。
共有用に使ってて、この作業で切り離した ocfs2.qcow2 は、virt-manager を使って削除しておこう。
-------------------------------------------------------
続いて、gfs2 領域もiSCSI化してしまおう。
やり方はまったく同じ。
まずは、NASキットの iSCSI ターゲット機能を使って、gemini/cancerに100GBのLUNを渡す。(gemini/cancerの両方と接続しているiSCSIターゲットに、100GBのLUNを追加する。)
dmesg コマンドで確認すると、gemini では /dev/sdc、cancer では /dev/sdb として認識された。
というわけで、gemini から作業。
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo multipath -a /dev/sdc
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -r /dev/sdc
(gemini) $ sudo multipath -ll
(gemini) $ sudo vi /etc/multipath/bindings
--ココから
mpatha 23566633634646565
↓(新しく作成されたデバイスの名前を変更する。)
gfs2-001 23566633634646565
--ココまで
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -F /dev/sdc
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -r /dev/sdc
(gemini) $ sudo multipath -ll
これで、gemini では、新しいディスクは /dev/mapper/gfs2-001 というデバイスファイル名で扱えるようになった。
続いて、cancer 側で同じ作業。
(cancer) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo multipath -a /dev/sdb
(cancer) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo vi /etc/multipath/bindings
--ココから
(1行追加。)
gfs2-001 23566633634646565
--ココまで
(cancer) $ sudo multipath -ll
(cancer) $ sudo multipath -r /dev/sdb
(cancer) $ sudo multipath -ll
そしたら、ocfs2 と同じように移動作業。
ocfs2 の時は、排他モードでアクティベートしてから実施したけど、非アクティベート状態で実施する。
ただし、まだクラスタマークが付与されてなかったと思うので、クラスタマークは付与しておく。
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo vgchange -c y vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo vgextend vg-gfs2 /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo pvmove /dev/vdb1 /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
ここまでで移動は完了のはず。
移動完了したので、古い方のボリュームは切り離す。
(gemini) $ sudo vgreduce vg-gfs2 /dev/vdb1
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo pvremove /dev/vdb1
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb rm 1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ ls -l /sys/block/vdb/device
virtio4 へのシンボリックリンクのようだ。
(gemini) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdb*
(gemini) $ lsblk
(cancer) $ ls -l /sys/block/vdb/device
こちらも virtio4 へのシンボリックリンクのようだ。
(cancer) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdb*
(cancer) $ lsblk
そしたら、virt-manager を使って、仮想マシン gemini/cancer から当該仮想ディスクを外しておこう。
vg-gfs2 を共有モードでアクティベートして確認だ。
(gemini) $ sudo vgchange -a n vg-gfs2
(gemini) $ sudo vgchange -asy vg-gfs2
マウント出来るか確認。
(gemini) $ sudo systemctl start /mnt/gfs2
(cancer) $ sudo systemctl start /mnt/gfs2
構成をいじったので、再起動して反映されているか確認しておこう。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
あれ？ココで cancer のシャットダウン処理中に刺さる現象が…。
ネットワーク関連っぽいな。cifs マウントか iSCSI 関連が絡んでいそうだ。
これも要調査。
とりあえず、cancer は強制的に再起動させた。
(gemini) $ lsblk
(cancer) $ lsblk
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo vgchange -asy vg-gfs2
(gemini) $ sudo systemctl start /mnt/gfs2
(cancer) $ sudo systemctl start /mnt/gfs2
マウント出来た。
これで、iSCSI共有領域のみで ocfs2 のファイルシステムを用意できた。
ocfs2 の時と同様、共有用に使ってて、この作業で切り離した gfs2.qcow2 は、virt-manager を使って削除しておこう。
さて、ココまでで iSCSI 領域の共有化が完成したが、問題が3点。
これらも調査を継続しないと…な…。
以前、ココで100GBの ocfs2 用のボリュームは用意した。
とりあえず、コレを使って ocfs2 用の領域を作ろう。
multipath が正しく動いていれば、 /dev/mapper/ocfs2-001 というデバイスファイル名で見えているはずだ。(シンボリックリンクだけど、普通にデバイスファイルとして扱える。)
これを、クラスタマークを付与した /dev/vg-ocfs2 に追加し、既に存在するファイルシステムを pvmove で /dev/mapper/ocfs2-001 に移してしまう。
アクティベートされていないと思うので、アクティベートしておこう。
(gemini) $ sudo vgchange -asy vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
/dev/mapper/ocfs2-001 を vg-ocfs2 に追加。
これまでは、parted による gptパーティション を作っていたが、今回はディスクデバイスごと追加してしまう。
(gemini) $ sudo pvcreate /dev/mapper/ocfs2-001
(gemini) $ sudo pvdisplay /dev/mapper/ocfs2-001
(gemini) $ sudo vgextend vg-ocfs2 /dev/mapper/ocfs2-001
(gemini) $ sudo vgdisplay -v vg-ocfs2
ここまで出来たら、cancer 側でも確認。
(cancer) $ sudo vgdisplay -v vg-ocfs2
ちょっと試しに、両ノードでマウントしておこう。
(gemini) $ sudo systemctl start /mnt/ocfs2
あ…あれ？マウント出来ねぇ…。
なんか、クラスタサービスがどうのこうの…
ヨクワカランが、o2cbサービスの再起動をしておく。
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo systemctl restart o2cb
(cancer) $ sudo systemctl restart o2cb
(gemini) $ sudo vgchange -asy vg-ocfs2
再びマウント
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
(gemini) $ df /mnt/ocfs2
(cancer) $ df /mnt/ocfs2
マウント出来ているのが確認できたら、vdb1 から ocfs2-001 へ移動。
(gemini) $ sudo pvmove /dev/vdb1 /dev/mapper/ocfs2-001
Cannot move in clustered VG vg-ocfs2, clustered mirror (cmirror) not detected and LVs are activated non-exclusively.
おや？どうやら、排他モードでアクティベートしていないと、pvmove は出来ないらしい。知らんかった。
(clusterd mirror というのを動かしておけばいいようだ。これも要調査だな。)
というわけで、一旦排他モードにする。
(cancer) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -an vg-ocfs2
(gemini) $ sudo vgchange -aey vg-ocfs2
(gemini) $ sudo systemctl start /mnt/ocfs2
そしたら今度こそ pvmove 。
(gmeini) $ sudo pvmove /dev/vdb1 /dev/mapper/ocfs2-001
う～ん。排他モードでないとダメなのかなぁ？他にやり方ありそうだけど…。
pvmoveが完了したら、状況を確認してみよう。
(gemini) $ ls /mnt/ocfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo pvdisplay -v /dev/vdb1
(gemini) $ sudo pvdisplay -v /dev/mapper/ocfs2-001
vgdisplayのタイミングで、vg構成のバックアップが行われたようだ。
本来なら、vgcfgbackup を実行する必要がありそうだな。(今回は自動で実行されたので不要だが)
cancer側でも確認。
(cancer) $ sudo vgcfgbackup vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo pvdisplay -v /dev/vdb1
(cancer) $ sudo pvdisplay -v /dev/mapper/ocfs2-001
/dev/vdb1 の Allocated PE がゼロになっているのが確認できたら、この /dev/vdb1 は不要になったので、vg-ocfs2 から切り離そう。
(gemini) $ sudo vgreduce vg-ocfs2 /dev/vdb1
(gemini) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
/dev/vdb1 の PVヘッダ(pvcreate コマンドでディスク上に付けられる管理情報)も削除しておこう。
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo pvremove /dev/vdb1
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
パーティションテーブルも削除。
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb rm 1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
削除が終わったら、/dev/vdb 自体をOSから外してしまおう。
(gemini) $ ls -l /sys/block/vdb/device
virtio4 へのシンボリックリンクのようだ。
(gemini) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdb*
(gemini) $ lsblk
cancerも。
(cancer) $ ls -l /sys/block/vdb/device
こちらも virtio4 へのシンボリックリンクのようだ。
(cancer) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdb*
(cancer) $ lsblk
そしたら、virt-manager を使って、仮想マシン gemini/cancer から当該仮想ディスクを外しておこう。
あっと、vg-ocfs2 は今、排他モードになっているはず。
共有モードに切り替えておこう。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo vgchange -a n vg-ocfs2
(gemini) $ sudo vgchange -asy vg-ocfs2
マウント出来るか確認。
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
構成をいじったので、再起動して反映されているか確認しておこう。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
(gemini) $ lsblk
(cancer) $ lsblk
(gemini) $ sudo vgdisplay -v vg-ocfs2
(cancer) $ sudo vgdisplay -v vg-ocfs2
ここまで問題なし。
(gemini) $ sudo vgchange -asy vg-ocfs2
(gemini) $ sudo systemctl start /mnt/ocfs2
やっぱりマウントで失敗する。どうやら、o2cb の起動処理に問題がありそうだ。
別途調査。
取り急ぎ、o2cb の再起動で逃げよう。
(gemini) $ sudo systemctl restart o2cb
(cancer) $ sudo systemctl restart o2cb
も一回マウント
(gemini) $ sudo systemctl start /mnt/ocfs2
(cancer) $ sudo systemctl start /mnt/ocfs2
マウント出来た。
これで、iSCSI共有領域のみで ocfs2 のファイルシステムを用意できた。
共有用に使ってて、この作業で切り離した ocfs2.qcow2 は、virt-manager を使って削除しておこう。
-------------------------------------------------------
続いて、gfs2 領域もiSCSI化してしまおう。
やり方はまったく同じ。
まずは、NASキットの iSCSI ターゲット機能を使って、gemini/cancerに100GBのLUNを渡す。(gemini/cancerの両方と接続しているiSCSIターゲットに、100GBのLUNを追加する。)
dmesg コマンドで確認すると、gemini では /dev/sdc、cancer では /dev/sdb として認識された。
というわけで、gemini から作業。
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo multipath -a /dev/sdc
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -r /dev/sdc
(gemini) $ sudo multipath -ll
(gemini) $ sudo vi /etc/multipath/bindings
--ココから
mpatha 23566633634646565
↓(新しく作成されたデバイスの名前を変更する。)
gfs2-001 23566633634646565
--ココまで
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -F /dev/sdc
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -r /dev/sdc
(gemini) $ sudo multipath -ll
これで、gemini では、新しいディスクは /dev/mapper/gfs2-001 というデバイスファイル名で扱えるようになった。
続いて、cancer 側で同じ作業。
(cancer) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo multipath -a /dev/sdb
(cancer) $ sudo cat /etc/multipath/wwids
(cancer) $ sudo vi /etc/multipath/bindings
--ココから
(1行追加。)
gfs2-001 23566633634646565
--ココまで
(cancer) $ sudo multipath -ll
(cancer) $ sudo multipath -r /dev/sdb
(cancer) $ sudo multipath -ll
そしたら、ocfs2 と同じように移動作業。
ocfs2 の時は、排他モードでアクティベートしてから実施したけど、非アクティベート状態で実施する。
ただし、まだクラスタマークが付与されてなかったと思うので、クラスタマークは付与しておく。
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo vgchange -c y vg-gfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo vgextend vg-gfs2 /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo pvmove /dev/vdb1 /dev/mapper/gfs2-001
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
ここまでで移動は完了のはず。
移動完了したので、古い方のボリュームは切り離す。
(gemini) $ sudo vgreduce vg-gfs2 /dev/vdb1
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo pvremove /dev/vdb1
(gemini) $ sudo pvdisplay /dev/vdb1
(cancer) $ sudo pvdisplay /dev/vdb1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ sudo parted /dev/vdb rm 1
(gemini) $ sudo parted /dev/vdb print
(cancer) $ sudo parted /dev/vdb print
(gemini) $ ls -l /sys/block/vdb/device
virtio4 へのシンボリックリンクのようだ。
(gemini) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(gemini) $ ls -l /dev/vdb*
(gemini) $ lsblk
(cancer) $ ls -l /sys/block/vdb/device
こちらも virtio4 へのシンボリックリンクのようだ。
(cancer) $ sudo bash -c "echo virtio4 > /sys/bus/virtio/drivers/virtio_blk/unbind"
(cancer) $ ls -l /dev/vdb*
(cancer) $ lsblk
そしたら、virt-manager を使って、仮想マシン gemini/cancer から当該仮想ディスクを外しておこう。
vg-gfs2 を共有モードでアクティベートして確認だ。
(gemini) $ sudo vgchange -a n vg-gfs2
(gemini) $ sudo vgchange -asy vg-gfs2
マウント出来るか確認。
(gemini) $ sudo systemctl start /mnt/gfs2
(cancer) $ sudo systemctl start /mnt/gfs2
構成をいじったので、再起動して反映されているか確認しておこう。
(gemini) $ sudo systemctl reboot
(cancer) $ sudo systemctl reboot
あれ？ココで cancer のシャットダウン処理中に刺さる現象が…。
ネットワーク関連っぽいな。cifs マウントか iSCSI 関連が絡んでいそうだ。
これも要調査。
とりあえず、cancer は強制的に再起動させた。
(gemini) $ lsblk
(cancer) $ lsblk
(gemini) $ sudo vgdisplay -v vg-gfs2
(cancer) $ sudo vgdisplay -v vg-gfs2
(gemini) $ sudo vgchange -asy vg-gfs2
(gemini) $ sudo systemctl start /mnt/gfs2
(cancer) $ sudo systemctl start /mnt/gfs2
マウント出来た。
これで、iSCSI共有領域のみで ocfs2 のファイルシステムを用意できた。
ocfs2 の時と同様、共有用に使ってて、この作業で切り離した gfs2.qcow2 は、virt-manager を使って削除しておこう。
さて、ココまでで iSCSI 領域の共有化が完成したが、問題が3点。
- ocfs2ファイルシステムのマウントが出来ない
(o2cb.service を再起動させることで処理可能) - 再起動時に刺さる現象がまだ解消できていない
(ネットワークとネットワークストレージの関連か？) - CLVM共有モードで pvmove するためには、 clusterd mirror というのが必要
これらも調査を継続しないと…な…。
2017年3月14日火曜日
iSCSIボリュームのLVMが有効化されるまで(その3：多分完結)
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
悩んで悩んで悩んで、どうやら見当違いのところを調査していたらしい…。
まず、ネットワーク設定のディレクトリに、geminiを作成した時の設定情報が残っていた。
そのファイルがまず不要だったので削除する。
(gemini/cancerを作る時の基本的な手順は省略してしまっているが、ココのタイミングで作ったと思われるファイルだ…。)
(gemini) $ cd /etc/network/interfaces.d
(gemini) $ ls -l ens3
(gemini) $ sudo cat ens3
(gemini) $ sudo rm ens3
(gemini) $ ls -l
それから、ココやココではOpenvSwitchのブリッジにIPアドレスを付与しているように見えるが、どうやらこれは正しく無いようだ。
実際にはやはり、NICやNICから作るbondingに対して、IPを付与するようだ。
(確かに、違和感はあった。)
というわけで、ブリッジのIP定義ファイルとNICのIP定義ファイルを書き換える。
まずは、NICのIP定義ファイル。
(gemini) $ sudo vi 0110.ens3
--以下のように行を追加＆修正
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
↓(下線行を追加＆修正)
auto ens3
allow-br-external ens3
iface ens3 inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_bridge br-external
ovs_type OVSPort
dns-nameservers 192.168.55.1
--ココまで
続いて、ブリッジのIP定義ファイル
(gemini) $ sudo vi 0010.br-external
--以下のように修正＆行削除
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
↓
auto br-external
allow-ovs br-external
iface br-external inet manual
ovs_type OVSBridge
ovs_ports ens3
--ココまで
更に、ココの最後に無効化したnetworking.serviceはやはり必要なようなので、有効化しておく。
(gemini) $ systemctl is-enabled networking.service
(gemini) $ sudo systemctl enable networking.service
(少し時間かかってエラーになるかもしれないけど我慢だ)
(gemini) $ systemctl is-enabled networking.service
そうしたら再起動してみる。
(gemini) $ sudo shutdown -r now
起動してきたら確認。
(gemini) $ systemctl status
Failedが無くなった！
(gemini) $ sudo vgs
ちゃんと表示される…。
(gemini) $ sudo iscsiadm -m session
ログインできてる。
そうか…OpenvSwitchの設定をミスってただけなのか…。
やっと、長いこと悩んでいた原因が分かって修正方法も分かった…。
次回は、これにそってaquariusの修正を行う。
--2017/03/24追記
根本的に間違えていた。今はまだ調査を続行しているけど、↑の設定は根本的に誤り。
まだ対応方法は不明だけど、↑のやり方は間違いなので、元に戻しておいた方がいい。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
悩んで悩んで悩んで、どうやら見当違いのところを調査していたらしい…。
まず、ネットワーク設定のディレクトリに、geminiを作成した時の設定情報が残っていた。
そのファイルがまず不要だったので削除する。
(gemini/cancerを作る時の基本的な手順は省略してしまっているが、ココのタイミングで作ったと思われるファイルだ…。)
(gemini) $ cd /etc/network/interfaces.d
(gemini) $ ls -l ens3
(gemini) $ sudo cat ens3
(gemini) $ sudo rm ens3
(gemini) $ ls -l
それから、ココやココではOpenvSwitchのブリッジにIPアドレスを付与しているように見えるが、どうやらこれは正しく無いようだ。
実際にはやはり、NICやNICから作るbondingに対して、IPを付与するようだ。
(確かに、違和感はあった。)
というわけで、ブリッジのIP定義ファイルとNICのIP定義ファイルを書き換える。
まずは、NICのIP定義ファイル。
(gemini) $ sudo vi 0110.ens3
--以下のように行を追加＆修正
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
↓(下線行を追加＆修正)
auto ens3
allow-br-external ens3
iface ens3 inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_bridge br-external
ovs_type OVSPort
dns-nameservers 192.168.55.1
--ココまで
続いて、ブリッジのIP定義ファイル
(gemini) $ sudo vi 0010.br-external
--以下のように修正＆行削除
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
↓
auto br-external
allow-ovs br-external
iface br-external inet manual
ovs_type OVSBridge
ovs_ports ens3
--ココまで
更に、ココの最後に無効化したnetworking.serviceはやはり必要なようなので、有効化しておく。
(gemini) $ systemctl is-enabled networking.service
(gemini) $ sudo systemctl enable networking.service
(少し時間かかってエラーになるかもしれないけど我慢だ)
(gemini) $ systemctl is-enabled networking.service
そうしたら再起動してみる。
(gemini) $ sudo shutdown -r now
起動してきたら確認。
(gemini) $ systemctl status
Failedが無くなった！
(gemini) $ sudo vgs
ちゃんと表示される…。
(gemini) $ sudo iscsiadm -m session
ログインできてる。
そうか…OpenvSwitchの設定をミスってただけなのか…。
やっと、長いこと悩んでいた原因が分かって修正方法も分かった…。
次回は、これにそってaquariusの修正を行う。
--2017/03/24追記
根本的に間違えていた。今はまだ調査を続行しているけど、↑の設定は根本的に誤り。
まだ対応方法は不明だけど、↑のやり方は間違いなので、元に戻しておいた方がいい。
iSCSIボリュームのLVMが有効化されるまで(その2)
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
未だ解決出来ていないのだが、前回からの再起動後、systemdの状態をよく見てみたら、corosync.serviceの起動にも失敗している。
はて？cancerの方はどうだ？
(cancer) $ sudo shutdown -r now
(cancer) $ systemctl status corosync.service
問題なく起動している。
なんとまぁ…geminiに対する変更処理で、corosyncにまで影響が出てしまった。
これは要調査だな…。
ってどうやら、dlm.serviceも正常起動しなくなってるぞ。
これは大ダメージだ。
とりあえず状態の整理。
(gemini) $ cat /lib/systemd/system/corosync.service
要件として、network-online.targetが入っている。
ステータスは…
(gemini) $ systemctl status network-online.target
activeだ。
条件は…
(gemini) $ cat /lib/systemd/system/network-online.target
前提条件としてnetwork.targetが入っている。
ステータスは当然…
(gemini) $ systemctl status network.target
activeだ。
う～ん。corosync.serviceが起動していないのは何故だろう？
試しに起動してみる。
(gemini) $ sudo systemctl start corosync.service
(gemini) $ systemctl status corosync.service
む？activeになったぞ…？
もう一度再起動して、再現確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status corosync.service
あれ？今度は
………色々調べてたら、どうやらOpenvSwitchの設定がおかしいようだ………
ヘルプに書かれている設定方法じゃダメっぽい………
整理して書き直す…。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
未だ解決出来ていないのだが、前回からの再起動後、systemdの状態をよく見てみたら、corosync.serviceの起動にも失敗している。
はて？cancerの方はどうだ？
(cancer) $ sudo shutdown -r now
(cancer) $ systemctl status corosync.service
問題なく起動している。
なんとまぁ…geminiに対する変更処理で、corosyncにまで影響が出てしまった。
これは要調査だな…。
ってどうやら、dlm.serviceも正常起動しなくなってるぞ。
これは大ダメージだ。
とりあえず状態の整理。
- /etc/libvirt等のKVM用ファイルシステムは未マウント
- NAS領域も未マウント
- vg確認・操作系オペレーションはハング(vgs)
- iSCSIターゲットへのログインは成功(iscsadm -m session)
- ブロックデバイスは認識済み(lsblk)
- corosync.serviceはfailed
- dlm.serviceはinactive
- clvm.serviceはinactive(これはcancerも)
- multipathは認識済み
(gemini) $ cat /lib/systemd/system/corosync.service
要件として、network-online.targetが入っている。
ステータスは…
(gemini) $ systemctl status network-online.target
activeだ。
条件は…
(gemini) $ cat /lib/systemd/system/network-online.target
前提条件としてnetwork.targetが入っている。
ステータスは当然…
(gemini) $ systemctl status network.target
activeだ。
う～ん。corosync.serviceが起動していないのは何故だろう？
試しに起動してみる。
(gemini) $ sudo systemctl start corosync.service
(gemini) $ systemctl status corosync.service
む？activeになったぞ…？
もう一度再起動して、再現確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl status corosync.service
あれ？今度は
- iSCSIターゲットへのログインは、片方失敗(gemini単独用ターゲットへのログイン失敗)
- corosync.serviceは起動状態
- dlm.serviceも起動状態
- clvmはinactive
………色々調べてたら、どうやらOpenvSwitchの設定がおかしいようだ………
ヘルプに書かれている設定方法じゃダメっぽい………
整理して書き直す…。
2017年3月11日土曜日
iSCSIボリュームのLVMが有効化されるまで(その1)
--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
前回の調査で、どうやらOS起動時のファイルシステム(iSCSIボリュームで作成したLVM領域のファイルシステム)マウント、OS停止時のファイルシステムアンマウントの流れがおかしいのでは？というのが予想出来た。
そもそもこの領域、iSCSI領域であり、OpenvSwitch上の仮想スイッチを経由してiSCSIターゲットへ接続している。
(サーバとして使うのなら、iSCSIターゲットへの接続は独立したネットワークを用い、OpenvSwitchを経由しない構成にするべきだと思うのだが、自宅PCレベルでは複数NICや複数N/Wを使いまわすのは面倒だ…)
そのため、OS起動からファイルシステムマウントまでは、以下の流れにならないといけないと思う。(CIFSマウントのタイミングもついでに書いておいた。)
停止はこの逆になるはず。
根本的なところで、OpenvSwitchが起動した後に、iSCSIのLVM関連が動き出さないといけないのだが、どうやら起動処理ではこの順番が守られていないように見える。
また、停止時もこの逆になっていないように見える。
これを追いかけてみよう。
まずは再起動をして、サービス起動が上手く行っていないものを探す。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl -a status
今のgeminiは、以下のような状態になっている。
● gemini
State: starting
Jobs: 3 queued
Failed: 1 units
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2detc\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2dvar\x2d\x2dlib\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(以降省略)
みたいな感じだ。
なんか、表示が上手く行っていないが、
dev-mapper-vg--kvm-lv--etc--libvirt.device
とかのようだ。
末尾が.deviceとなっているunitは、deviceタイプと呼ばれる代物。
実体は何処にあるかと言うと…無い…。
どういうことだろ…。deviceタイプはチェックしなくていいのかな？
一応、確認はしてみる。
(gemini) $ systemctl status dev-mapper-vg\\x2d\\x2dkvm\\x2dlv\\x2d\\x2detc\\x2d\\xwdlibvirt.device
Timed out waiting for device dev-mapper-vg…
う～ん。どうやら、デバイス(vg)へのアクセスがタイムアウトを起こした、ということらしいな。
ということは、vg構成情報が読み取れる状態になるところ(iSCSIログイン？)に問題があるのか？
systemdのユニットは、service/deviceの他に、mount/target等があるようだ。
ということで、一応mountも確認してみるか。
mount関連はココにも書いた通り、/run/systemd/generaterの下に自動生成される。
試しに、etc-libvirt.mountとmnt-iso\x2dos.mountを見てみると、以下のようなエントリが見える。
Before=remote-fs.target
これは、自分自身(etc-libvirt.mountとかmnt-iso\x2dos.mountとか)よりも後に、remote-fs.targetを起動する、という設定。
前提条件を書いているのではなく、後続条件を書いていることになる。
ちなみに、remote-fs.targetは、今の自分の環境には2つ存在してる。
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/lib/systemd/system/remote-fs.target
が、実体は後者で、前者はシンボリックリンクだ。
前者はSysV init方式で言うところのrunlevelを制御するところの関係なので、今回はちょっと無視する。
後者を確認しよう(前者はシンボリックリンクなので、どちらを確認しても同じなのだが…)。
以下の3行が気になる。
After=remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target
これを見ると、remote-fs.targetは、remote-fs-pre.targetの処理が終わってからでないと起動しないらしい。
また、shutdown.targetとConflictsになっているため、shutdown.targetと同時起動はしない。
DefaultDependenciesは…ちょっと良くわからない。標準的な依存関係を暗黙的に有効にするかどうか？で、noに設定されているので、幾つかの標準的な依存関係は無視される？
remote-fs-pre.targetも同じディレクトリにあるので、こちらもついでに確認する。
特に何かが書いてあるわけではない。
RefuseManualStart=yes
ってのがあるが…これがyesなので、ユーザの手作業による起動・停止は出来ないようだ。
これらをまとめてみると、以下のフローになるのかな？
さて、ココを調べてもしょうがない。
もっと上位で問題が起きていて、ファイルシステムマウントまで辿り着いていない、というのが現実だ。
とは言え、etc-libvirt.mountを見ても前提条件が書かれていない。
ステータスを見てみると…
(gemini) $ systemctl status etc-libvirt.mount
Dependency failed for /etc/libvirt.
となっていて、Dependency(依存)の失敗が原因となっている。
一体どういうことなんだろう…。
やはり、iSCSIログインに問題があるのだろうか？
と思って、NAS装置の管理画面からiSCSIターゲットを見てみたら、一応ログインされているようだ。
iSCSIログインに関するsystemd unitは何だろうな…
(gemini) $ systemctl | grep -i iscsi
iscsid.serviceのようだ。ステータスはrunningだから問題無い。
(gemini) $ systemctl status iscsid.service
cannot make a connection to....
あれ？なんかエラーっぽいメッセージが出てるな…大丈夫か？
一応、iscsid.serviceを再起動してみるか…。
(gemini) $ sudo systemctl restart iscsid.service
(gemini) $ systemctl status iscsid.service
おや？先程のエラーっぽいメッセージは出なくなった。
でも、vg情報は取得されてないぞ…。
む？もう1つ、open-iscsi.serviceってあるけど…これ…は？
(gemini) $ systemctl status open-iscsi.service
正常に動いているっぽいけど、一応再起動してみる…。
(gemini) $ sudo systemctl restart open-iscsi.service
ログイン済みのiSCSI targetからログアウト→再度ログイン、という流れになるはずなんだけど、syslogを見てみたらログアウトに1分30秒かかってタイムアウトした。
その後、再ログインしてデバイス認識はスムーズに行っている。
もしかして、これでvg認識されたかな？
(gemini) $ sudo pvdisplay /dev/sda1
ダメだ。ハングする。
他にも問題を抱えているのか…。
iSCSIイニシエータのエラーっぽいメッセージが消えたから、今度はLVM関連のサービスを確認してみるか。
(gemini) $ systemctl status | grep lvm2
lvm2-activation-net.serviceというのがあるな。
これの内容は…おや？これも自動生成関係っぽいな。
(gemini) $ man lvm2-activation-generator
lvm.confでlvmetadが無効化されている場合に、このlvm2-activation-generatorによってユニットが生成され、LVMボリュームがアクティベートされる、と。
gemini/cancerは、CLVMを使用する関係で、lvmetadを無効化している。
となると、今のaquarius/sagittariusとは条件が違うか…。まぁaquarius/sagittariusも将来的にはlvmetadを停止することになりそうだから、調べておくか。
どうやら、/run/systemd/generatorに、
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
という3つのユニットが作成されているっぽい。
これが関係あるかもしれない。
1つずつ確認してみよう。
まず3つのユニットのExecStartだけど、全て同じで
ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster
になっている。
つまり、lvm.confのauto_activation_volume_listに記載されているlvolのうち、Clusterマークが付いているボリュームを無視して、残り全てをアクティベーションさせるということか。
これだと、既にPVが認識できていることが前提条件になりそうだな…。
3つのユニットの依存関係を見てみると…。
lvm2-activation-early.service
After=systemd-udev-settle.service
Before=cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
lvm2-activation-net.service
After=lvm2-activation.service iscsi.service fcoe.service
Before=remote-fs-pre.target shutdown.target
lvm2-activation.service
After= lvm2-activation-early.service cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
After/Before/Wantsが定義されている。
これらの依存関係を整理すると…
こんな感じだろうか…。
これ、1つずつ実行してみる。(最後のshutdown.targetは実行しちゃダメだよ)
(gemini) $ sudo systemctl restart systemd-udev-settle.service
(gemini) $ sudo systemctl restart lvm2-activation-early.service
あれ…？ココでハングした…？
--以下は想定していたコマンド。上でハングしたので実施せず。
(gemini) $ sudo systemctl restart cryptsetup.target
(gemini) $ sudo systemctl restart lvm2-activation.service
(gemini) $ sudo systemctl restart iscsi.service
(gemini) $ sudo systemctl restart lvm2-activation-net.service
--ココまで
う～ん。なんだろう…？
ちょっと調査を続けていたら、ココで設定したgemini/cancer共用のiSCSIターゲットへの自動ログインがOffになってた。(geminiだけ。)
たんなる作業ミスなのか、一連の作業の中で自動的に解除されたのかは不明。
とりあえず、「iSCSIを利用しようその1」等に従って、自動ログインを実施するように設定。
この状態で一度再起動をしてみるが、まだ解決できず。
とりあえず、調査は継続するけど、今回はここまで。
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--
前回の調査で、どうやらOS起動時のファイルシステム(iSCSIボリュームで作成したLVM領域のファイルシステム)マウント、OS停止時のファイルシステムアンマウントの流れがおかしいのでは？というのが予想出来た。
そもそもこの領域、iSCSI領域であり、OpenvSwitch上の仮想スイッチを経由してiSCSIターゲットへ接続している。
(サーバとして使うのなら、iSCSIターゲットへの接続は独立したネットワークを用い、OpenvSwitchを経由しない構成にするべきだと思うのだが、自宅PCレベルでは複数NICや複数N/Wを使いまわすのは面倒だ…)
そのため、OS起動からファイルシステムマウントまでは、以下の流れにならないといけないと思う。(CIFSマウントのタイミングもついでに書いておいた。)
停止はこの逆になるはず。
根本的なところで、OpenvSwitchが起動した後に、iSCSIのLVM関連が動き出さないといけないのだが、どうやら起動処理ではこの順番が守られていないように見える。
また、停止時もこの逆になっていないように見える。
これを追いかけてみよう。
まずは再起動をして、サービス起動が上手く行っていないものを探す。
(gemini) $ sudo shutdown -r now
(gemini) $ systemctl -a status
今のgeminiは、以下のような状態になっている。
● gemini
State: starting
Jobs: 3 queued
Failed: 1 units
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2detc\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(略)
● dev-mapper-vg\x2d\x2dkvm\x2dlv\x2d\x2dvar\x2d\x2dlib\x2d\x2dlibvirt.device
Loaded: loaded
Active: inactive (dead)
(以降省略)
みたいな感じだ。
なんか、表示が上手く行っていないが、
dev-mapper-vg--kvm-lv--etc--libvirt.device
とかのようだ。
末尾が.deviceとなっているunitは、deviceタイプと呼ばれる代物。
実体は何処にあるかと言うと…無い…。
どういうことだろ…。deviceタイプはチェックしなくていいのかな？
一応、確認はしてみる。
(gemini) $ systemctl status dev-mapper-vg\\x2d\\x2dkvm\\x2dlv\\x2d\\x2detc\\x2d\\xwdlibvirt.device
Timed out waiting for device dev-mapper-vg…
う～ん。どうやら、デバイス(vg)へのアクセスがタイムアウトを起こした、ということらしいな。
ということは、vg構成情報が読み取れる状態になるところ(iSCSIログイン？)に問題があるのか？
systemdのユニットは、service/deviceの他に、mount/target等があるようだ。
ということで、一応mountも確認してみるか。
mount関連はココにも書いた通り、/run/systemd/generaterの下に自動生成される。
試しに、etc-libvirt.mountとmnt-iso\x2dos.mountを見てみると、以下のようなエントリが見える。
Before=remote-fs.target
これは、自分自身(etc-libvirt.mountとかmnt-iso\x2dos.mountとか)よりも後に、remote-fs.targetを起動する、という設定。
前提条件を書いているのではなく、後続条件を書いていることになる。
ちなみに、remote-fs.targetは、今の自分の環境には2つ存在してる。
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/lib/systemd/system/remote-fs.target
が、実体は後者で、前者はシンボリックリンクだ。
前者はSysV init方式で言うところのrunlevelを制御するところの関係なので、今回はちょっと無視する。
後者を確認しよう(前者はシンボリックリンクなので、どちらを確認しても同じなのだが…)。
以下の3行が気になる。
After=remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target
これを見ると、remote-fs.targetは、remote-fs-pre.targetの処理が終わってからでないと起動しないらしい。
また、shutdown.targetとConflictsになっているため、shutdown.targetと同時起動はしない。
DefaultDependenciesは…ちょっと良くわからない。標準的な依存関係を暗黙的に有効にするかどうか？で、noに設定されているので、幾つかの標準的な依存関係は無視される？
remote-fs-pre.targetも同じディレクトリにあるので、こちらもついでに確認する。
特に何かが書いてあるわけではない。
RefuseManualStart=yes
ってのがあるが…これがyesなので、ユーザの手作業による起動・停止は出来ないようだ。
これらをまとめてみると、以下のフローになるのかな？
さて、ココを調べてもしょうがない。
もっと上位で問題が起きていて、ファイルシステムマウントまで辿り着いていない、というのが現実だ。
とは言え、etc-libvirt.mountを見ても前提条件が書かれていない。
ステータスを見てみると…
(gemini) $ systemctl status etc-libvirt.mount
Dependency failed for /etc/libvirt.
となっていて、Dependency(依存)の失敗が原因となっている。
一体どういうことなんだろう…。
やはり、iSCSIログインに問題があるのだろうか？
と思って、NAS装置の管理画面からiSCSIターゲットを見てみたら、一応ログインされているようだ。
iSCSIログインに関するsystemd unitは何だろうな…
(gemini) $ systemctl | grep -i iscsi
iscsid.serviceのようだ。ステータスはrunningだから問題無い。
(gemini) $ systemctl status iscsid.service
cannot make a connection to....
あれ？なんかエラーっぽいメッセージが出てるな…大丈夫か？
一応、iscsid.serviceを再起動してみるか…。
(gemini) $ sudo systemctl restart iscsid.service
(gemini) $ systemctl status iscsid.service
おや？先程のエラーっぽいメッセージは出なくなった。
でも、vg情報は取得されてないぞ…。
む？もう1つ、open-iscsi.serviceってあるけど…これ…は？
(gemini) $ systemctl status open-iscsi.service
正常に動いているっぽいけど、一応再起動してみる…。
(gemini) $ sudo systemctl restart open-iscsi.service
ログイン済みのiSCSI targetからログアウト→再度ログイン、という流れになるはずなんだけど、syslogを見てみたらログアウトに1分30秒かかってタイムアウトした。
その後、再ログインしてデバイス認識はスムーズに行っている。
もしかして、これでvg認識されたかな？
(gemini) $ sudo pvdisplay /dev/sda1
ダメだ。ハングする。
他にも問題を抱えているのか…。
iSCSIイニシエータのエラーっぽいメッセージが消えたから、今度はLVM関連のサービスを確認してみるか。
(gemini) $ systemctl status | grep lvm2
lvm2-activation-net.serviceというのがあるな。
これの内容は…おや？これも自動生成関係っぽいな。
(gemini) $ man lvm2-activation-generator
lvm.confでlvmetadが無効化されている場合に、このlvm2-activation-generatorによってユニットが生成され、LVMボリュームがアクティベートされる、と。
gemini/cancerは、CLVMを使用する関係で、lvmetadを無効化している。
となると、今のaquarius/sagittariusとは条件が違うか…。まぁaquarius/sagittariusも将来的にはlvmetadを停止することになりそうだから、調べておくか。
どうやら、/run/systemd/generatorに、
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
という3つのユニットが作成されているっぽい。
これが関係あるかもしれない。
1つずつ確認してみよう。
まず3つのユニットのExecStartだけど、全て同じで
ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster
になっている。
つまり、lvm.confのauto_activation_volume_listに記載されているlvolのうち、Clusterマークが付いているボリュームを無視して、残り全てをアクティベーションさせるということか。
これだと、既にPVが認識できていることが前提条件になりそうだな…。
3つのユニットの依存関係を見てみると…。
lvm2-activation-early.service
After=systemd-udev-settle.service
Before=cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
lvm2-activation-net.service
After=lvm2-activation.service iscsi.service fcoe.service
Before=remote-fs-pre.target shutdown.target
lvm2-activation.service
After= lvm2-activation-early.service cryptsetup.target
Before=local-fs-pre.target shutdown.target
Wants=systemd-udev-settle.service
After/Before/Wantsが定義されている。
これらの依存関係を整理すると…
こんな感じだろうか…。
これ、1つずつ実行してみる。(最後のshutdown.targetは実行しちゃダメだよ)
(gemini) $ sudo systemctl restart systemd-udev-settle.service
(gemini) $ sudo systemctl restart lvm2-activation-early.service
あれ…？ココでハングした…？
--以下は想定していたコマンド。上でハングしたので実施せず。
(gemini) $ sudo systemctl restart cryptsetup.target
(gemini) $ sudo systemctl restart lvm2-activation.service
(gemini) $ sudo systemctl restart iscsi.service
(gemini) $ sudo systemctl restart lvm2-activation-net.service
--ココまで
う～ん。なんだろう…？
ちょっと調査を続けていたら、ココで設定したgemini/cancer共用のiSCSIターゲットへの自動ログインがOffになってた。(geminiだけ。)
たんなる作業ミスなのか、一連の作業の中で自動的に解除されたのかは不明。
とりあえず、「iSCSIを利用しようその1」等に従って、自動ログインを実施するように設定。
この状態で一度再起動をしてみるが、まだ解決できず。
とりあえず、調査は継続するけど、今回はここまで。
2017年3月7日火曜日
実はちょっと問題が
今のウチの構成は、KVMホストとして使っている物理マシンが2台ある。
Intel NUCを使った弁当箱サイズのaquariusと、いわゆる自作マシンのミドルタワーサイズのsagittariusだ。
このマシンにUbuntu16.04を導入し、iSCSIイニシエータ、OpenvSwitch、KVM等を導入して運用している。
で、このマシン、実はシャットダウンやリブートで詰まる事象が起きている。
ファイルシステムアンマウント・ボリュームディアクティベートあたりで発生しているようで、多分「gfs2マウントについて(その1:自動マウント)」辺りと似たような問題だと睨んでいる。
ただ、仮想マシンではなく物理マシンのため、今までは見て見ぬふりをしていた。
再起動を伴う設定変更・確認は、物理マシンを相手にする場合は、物理マシンの直ぐ側にいないとリスキーなので。
ただ、仮想マシンでiSCSIが利用できることも確認できたので、仮想マシンで現象の再現、対応方法の確立をしようと思う。
とりあえず、gemini/cancer上でKVMを動かしたいので、一旦停止してgemini/cancerのCPU定義と割当メモリを変更する。
まずは停止。
(gemini) $ sudo shutdown -h now
(cancer) $ sudo shutdown -h now
停止しているのを確認して、両仮想マシンを編集。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh edit gemini
(sagittarius) $ virsh edit cancer
gemini/cancerともに同じ修正を施す。
--ココから
4～5行目付近
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
↓(割当サイズを4GBにする)
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
17～18行目付近
<cpu mode='custom' match='exact'>
<model fallback='allow'>core2duo</model>
↓(CPUモデルをhost-modelに)
<cpu mode='host-model'>
<model fallback='allow'/>
--ココまで
ココまで出来たらgemini/cancerともに起動する。
(sagittarius) $ virsh start gemini
(sagittarius) $ virsh start cancer
後は、過去の内容を参照しながら作り込んでいく。(とりあえずgeminiに対してのみ更新。)
ざっとコマンド羅列。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install qemu-kvm
(gemini) $ sudo shutdown -r now
(gemini) $ grep kvm /etc/group
(gemini) $ id
(gemini) $ sudo adduser (自分のユーザ名) kvm
(gemini) $ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
(gemini) $ id
(gemini) $ lsmod | grep kvm
(gemini) $ sudo apt-get install virtinst
(gemini) $ sudo apt-get install libosinfo-bin
再ログイン
(gemini) $ virsh list --all
(gemini) $ sudo apt-get install virt-manager
(gemini) $ sudo apt-get install fonts-ipafont
(gemini) $ sudo apt-get install openvswitch-switch
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo ovs-vsctl add-br br-external
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo vi /etc/network/interfaces.d/0110.ens3
ファイルの新規作成
--ココから--
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
--ココまで--
(gemini) $ sudo vi /etc/network/interfaces.d/0010.br-external
ファイルの新規作成
--ココから--
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
--ココまで--
--2017/04/14追記
ネットワークセッションが切れてしまうので、コンソールで作業しよう。
(gemini) $ sudo ifdown ens3
(gemini) $ sudo rm /etc/network/interfaces.d/ens3
(gemini) $ sudo ovs-vsctl add-port br-external ens3
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ifup ens3
(gemini) $ sudo ifup br-external
--2017/04/14追記ココまで
--2017/04/20追記
このまま再起動させると、 OpenvSwitch/corosync/dlm/lvm2-cluster-activation の起動関連が上手く行かず、ハングしてしまう。
そのため、起動順の制御と、OpenvSwitchの起動時に、少しsleepを置くことにする。
(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi corosync.service corosync.service.orig
(gemini) $ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
(gemini) $ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで
(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓(何も実行しない処理を、6秒待機に変更する)
ExecStart=/bin/sleep 6
--ココまで
変更内容を取り込む。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
--2017/04/20追記ココまで
(gemini) $ sudo shutdown -r now
(gemini) $ ip address show
(gemini) $ dig www.blogger.com
(gemini) $ sudo ovs-vsctl show
(gemini) $ virsh net-list --all
(gemini) $ vi ovsbridge.xml
ファイルの新規作成
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='br-external'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
(gemini) $ virsh net-define ovsbridge.xml
(gemini) $ virsh net-list --all
(gemini) $ virsh net-autostart ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ virsh net-start ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ sudo apt-get install ovmf
-------------------------------------------------------------
がーっと作ってしまったが、iSCSIのボリューム以外はだいたいホストOSと同じになったはず。
この状態で再起動が上手くいくか確認。
(gemini) $ sudo shutdown -r now
特に問題無さそうだ。
iSCSIストレージ装置で、新しくiSCSIターゲットを作成、100GBのLUNを新たに繋いで、geminiにのみ接続させておく。
/dev/sdb として認識された。
そのディスクを、ホストOSと同じように領域確保＆ファイルシステム作成する。
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb mklabel gpt
(gemini) $ sudo parted /dev/sdb mkpart primary ext4 0% 100%
(gemini) $ sudo parted /dev/sdb toggle 1 lvm
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo pvcreate /dev/sdb1
(gemini) $ sudo vgcreate vg-kvm /dev/sdb1
(gemini) $ sudo vgchange -c n vg-kvm
(gemini) $ sudo vgdisplay -v vg-kvm
(gemini) $ sudo lvcreate -L 32M -n lv-etc-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 50G -n lv-var-lib-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 2G -n lv-var-log-libvirt vg-kvm
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
続いて、中身のコピー。
(gemini) $ sudo mkdir /tmp/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /etc
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /etc/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /etc/libvirt
(gemini) $ sudo mkdir /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/lib
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/lib/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/lib/libvirt
(gemini) $ sudo mkdir /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /var/lib/libvirt
(gemini) $ df /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/log
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/log/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/log/libvirt
(gemini) $ sudo mkdir /var/log/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /var/log/libvirt
(gemini) $ df /var/log/libvirt
(gemini) $ sudo rmdir /tmp/libvirt
fstabを更新
(gemini) $ sudo vi /etc/fstab
以下の行を追加
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev 0 0
--ココまで
(gemini) $ sudo umount /etc/libvirt
(gemini) $ sudo umount /var/log/libvirt
(gemini) $ sudo umount /var/lib/libvirt
(gemini) $ sudo mount -a
(gemini) $ df
自動アクティベート対象にする。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
auto_activation_volume_list = [ "gemini-vg" ]
↓項目追加
auto_activation_volume_list = [ "gemini-vg", "vg-kvm" ]
--ココまで
もう1つ、KVMホストは実はcifsマウントもしている。
(OSのisoメディアを配置するディスクはcifsにした。これなら別のWindowsマシンからも利用が可能だからだ。)
cifsマウント用のパッケージの導入
(gemini) $ sudo apt-get install cifs-utils
そのマウントポイントを作成する。
(gemini) $ sudo mkdir /mnt/iso-os
fstabに追記する。
(gemini) $ sudo vi /etc/fstab
以下の行を追記
--ココから
//(cifsのIPアドレス)/(cifsのディレクトリ) /mnt/iso-os cifs guest,_netdev 0 0
--ココまで
マウント確認
(gemini) $ sudo mount /mnt/iso-os
(gemini) $ df /mnt/iso-os
(gemini) $ sudo umount /mnt/iso-os
再起動してマウント状態の確認
(gemini) $ sudo shutdown -r now
(gemini) $ df
これでgeminiは、KVMホストのaquarius/sagittariusとほぼ同じ環境になったはずだ。
あれ…何度再起動しかけても、KVMホストマシンで発生している現象が起きない…な…。
そういえば、ココでnetworking.serviceを無効にしてたんだった。
それも適用してみよう。
(gemini) $ sudo systemctl stop networking.service
(gemini) $ sudo systemctl is-active networking.service
(gemini) $ sudo systemctl disable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
--2017/04/20追記--
そもそも、 networking.service が failed になる理由だけど…。
今回、 OpenvSwitch で br-external という仮想スイッチ(仮想デバイス)を作成している。物理デバイスは存在しないデバイスだ。
networking.service は、 /etc/network/interfaces と /etc/network/interfaces.d/* で auto に指定されているデバイスは起動時に有効にしようとするが、 br-external は物理デバイスが無いため、 networking.service では有効に出来ない。(openvswitch-nonetwork.service にて有効にされる。)
networking.service が failed になる理由は、起動時に br-external を有効化しようとしてコケるからだ。
というわけで、 br-external は networking.service からは有効化されないように設定しよう。
(gemini) $ sudo cp -pi /etc/default/networking /etc/default/netwoking.orig
(gemini) $ sudo vi /etc/default/networking
--ココから
8行目付近
#EXCLUDE_INTERFACES=
↓(br-externalを指定)
EXCLUDE_INTERFACES=br-external
--ココまで
(gemini) $ sudo systemctl daemon-reload
networking.service は有効化しておこう。
(gemini) $ sudo systemctl enable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
これで、再起動しても networking.service が failed になることは無いはずだ。
--2017/04/20追記ココまで--
--2017/04/20削除ココから--
これで再起動してみると…。再現した！というか、状況はもっと悪くて、vg-kvmがアクティベートされてない！？
なるほど、networking.serviceを無効にしたら停止や再起動で刺さったような状態になるのか…。
実際にaquariusで停止を実行しようとすると、cifsアンマウントやiSCSI領域のアンマウント前にOpenvSwitchが停止しているように見える。
cifsやiSCSIは、OpenvSwitchのネットワークを経由して接続している。これらの停止前にOpenvSwitchが停止してはマズいのだ。
しかし、networking.serviceを有効にすると、systemctlでFaild:1unitsになってしまう。
これはこれで問題だ。
どうすりゃいいんだろうか。
「gfs2マウントについて(その1:自動マウント)」辺りと同じように、x-systemd.requiresを設定して対応するのではないだろうか？
ちょっと長いのと、調査に時間がかかるので、ここで一旦記事を切ろう。
--2017/04/20削除ココまで--
Intel NUCを使った弁当箱サイズのaquariusと、いわゆる自作マシンのミドルタワーサイズのsagittariusだ。
このマシンにUbuntu16.04を導入し、iSCSIイニシエータ、OpenvSwitch、KVM等を導入して運用している。
で、このマシン、実はシャットダウンやリブートで詰まる事象が起きている。
ファイルシステムアンマウント・ボリュームディアクティベートあたりで発生しているようで、多分「gfs2マウントについて(その1:自動マウント)」辺りと似たような問題だと睨んでいる。
ただ、仮想マシンではなく物理マシンのため、今までは見て見ぬふりをしていた。
再起動を伴う設定変更・確認は、物理マシンを相手にする場合は、物理マシンの直ぐ側にいないとリスキーなので。
ただ、仮想マシンでiSCSIが利用できることも確認できたので、仮想マシンで現象の再現、対応方法の確立をしようと思う。
とりあえず、gemini/cancer上でKVMを動かしたいので、一旦停止してgemini/cancerのCPU定義と割当メモリを変更する。
まずは停止。
(gemini) $ sudo shutdown -h now
(cancer) $ sudo shutdown -h now
停止しているのを確認して、両仮想マシンを編集。
(sagittarius) $ virsh list --all
(sagittarius) $ virsh edit gemini
(sagittarius) $ virsh edit cancer
gemini/cancerともに同じ修正を施す。
--ココから
4～5行目付近
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
↓(割当サイズを4GBにする)
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
17～18行目付近
<cpu mode='custom' match='exact'>
<model fallback='allow'>core2duo</model>
↓(CPUモデルをhost-modelに)
<cpu mode='host-model'>
<model fallback='allow'/>
--ココまで
ココまで出来たらgemini/cancerともに起動する。
(sagittarius) $ virsh start gemini
(sagittarius) $ virsh start cancer
後は、過去の内容を参照しながら作り込んでいく。(とりあえずgeminiに対してのみ更新。)
ざっとコマンド羅列。
(gemini) $ sudo apt-get update
(gemini) $ sudo apt-get install qemu-kvm
(gemini) $ sudo shutdown -r now
(gemini) $ grep kvm /etc/group
(gemini) $ id
(gemini) $ sudo adduser (自分のユーザ名) kvm
(gemini) $ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
(gemini) $ id
(gemini) $ lsmod | grep kvm
(gemini) $ sudo apt-get install virtinst
(gemini) $ sudo apt-get install libosinfo-bin
再ログイン
(gemini) $ virsh list --all
(gemini) $ sudo apt-get install virt-manager
(gemini) $ sudo apt-get install fonts-ipafont
(gemini) $ sudo apt-get install openvswitch-switch
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo ovs-vsctl add-br br-external
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ovs-vsctl list-br
(gemini) $ sudo vi /etc/network/interfaces.d/0110.ens3
ファイルの新規作成
--ココから--
auto ens3
allow-br-external
iface ens3 inet manual
ovs_bridge br-external
ovs_type OVSPort
--ココまで--
(gemini) $ sudo vi /etc/network/interfaces.d/0010.br-external
ファイルの新規作成
--ココから--
auto br-external
allow-ovs br-external
iface br-external inet static
address 192.168.55.136
network 192.168.55.0
netmask 255.255.255.0
broadcast 192.168.55.255
gateway 192.168.55.1
ovs_type OVSBridge
ovs_ports ens3
dns-nameservers 192.168.55.1
--ココまで--
--2017/04/14追記
ネットワークセッションが切れてしまうので、コンソールで作業しよう。
(gemini) $ sudo ifdown ens3
(gemini) $ sudo rm /etc/network/interfaces.d/ens3
(gemini) $ sudo ovs-vsctl add-port br-external ens3
(gemini) $ sudo ovs-vsctl show
(gemini) $ sudo ifup ens3
(gemini) $ sudo ifup br-external
--2017/04/14追記ココまで
--2017/04/20追記
このまま再起動させると、 OpenvSwitch/corosync/dlm/lvm2-cluster-activation の起動関連が上手く行かず、ハングしてしまう。
- OpenvSwitchが完全に起動
- corosync起動
- dlm起動
- lvm2-cluster-activation起動
そのため、起動順の制御と、OpenvSwitchの起動時に、少しsleepを置くことにする。
(gemini) $ cd /lib/systemd/system
(gemini) $ sudo cp -pi corosync.service corosync.service.orig
(gemini) $ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig
(gemini) $ sudo vi corosync.service
--ココから
Requires=network-online.target
After=network-online.target
↓(前提条件に openvswitch-switch.service を追加する)
Requires=network-online.target openvswitch-switch.service
After=network-online.target openvswitch-switch.service
--ココまで
(gemini) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓(何も実行しない処理を、6秒待機に変更する)
ExecStart=/bin/sleep 6
--ココまで
変更内容を取り込む。
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
--2017/04/20追記ココまで
(gemini) $ sudo shutdown -r now
(gemini) $ ip address show
(gemini) $ dig www.blogger.com
(gemini) $ sudo ovs-vsctl show
(gemini) $ virsh net-list --all
(gemini) $ vi ovsbridge.xml
ファイルの新規作成
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='br-external'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
(gemini) $ virsh net-define ovsbridge.xml
(gemini) $ virsh net-list --all
(gemini) $ virsh net-autostart ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ virsh net-start ovsbridge
(gemini) $ virsh net-list --all
(gemini) $ sudo apt-get install ovmf
-------------------------------------------------------------
がーっと作ってしまったが、iSCSIのボリューム以外はだいたいホストOSと同じになったはず。
この状態で再起動が上手くいくか確認。
(gemini) $ sudo shutdown -r now
特に問題無さそうだ。
iSCSIストレージ装置で、新しくiSCSIターゲットを作成、100GBのLUNを新たに繋いで、geminiにのみ接続させておく。
/dev/sdb として認識された。
そのディスクを、ホストOSと同じように領域確保＆ファイルシステム作成する。
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb mklabel gpt
(gemini) $ sudo parted /dev/sdb mkpart primary ext4 0% 100%
(gemini) $ sudo parted /dev/sdb toggle 1 lvm
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo pvcreate /dev/sdb1
(gemini) $ sudo vgcreate vg-kvm /dev/sdb1
(gemini) $ sudo vgchange -c n vg-kvm
(gemini) $ sudo vgdisplay -v vg-kvm
(gemini) $ sudo lvcreate -L 32M -n lv-etc-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 50G -n lv-var-lib-libvirt vg-kvm
(gemini) $ sudo lvcreate -L 2G -n lv-var-log-libvirt vg-kvm
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-etc-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo mkfs.ext4 /dev/vg-kvm/lv-var-log-libvirt
続いて、中身のコピー。
(gemini) $ sudo mkdir /tmp/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /etc
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /etc/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /etc/libvirt
(gemini) $ sudo mkdir /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-etc-libvirt /etc/libvirt
(gemini) $ df /etc/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/lib
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/lib/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/lib/libvirt
(gemini) $ sudo mkdir /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-lib-libvirt /var/lib/libvirt
(gemini) $ df /var/lib/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /tmp/libvirt
(gemini) $ df /tmp/libvirt
(gemini) $ sudo -i
(gemini) # cd /var/log
(gemini) # tar cSf - libvirt | ( cd /tmp ; tar xSf - )
(gemini) # ls -l /tmp/libvirt
(gemini) # ls -ld /tmp/libvirt /var/log/libvirt
(gemini) # exit
(gemini) $ sudo umount /tmp/libvirt
(gemini) $ sudo rm -rf /var/log/libvirt
(gemini) $ sudo mkdir /var/log/libvirt
(gemini) $ sudo mount /dev/vg-kvm/lv-var-log-libvirt /var/log/libvirt
(gemini) $ df /var/log/libvirt
(gemini) $ sudo rmdir /tmp/libvirt
fstabを更新
(gemini) $ sudo vi /etc/fstab
以下の行を追加
--ココから
/dev/mapper/vg--kvm-lv--etc--libvirt /etc/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--lib--libvirt /var/lib/libvirt ext4 _netdev 0 0
/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev 0 0
--ココまで
(gemini) $ sudo umount /etc/libvirt
(gemini) $ sudo umount /var/log/libvirt
(gemini) $ sudo umount /var/lib/libvirt
(gemini) $ sudo mount -a
(gemini) $ df
自動アクティベート対象にする。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近
auto_activation_volume_list = [ "gemini-vg" ]
↓項目追加
auto_activation_volume_list = [ "gemini-vg", "vg-kvm" ]
--ココまで
もう1つ、KVMホストは実はcifsマウントもしている。
(OSのisoメディアを配置するディスクはcifsにした。これなら別のWindowsマシンからも利用が可能だからだ。)
cifsマウント用のパッケージの導入
(gemini) $ sudo apt-get install cifs-utils
そのマウントポイントを作成する。
(gemini) $ sudo mkdir /mnt/iso-os
fstabに追記する。
(gemini) $ sudo vi /etc/fstab
以下の行を追記
--ココから
//(cifsのIPアドレス)/(cifsのディレクトリ) /mnt/iso-os cifs guest,_netdev 0 0
--ココまで
マウント確認
(gemini) $ sudo mount /mnt/iso-os
(gemini) $ df /mnt/iso-os
(gemini) $ sudo umount /mnt/iso-os
再起動してマウント状態の確認
(gemini) $ sudo shutdown -r now
(gemini) $ df
これでgeminiは、KVMホストのaquarius/sagittariusとほぼ同じ環境になったはずだ。
あれ…何度再起動しかけても、KVMホストマシンで発生している現象が起きない…な…。
そういえば、ココでnetworking.serviceを無効にしてたんだった。
それも適用してみよう。
(gemini) $ sudo systemctl stop networking.service
(gemini) $ sudo systemctl is-active networking.service
(gemini) $ sudo systemctl disable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
--2017/04/20追記--
そもそも、 networking.service が failed になる理由だけど…。
今回、 OpenvSwitch で br-external という仮想スイッチ(仮想デバイス)を作成している。物理デバイスは存在しないデバイスだ。
networking.service は、 /etc/network/interfaces と /etc/network/interfaces.d/* で auto に指定されているデバイスは起動時に有効にしようとするが、 br-external は物理デバイスが無いため、 networking.service では有効に出来ない。(openvswitch-nonetwork.service にて有効にされる。)
networking.service が failed になる理由は、起動時に br-external を有効化しようとしてコケるからだ。
というわけで、 br-external は networking.service からは有効化されないように設定しよう。
(gemini) $ sudo cp -pi /etc/default/networking /etc/default/netwoking.orig
(gemini) $ sudo vi /etc/default/networking
--ココから
8行目付近
#EXCLUDE_INTERFACES=
↓(br-externalを指定)
EXCLUDE_INTERFACES=br-external
--ココまで
(gemini) $ sudo systemctl daemon-reload
networking.service は有効化しておこう。
(gemini) $ sudo systemctl enable networking.service
(gemini) $ sudo systemctl is-enabled networking.service
これで、再起動しても networking.service が failed になることは無いはずだ。
--2017/04/20追記ココまで--
--2017/04/20削除ココから--
--2017/04/20削除ココまで--
2017年3月2日木曜日
VGのSharedフラグ
クラスタマークを付けたVG(vgchange -c y)に対してvgdisplayを実行すると、Clusterdというパラメータの他に、Sharedというパラメータが表示される。
このSharedは、いつ見ても「no」になっていて、一体このフラグが何を意味しているのか？どういう状況で「yes」に変わるのか？が分からないでいた。
というわけで、今回はこれを調べてみたい。
が…Webで調べてもマニュアルを読んでも、このあたり全然情報が無い。調べ方が悪いのか？
こうなってくると、もうソースを読んで見るしか無いわけだが…正直なところ、あまりやりたくない。
ので、軽く調べて「分かりませんでした」という結論にしたいと思う。
まずはソースコードの入手。
Ubuntuのパッケージ検索サイトから、キーワード「clvm」、Distribution「xenial」で検索し、ヒットした結果の「lvm2ソースパッケージのダウンロード」から[lvm2_2.02.133.orig.tar.xz]をダウンロードする。
とは言っても、gemini/cancerにはwebブラウザは導入していないので、ダウンロードurlをwget/curlで取得しよう。
(gemini) $ wget http://archive.ubuntu.com/ubuntu/pool/main/l/lvm2/lvm2_2.02.133.orig.tar.xz
もしくは
(gemini) $ curl http://archive.ubuntu.com/ubuntu/pool/main/l/lvm2/lvm2_2.02.133.orig.tar.xz > lvm2_2.02.133.orig.tar.xz
ダウンロードしたらファイルの展開だ。
.tar.xz形式なので、オプションに注意だ。
(gemini) $ tar tvJf lvm2_2.02.133.orig.tar.xz
(gemini) $ tar xvJf lvm2_2.02.133.orig.tar.xz
lvm2-2.02-133というディレクトリが作成され、その下に展開される。
(gemini) $ cd lvm2-2.02.133
ここからは、ソースファイル(.c)やヘッダファイル(.h)を色々漁って探してみる。
vgdisplayというファイルがあるかも。
(gemini) $ find . -name "*vgdisplay*" -print
./man/vgdisplay.8.in
./tools/vgdisplay.c
あった。
前者はマニュアルなので、後者(./tools/vgdisplay.c)がそれっぽい。
中身を確認してみよう。
(gemini) $ view ./tools/vgdisplay.c
う～ん。何かチガウな…。
「Shared」というキーワードで調べてみよう…。
(gemini) $ find . -type f -print | xargs grep Shared
30行ぐらい出て来るが、その中の1つにそれっぽい行がある。
./lib/display/display.c: log_print("Shared %s",
だ。
どうやら、./lib/display/display.cに、vgdisplayのSharedフラグを表示する行があるっぽい。
見てみよう。
(gemini) $ view ./lib/display/display.c
あったあった。
一部引用する。
--ココから
void vgdisplay_full(const struct volume_group *vg)
{
(略)
log_print("--- Volume group ---");
log_print("VG Name %s", vg->name);
(略)
if (vg_is_clustered(vg)) {
log_print("Clustered yes");
log_print("Shared %s",
vg->status & SHARED ? "yes" : "no");
}
(略)
log_print(" ");
}
--引用ココまで
なるほど、vg構造体ポインタのstatus値でSHAREDフラグが立っていたら「yes」、立っていいなければ「no」か。
(構造体やら論理式やら三項演算子やらが入った行なので、分からなければ「一応、no固定で出しているわけじゃなく、yesかnoかを判定する処理は入ってるんだな」程度の理解でいいだろう。)
vg構造体(volume_group構造体)のstatusフラグか…。一体ドコに更新処理が入ってるんだろう…？この値が更新されないと、Sharedがyesになることは無いんだよな…。
ちょっと検索。
(gemini) $ find . -type f -print | xargs grep status | grep SHARED
う～む。
./lib/format1/import-export.c
./lib/format_pool/import_export.c
の2つのファイルで、SHAREDフラグを立ててるっぽいなぁ。
逆に、フラグを倒す部分が見つからなかった。検索漏れかな？
とりあえず、両ファイルを見てみるか。
(gemini) $ view ./lib/format1/import-export.c
(gemini) $ view ./lib/format_pool/import_export.c
後者はちょっと分からなかった…。
前者は、
なんじゃそりゃ…。結局、明示的にSHAREDフラグを立てる方法は無いんかい！？
更に色々見ていったら、vgcreateのmanに、--sharedというオプションがある。
これ、vgcreate時に指定できるけど、vgchangeで変更出来るようには見えない。もしかしたら、vgchange --lock-typeで変更出来るのか…？
いずれにしても、lvmlockdというのが関連しているようなんだけど、Ubuntuにはlvmlockdは実装されていないっぽい。
もはや、vgのSharedフラグは無視してもいいんじゃないか…。
Sharedフラグがlvmlockdに関連すると仮定して、更にwebを調べてみたら、lvmlockdを使用する場合は/etc/lvm/lvm.confのlocking_typeを1(LVM uses local file-based locking, the standard mode.)に設定する必要があるようだ。
CLVMを用いる場合は、同フラグを3(LVM uses built-in clustered locking with clvmd.)に設定するため、どうやらCLVMとlvmlockdは排他使用のようだ。
Ubuntu16.04にはlvmlockdは実装されていないっぽい＆CLVMとlvmlockdは競合する、ということで、これ以上の調査は止めよう。
ということで、Sharedフラグは無視することに。
このSharedは、いつ見ても「no」になっていて、一体このフラグが何を意味しているのか？どういう状況で「yes」に変わるのか？が分からないでいた。
というわけで、今回はこれを調べてみたい。
が…Webで調べてもマニュアルを読んでも、このあたり全然情報が無い。調べ方が悪いのか？
こうなってくると、もうソースを読んで見るしか無いわけだが…正直なところ、あまりやりたくない。
ので、軽く調べて「分かりませんでした」という結論にしたいと思う。
まずはソースコードの入手。
Ubuntuのパッケージ検索サイトから、キーワード「clvm」、Distribution「xenial」で検索し、ヒットした結果の「lvm2ソースパッケージのダウンロード」から[lvm2_2.02.133.orig.tar.xz]をダウンロードする。
とは言っても、gemini/cancerにはwebブラウザは導入していないので、ダウンロードurlをwget/curlで取得しよう。
(gemini) $ wget http://archive.ubuntu.com/ubuntu/pool/main/l/lvm2/lvm2_2.02.133.orig.tar.xz
もしくは
(gemini) $ curl http://archive.ubuntu.com/ubuntu/pool/main/l/lvm2/lvm2_2.02.133.orig.tar.xz > lvm2_2.02.133.orig.tar.xz
ダウンロードしたらファイルの展開だ。
.tar.xz形式なので、オプションに注意だ。
(gemini) $ tar tvJf lvm2_2.02.133.orig.tar.xz
(gemini) $ tar xvJf lvm2_2.02.133.orig.tar.xz
lvm2-2.02-133というディレクトリが作成され、その下に展開される。
(gemini) $ cd lvm2-2.02.133
ここからは、ソースファイル(.c)やヘッダファイル(.h)を色々漁って探してみる。
vgdisplayというファイルがあるかも。
(gemini) $ find . -name "*vgdisplay*" -print
./man/vgdisplay.8.in
./tools/vgdisplay.c
あった。
前者はマニュアルなので、後者(./tools/vgdisplay.c)がそれっぽい。
中身を確認してみよう。
(gemini) $ view ./tools/vgdisplay.c
う～ん。何かチガウな…。
「Shared」というキーワードで調べてみよう…。
(gemini) $ find . -type f -print | xargs grep Shared
30行ぐらい出て来るが、その中の1つにそれっぽい行がある。
./lib/display/display.c: log_print("Shared %s",
だ。
どうやら、./lib/display/display.cに、vgdisplayのSharedフラグを表示する行があるっぽい。
見てみよう。
(gemini) $ view ./lib/display/display.c
あったあった。
一部引用する。
--ココから
void vgdisplay_full(const struct volume_group *vg)
{
(略)
log_print("--- Volume group ---");
log_print("VG Name %s", vg->name);
(略)
if (vg_is_clustered(vg)) {
log_print("Clustered yes");
log_print("Shared %s",
vg->status & SHARED ? "yes" : "no");
}
(略)
log_print(" ");
}
--引用ココまで
なるほど、vg構造体ポインタのstatus値でSHAREDフラグが立っていたら「yes」、立っていいなければ「no」か。
(構造体やら論理式やら三項演算子やらが入った行なので、分からなければ「一応、no固定で出しているわけじゃなく、yesかnoかを判定する処理は入ってるんだな」程度の理解でいいだろう。)
vg構造体(volume_group構造体)のstatusフラグか…。一体ドコに更新処理が入ってるんだろう…？この値が更新されないと、Sharedがyesになることは無いんだよな…。
ちょっと検索。
(gemini) $ find . -type f -print | xargs grep status | grep SHARED
う～む。
./lib/format1/import-export.c
./lib/format_pool/import_export.c
の2つのファイルで、SHAREDフラグを立ててるっぽいなぁ。
逆に、フラグを倒す部分が見つからなかった。検索漏れかな？
とりあえず、両ファイルを見てみるか。
(gemini) $ view ./lib/format1/import-export.c
(gemini) $ view ./lib/format_pool/import_export.c
後者はちょっと分からなかった…。
前者は、
- vgをexportする時、当該vgのSHAREDフラグが立ってたら、export情報にもSHARED情報を載せるよ。
- vgをimportする時、入力情報にSHARED情報が載っていたら、import時にSHAREDフラグを立てるよ。
なんじゃそりゃ…。結局、明示的にSHAREDフラグを立てる方法は無いんかい！？
更に色々見ていったら、vgcreateのmanに、--sharedというオプションがある。
これ、vgcreate時に指定できるけど、vgchangeで変更出来るようには見えない。もしかしたら、vgchange --lock-typeで変更出来るのか…？
いずれにしても、lvmlockdというのが関連しているようなんだけど、Ubuntuにはlvmlockdは実装されていないっぽい。
もはや、vgのSharedフラグは無視してもいいんじゃないか…。
Sharedフラグがlvmlockdに関連すると仮定して、更にwebを調べてみたら、lvmlockdを使用する場合は/etc/lvm/lvm.confのlocking_typeを1(LVM uses local file-based locking, the standard mode.)に設定する必要があるようだ。
CLVMを用いる場合は、同フラグを3(LVM uses built-in clustered locking with clvmd.)に設定するため、どうやらCLVMとlvmlockdは排他使用のようだ。
Ubuntu16.04にはlvmlockdは実装されていないっぽい＆CLVMとlvmlockdは競合する、ということで、これ以上の調査は止めよう。
ということで、Sharedフラグは無視することに。
2017年2月28日火曜日
LVMの自動アクティベートを停止
前回の最後に、「OS起動時に当該LVOLが自動的にアクティベーションされないように設定する」って書いた。
これは、HAクラスタ等を組んでいる場合、共有ボリュームのアクティベーションはOS起動時ではなく、クラスタソフトの方で制御して欲しいからだ。
ただ、今回の構成・目的では、そちらの意味はあまり無い。
共有ファイルシステムを使用しているので、アクティベーションされるのなら共有モードでアクティベーションされて欲しいから、ちょっと使用目的は違う。
のだが、OS起動時の自動アクティベートを調べておきたい、というのが今回の目的。
てっきり、vgchange -aay / -aanというオプションで、自動アクティベートをOn/Off出来ると踏んでいたのだが、どうやら違うようだ。そもそも、-aanというオプションは存在しない模様。
vgchangeのマニュアルを読んでみると、-aay は /etc/lvm/lvm.confのactivation/auto_activation_volume_listに記載されているボリュームを、自動的にアクティベーションする、という意味のようだ。
/etc/fstabに記載されているエントリを一斉にマウントする、mount -a と同じような意味合いか。
逆に、activation/auto_activation_volume_list が未記載の場合は、全てのボリュームをアクティベートしてしまうようだ。
なるほど、システム起動時(OS起動時)にアクティベーションして欲しいボリュームを、activation/auto_activation_volume_list に記載して、アクティベーションして欲しくないボリュームを記載しないことで、OS起動時に自動アクティベートされないようになるようだ。
さっそく実験してみよう。
まずは、当該ボリュームをアンマウント・ディアクティベートしておく。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo systemctl stop /mnt/gfs2
(gemini) $ sudo vgchange -aln vg-ocfs2
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
一旦再起動して、vg-ocfs2/vg-gfs2が両方共アクティベートされるか確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
lvolがavailableになっているだろうか？
OSを構成するVGの名前を確認しておこう。
(gemini) $ sudo vgs
VG #PV #LV #SN Attr VSize VFree
gemini-vg 1 2 0 wz--n- 72.02g 32.00m
vg-gfs2 1 1 0 wz--nc 10.00g 5.00g
vg-ocfs2 1 1 0 wz--nc 10.00g 5.00g
geminiは、OSインストールメディアのお任せにしていたので、gemini-vgという名前のようだ。
続いて、/etc/lvm/lvm.confを以下のように書き換える。(今回は、vg-gfs2とvg-ocfs2で敢えて変えておく。vg-ocfs2を自動アクティベートされないようにしておく。)
(gemini) $ sudo vi /etc/lvm/lvm.conf
「activation {」で始まる行を探そう。
そのブロックの中に、auto_activation_volume_listの説明文がある。(こちらの環境では、1120行目あたりからだ。)
そのコメント文の下部(こちらの環境では、1156行目あたり)に、以下の行を追記しよう。
--ココから
auto_activation_volume_list = [ "gemini-vg", "vg-gfs2" ]
--ココまで
さて、これでイイのかな？
一旦、両ボリューム(vg-ocfs2/vg-gfs2)をディアクティベートしておく。
(gemini) $ sudo vgchange -aln vg-ocfs2
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
lvmの設定変更を反映させてみる。(これでいいのかな？)
(gemini) $ sudo systemctl daemon-reload
auto_activateを試してみる。
(gemini) $ sudo vgchange -aay
さてどうなったかな？
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
お、狙ったとおり、vg-ocfs2はディアクティベートのまま、vg-gfs2はアクティベートされたぞ。
じゃ、OS起動時はどうだ？
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo shutdown -r now
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
期待したとおり、vg-ocfs2はディアクティベート、vg-gfs2はアクティベートだ。
これで、自動アクティベートの制御は分かった。
とりあえず、gemini/cancerともに、vg-ocfs2/vg-gfs2は自動アクティベートされないように設定しておこう。
(gemini) $ sudo vi /etc/lvm/lvm.conf
先程追記した行を書き換え。
--ココから
auto_activation_volume_list = [ "gemini-vg", "vg-gfs2" ]
↓
auto_activation_volume_list = [ "gemini-vg" ]
--ココまで
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo vgs
VG #PV #LV #SN Attr VSize VFree
cancer-vg 1 2 0 wz--n- 72.02g 32.00m
vg-gfs2 1 1 0 wz--nc 10.00g 5.00g
vg-ocfs2 1 1 0 wz--nc 10.00g 5.00g
OSのvgの名前はcancer-vgのようだ。
(cancer) $ sudo vi /etc/lvm/lvm.conf
1156行目付近に以下の行を追記。
--ココから
auto_activation_volume_list = [ "cancer-vg" ]
--ココまで
(cancer) $ sudo systemctl daemon-reload
さて今回はココまで。
次は、クラスタマーク付き(vgchange -cy)のvgに対してvgdisplayを実行したら表示される「Shared」の意味を調べてみよう。
(正直なところ、結論が出せるか自信がない。)
これは、HAクラスタ等を組んでいる場合、共有ボリュームのアクティベーションはOS起動時ではなく、クラスタソフトの方で制御して欲しいからだ。
ただ、今回の構成・目的では、そちらの意味はあまり無い。
共有ファイルシステムを使用しているので、アクティベーションされるのなら共有モードでアクティベーションされて欲しいから、ちょっと使用目的は違う。
のだが、OS起動時の自動アクティベートを調べておきたい、というのが今回の目的。
てっきり、vgchange -aay / -aanというオプションで、自動アクティベートをOn/Off出来ると踏んでいたのだが、どうやら違うようだ。そもそも、-aanというオプションは存在しない模様。
vgchangeのマニュアルを読んでみると、-aay は /etc/lvm/lvm.confのactivation/auto_activation_volume_listに記載されているボリュームを、自動的にアクティベーションする、という意味のようだ。
/etc/fstabに記載されているエントリを一斉にマウントする、mount -a と同じような意味合いか。
逆に、activation/auto_activation_volume_list が未記載の場合は、全てのボリュームをアクティベートしてしまうようだ。
なるほど、システム起動時(OS起動時)にアクティベーションして欲しいボリュームを、activation/auto_activation_volume_list に記載して、アクティベーションして欲しくないボリュームを記載しないことで、OS起動時に自動アクティベートされないようになるようだ。
さっそく実験してみよう。
まずは、当該ボリュームをアンマウント・ディアクティベートしておく。
(gemini) $ sudo systemctl stop /mnt/ocfs2
(gemini) $ sudo systemctl stop /mnt/gfs2
(gemini) $ sudo vgchange -aln vg-ocfs2
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
一旦再起動して、vg-ocfs2/vg-gfs2が両方共アクティベートされるか確認だ。
(gemini) $ sudo shutdown -r now
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
lvolがavailableになっているだろうか？
OSを構成するVGの名前を確認しておこう。
(gemini) $ sudo vgs
VG #PV #LV #SN Attr VSize VFree
gemini-vg 1 2 0 wz--n- 72.02g 32.00m
vg-gfs2 1 1 0 wz--nc 10.00g 5.00g
vg-ocfs2 1 1 0 wz--nc 10.00g 5.00g
geminiは、OSインストールメディアのお任せにしていたので、gemini-vgという名前のようだ。
続いて、/etc/lvm/lvm.confを以下のように書き換える。(今回は、vg-gfs2とvg-ocfs2で敢えて変えておく。vg-ocfs2を自動アクティベートされないようにしておく。)
(gemini) $ sudo vi /etc/lvm/lvm.conf
「activation {」で始まる行を探そう。
そのブロックの中に、auto_activation_volume_listの説明文がある。(こちらの環境では、1120行目あたりからだ。)
そのコメント文の下部(こちらの環境では、1156行目あたり)に、以下の行を追記しよう。
--ココから
auto_activation_volume_list = [ "gemini-vg", "vg-gfs2" ]
--ココまで
さて、これでイイのかな？
一旦、両ボリューム(vg-ocfs2/vg-gfs2)をディアクティベートしておく。
(gemini) $ sudo vgchange -aln vg-ocfs2
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
lvmの設定変更を反映させてみる。(これでいいのかな？)
(gemini) $ sudo systemctl daemon-reload
auto_activateを試してみる。
(gemini) $ sudo vgchange -aay
さてどうなったかな？
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
お、狙ったとおり、vg-ocfs2はディアクティベートのまま、vg-gfs2はアクティベートされたぞ。
じゃ、OS起動時はどうだ？
(gemini) $ sudo vgchange -aln vg-gfs2
(gemini) $ sudo shutdown -r now
(gemini) $ sudo vgdisplay -v vg-ocfs2
(gemini) $ sudo vgdisplay -v vg-gfs2
期待したとおり、vg-ocfs2はディアクティベート、vg-gfs2はアクティベートだ。
これで、自動アクティベートの制御は分かった。
とりあえず、gemini/cancerともに、vg-ocfs2/vg-gfs2は自動アクティベートされないように設定しておこう。
(gemini) $ sudo vi /etc/lvm/lvm.conf
先程追記した行を書き換え。
--ココから
auto_activation_volume_list = [ "gemini-vg", "vg-gfs2" ]
↓
auto_activation_volume_list = [ "gemini-vg" ]
--ココまで
(gemini) $ sudo systemctl daemon-reload
(cancer) $ sudo vgs
VG #PV #LV #SN Attr VSize VFree
cancer-vg 1 2 0 wz--n- 72.02g 32.00m
vg-gfs2 1 1 0 wz--nc 10.00g 5.00g
vg-ocfs2 1 1 0 wz--nc 10.00g 5.00g
OSのvgの名前はcancer-vgのようだ。
(cancer) $ sudo vi /etc/lvm/lvm.conf
1156行目付近に以下の行を追記。
--ココから
auto_activation_volume_list = [ "cancer-vg" ]
--ココまで
(cancer) $ sudo systemctl daemon-reload
さて今回はココまで。
次は、クラスタマーク付き(vgchange -cy)のvgに対してvgdisplayを実行したら表示される「Shared」の意味を調べてみよう。
(正直なところ、結論が出せるか自信がない。)
2016年8月9日火曜日
仮想マシンのHDDを拡大
今、piscesのOS用仮想HDDは3.5GB、ariesのOS用仮想HDDは2GBしか割り当てていない。
(aquarius) $ virsh pool-list
名前 状態 自動起動
-------------------------------------------
default 動作中 はい (yes)
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
(aquarius) $ virsh vol-list --pool default
名前 パス
------------------------------------------------------------------------------
aries.qcow2 /var/lib/libvirt/images/aries.qcow2
pisces.qcow2 /var/lib/libvirt/images/pisces.qcow2
ubuntu-14.04.4-server-amd64.iso /var/lib/libvirt/images/ubuntu-14.04.4-server-amd64.iso
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 3.50 GiB
割り当て: 1.85 GiB
(aquarius) $ virsh vol-info aries.qcow2 --pool default
名前: aries.qcow2
タイプ: ファイル
容量: 2.00 GiB
割り当て: 1.34 GiB
これでは、今後実験していく上で、あまりにも容量が少なすぎる。
これを拡大したい。
どれぐらいまで拡大できるだろうか？poolの利用可能容量が約45GBなので、それ以上に割り当てようとするとエラーになるのだろうか？
ちょっと試してみよう。
(念のため、仮想マシンは止めておくこと)
(aquarius) $ virsh vol-resize pisces.qcow2 72G --pool default
ボリューム 'pisces.qcow2' の容量を 72G に正常に変更しました
できたっぽい。
念のため確認。
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 72.00 GiB
割り当て: 1.85 GiB
出来た。
一応、起動してゲストOS側から確認してみよう。
(aquarius) $ virsh start pisces
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 3757MB 3500MB extended
5 257MB 3757MB 3500MB logical lvm
どうやら、拡大されているっぽいな。
ただし、パーティションサイズとpv(Phisical Volume)は構築当初のサイズのままだ。
これを拡大しないといけない。(末尾まで延ばしてしまおう)
まずはパーティションの拡大だ。(mbr形式の拡張領域なので、拡張パーティションと論理パーティションの両方を拡大する必要があるぞ。)
(pisces) $ sudo parted /dev/vda resizepart 2 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 3757MB 3500MB logical lvm
(pisces) $ sudo parted /dev/vda resizepart 5 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 77.3GB 77.1GB logical lvm
次いで、Phisical Volumeの拡張だ。これ上手くいくかな？
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 3.26g 0
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 3.26g 0
(pisces) $ sudo pvresize /dev/vda5
Physical volume "/dev/vda5" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 71.76g 68.50g
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 71.76g 68.50g
あっさり拡張できてしまった。
ついでに、/領域(/dev/pisces-vg/root)も4GBに拡張しておこう。
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 2.76g
(pisces) $ sudo lvextend -L 4G pisces-vg/root
Extending logical volume root to 4.00 GiB
Logical volume root successfully resized
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 4.00g
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 2.7G 1.2G 1.4G 46% /
(pisces) $ sudo resize2fs /dev/pisces-vg/root
Filesystem at /dev/pisces-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/pisces-vg/root is now 1048576 blocks long.
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 3.9G 1.2G 2.6G 31% /
piscesの拡張が出来たので、piscesは一旦シャットダウンしておこう。
(pisces) $ sudo shutdown -h now
ariesも同じように拡張しておく。
やり方は同じなので、コマンドだけ羅列しておく。
(aquarius) $ virsh vol-resize aries.qcow2 72G --pool default
(aquarius) $ virsh vol-info aries.qcow2 --pool default
(aquarius) $ virsh start aries
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 2 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 5 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo pvresize /dev/vda5
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ sudo lvextend -L 4G aries-vg/root
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo resize2fs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo shutdown -h now
終わった後のpoolの状態も確認しておこう。
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
問題なさそうだ。
(aquarius) $ virsh pool-list
名前 状態 自動起動
-------------------------------------------
default 動作中 はい (yes)
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
(aquarius) $ virsh vol-list --pool default
名前 パス
------------------------------------------------------------------------------
aries.qcow2 /var/lib/libvirt/images/aries.qcow2
pisces.qcow2 /var/lib/libvirt/images/pisces.qcow2
ubuntu-14.04.4-server-amd64.iso /var/lib/libvirt/images/ubuntu-14.04.4-server-amd64.iso
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 3.50 GiB
割り当て: 1.85 GiB
(aquarius) $ virsh vol-info aries.qcow2 --pool default
名前: aries.qcow2
タイプ: ファイル
容量: 2.00 GiB
割り当て: 1.34 GiB
これでは、今後実験していく上で、あまりにも容量が少なすぎる。
これを拡大したい。
どれぐらいまで拡大できるだろうか？poolの利用可能容量が約45GBなので、それ以上に割り当てようとするとエラーになるのだろうか？
ちょっと試してみよう。
(念のため、仮想マシンは止めておくこと)
(aquarius) $ virsh vol-resize pisces.qcow2 72G --pool default
ボリューム 'pisces.qcow2' の容量を 72G に正常に変更しました
できたっぽい。
念のため確認。
(aquarius) $ virsh vol-info pisces.qcow2 --pool default
名前: pisces.qcow2
タイプ: ファイル
容量: 72.00 GiB
割り当て: 1.85 GiB
出来た。
一応、起動してゲストOS側から確認してみよう。
(aquarius) $ virsh start pisces
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 3757MB 3500MB extended
5 257MB 3757MB 3500MB logical lvm
どうやら、拡大されているっぽいな。
ただし、パーティションサイズとpv(Phisical Volume)は構築当初のサイズのままだ。
これを拡大しないといけない。(末尾まで延ばしてしまおう)
まずはパーティションの拡大だ。(mbr形式の拡張領域なので、拡張パーティションと論理パーティションの両方を拡大する必要があるぞ。)
(pisces) $ sudo parted /dev/vda resizepart 2 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 3757MB 3500MB logical lvm
(pisces) $ sudo parted /dev/vda resizepart 5 100%
(pisces) $ sudo parted /dev/vda print
モデル: Virtio Block Device (virtblk)
ディスク /dev/vda: 77.3GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: msdos
番号 開始 終了 サイズ タイプ ファイルシステム フラグ
1 1049kB 256MB 255MB primary ext2 boot
2 257MB 77.3GB 77.1GB extended
5 257MB 77.3GB 77.1GB logical lvm
次いで、Phisical Volumeの拡張だ。これ上手くいくかな？
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 3.26g 0
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 3.26g 0
(pisces) $ sudo pvresize /dev/vda5
Physical volume "/dev/vda5" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
(pisces) $ sudo pvs /dev/vda5
PV VG Fmt Attr PSize PFree
/dev/vda5 pisces-vg lvm2 a-- 71.76g 68.50g
(pisces) $ sudo vgs pisces-vg
VG #PV #LV #SN Attr VSize VFree
pisces-vg 1 2 0 wz--n- 71.76g 68.50g
あっさり拡張できてしまった。
ついでに、/領域(/dev/pisces-vg/root)も4GBに拡張しておこう。
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 2.76g
(pisces) $ sudo lvextend -L 4G pisces-vg/root
Extending logical volume root to 4.00 GiB
Logical volume root successfully resized
(pisces) $ sudo lvs /dev/pisces-vg/root
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root pisces-vg -wi-ao--- 4.00g
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 2.7G 1.2G 1.4G 46% /
(pisces) $ sudo resize2fs /dev/pisces-vg/root
Filesystem at /dev/pisces-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/pisces-vg/root is now 1048576 blocks long.
(pisces) $ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/pisces--vg-root 3.9G 1.2G 2.6G 31% /
piscesの拡張が出来たので、piscesは一旦シャットダウンしておこう。
(pisces) $ sudo shutdown -h now
ariesも同じように拡張しておく。
やり方は同じなので、コマンドだけ羅列しておく。
(aquarius) $ virsh vol-resize aries.qcow2 72G --pool default
(aquarius) $ virsh vol-info aries.qcow2 --pool default
(aquarius) $ virsh start aries
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 2 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo parted /dev/vda resizepart 5 100%
(aries) $ sudo parted /dev/vda print
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo pvresize /dev/vda5
(aries) $ sudo pvs /dev/vda5
(aries) $ sudo vgs aries-vg
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ sudo lvextend -L 4G aries-vg/root
(aries) $ sudo lvs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo resize2fs /dev/aries-vg/root
(aries) $ df -h /
(aries) $ sudo shutdown -h now
終わった後のpoolの状態も確認しておこう。
(aquarius) $ virsh pool-info default
名前: default
UUID: (略)
状態: 実行中
永続: はい (yes)
自動起動: はい (yes)
容量: 49.09 GiB
割り当て: 3.81 GiB
利用可能: 45.28 GiB
問題なさそうだ。
登録:
投稿 (Atom)