ラベル fstab の投稿を表示しています。 すべての投稿を表示
ラベル fstab の投稿を表示しています。 すべての投稿を表示

2017年6月8日木曜日

cancer で共有ボリュームをマウント

続いて共有ボリュームのマウントだ。

単純に /etc/fstab を書き換えて、OS再起動等でイケるんだけど…。
今回 cancer を再作成している過程で、ちょっと気になる点があった。

今まで、sagittarius / aquarius / gemini でgfs2共有ボリュームをマウントする時、「x-systemd.requires=dlm.service」という条件を付けていた。
gfs2 をマウントするだけならこれでいいんだけど、clvmd(lvm2-clvmd.service) によって管理され、lvm2-cluster-activation.service によってアクティベートされる領域は、前提条件が変わってくるのではないだろうか?

実際に、/lib/systemd/system/lvm2-clvmd.service には「After=dlm.service corosync.service」という条件が付いており、 /lib/systemd/system/lvm2-cluster-activation.service には「After=lvm2-clvmd.service」という条件が付いている。

つまり、dlm.service、lvm2-clvmd.service、lvm2-cluster-activation.serivce の3つのサービスの起動順は、
  1. dlm.service
  2. lvm2-clvmd.service
  3. lvm2-cluster-activation.service
になっているはず。
そして、CLVM管理のボリュームは、最後の lvm2-cluster-activation.service によってアクティベーションされるということを考えると、このボリュームはこのサービスの起動後出ないとマウント出来ないはずだ。

つまり、/etc/fstab につける条件は、「x-systemd.requires=dlm.service」ではなく「x-systemd.requires=lvm2-cluster-activation.service」だと考えられる。

という前提を踏まえて、作業開始。
/etc/fstab 書き換え
(cancer) $ sudo vi /etc/fstab
--ココから
以下の行を追加
/dev/mapper/vg--gfs2-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=lvm2-cluster-activation.service 0 0
/dev/mapper/vg--gfs2-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=lvm2-cluster-activation.service 0 0
--ココまで

追記が終わったら反映させてみる。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl start /etc/libvirt
(cancer) $ sudo systemctl start /var/lib/libvirt
(cancer) $ df
(cancer) $ ls -ld /etc/libvirt
(cancer) $ ls -ld /var/lib/libvirt
マウント出来たようだ。

この状態なら、libvirt に OpenvSwitch が使えるようになっているはずだけど…
(cancer) $ virsh net-list --all
(cancer) $ virsh list --all
まだ libvirt に反映されていない。

というわけで、libvirt-bin を再読込み。
(cancer) $ sudo systemctl reload libvirt-bin.service
(cancer) $ virsh net-list --all
(cancer) $ virsh list --all
無事に認識された。

後は OS再起動できちんとマウントされるかどうか…。
(cancer) $ sudo systemctl reboot
(cancer) $ df
問題なくマウント出来ている。
(cancer) $ virsh list --all
(cancer) $ virsh net-list --all
libvirt の方も共有ディスク側の情報を得ているようだ。

…が…
何度か再起動確認をしていったら、停止時は問題出てないが、起動時に corosync/dlm が上手く起動しない現象がまた発生。(一回だけ)
イマイチ原因がつかめない。
う~ん…。その後何度か再起動しているが、発生したのは一回だけ…。う~ん…。

気を取り直して…。
sagittarius / aquarius / gemini の /etc/fstab も合わせて書き換えておこう。
$ sudo vi /etc/fstab
--
x-systemd.requires=dlm.service を x-systemd.requires=lvm2-cluster-activation.service に書き換え(2箇所?)
--
$ cat /run/systemd/generator/etc-libvirt.mount
$ cat /run/systemd/generator/var-lib-libvirt.mount
$ sudo systemctl daemon-reload
$ cat /run/systemd/generator/etc-libvirt.mount
$ cat /run/systemd/generator/var-lib-libvirt.mount

これでオシマイ。

2017年5月29日月曜日

autofs 設定を aquarius に

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

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

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

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

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

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

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

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

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

2017年5月27日土曜日

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

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

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

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

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

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

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

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

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

これでいいのかな?

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

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

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

2017年5月26日金曜日

sagittarius の整理

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

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

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

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

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

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

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

/dev/mapper/kvmcluster-etc--libvirt /etc/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
/dev/mapper/kvmcluster-var--lib--libvirt /var/lib/libvirt gfs2 _netdev,x-systemd.requires=dlm.service 0 0
#/dev/mapper/vg--kvm-lv--var--log--libvirt /var/log/libvirt ext4 _netdev,x-systemd.requires=openvswitch-switch.service 0 0
--ココまで

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

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

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

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

2017年4月21日金曜日

cancerをgeminiと同格までセットアップ

ずっと gemini でセットアップを行っていたので、今は gemini と cancer のセットアップ情報に差異がある。
gemini である程度問題解決が出来たので、cancer を gemini と同程度になるようにセットアップすることにする。

ダダっと書いていく。
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install qemu-kvm
(cancer) $ sudo systemctl reboot

(cancer) $ grep kvm /etc/group
(cancer) $ id
(cancer) $ sudo adduser (自分のユーザ名) kvm
(cancer) $ grep kvm /etc/group
(一旦exitで抜けて、再度ログイン)
(cancer) $ id

(cancer) $ lsmod | grep kvm
(cancer) $ sudo apt-get install virtinst libosinfo-bin virt-manager fonts-ipafont
(cancer) $ sudo systemctl reboot

再ログイン
(cancer) $ virsh list --all

(cancer) $ sudo apt-get install openvswitch-switch
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl list-br
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl list-br

(cancer) $ cd /lib/systemd/system
(cancer) $ sudo cp -pi corosync.service corosync.service.orig
(cancer) $ sudo cp -pi openvswitch-switch.service openvswitch-switch.service.orig

(cancer) $ 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
--ココまで

(cancer) $ sudo vi openvswitch-switch.service
--ココから
ExecStart=/bin/true
↓(何も実行しない処理を、6秒待機に変更する)
ExecStart=/bin/sleep 6
--ココまで

(cancer) $ cd
(cancer) $ sudo vi /etc/network/interfaces.d/0110.ens3
ファイルの新規作成
--ココから--
auto ens3
allow-extsw
iface ens3 inet manual
ovs_bridge extsw
ovs_type OVSPort
--ココまで--

(cancer) $ sudo vi /etc/network/interfaces.d/0010.extsw
ファイルの新規作成
--ココから--
auto extsw
allow-ovs extsw
iface extsw inet static
address 192.168.55.137
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
--ココまで--

ネットワークセッションが切れてしまうので、コンソールで作業しよう。
(cancer) $ sudo ifdown ens3
(cancer) $ sudo rm /etc/network/interfaces.d/ens3
(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw

変更内容を取り込む。
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
コンソール作業はココまで

(cancer) $ ip address show
(cancer) $ dig www.blogger.com
(cancer) $ sudo ovs-vsctl show

(cancer) $ virsh net-list --all
(cancer) $ vi ovsbridge.xml
ファイルの新規作成
--ここから
<network>
<name>ovsbridge</name>
<forward mode='bridge'/>
<bridge name='extsw'/>
<virtualport type='openvswitch'/>
</network>
--ここまで
(cancer) $ virsh net-define ovsbridge.xml
(cancer) $ virsh net-list --all

(cancer) $ virsh net-autostart ovsbridge
(cancer) $ virsh net-start ovsbridge
(cancer) $ virsh net-list --all

(cancer) $ sudo apt-get install ovmf

gemini はココで gemini 専用の iSCSIターゲット、LUN を作って作業を行ったが、cancer に対しては実施しないでおく。

(cancer) $ sudo apt-get install cifs-utils
(cancer) $ sudo mkdir /mnt/iso-os

fstabに追記する。
(cancer) $ sudo vi /etc/fstab
以下の行を追記
--ココから
//(cifsのIPアドレス)/(cifsのディレクトリ) /mnt/iso-os cifs guest,_netdev 0 0
--ココまで

マウント確認
(cancer) $ sudo mount /mnt/iso-os
(cancer) $ df /mnt/iso-os
(cancer) $ sudo umount /mnt/iso-os

再起動してマウント状態の確認
(cancer) $ sudo systemctl reboot
(cancer) $ df

(cancer) $ sudo cp -pi /etc/default/networking /etc/default/netwoking.orig
(cancer) $ sudo vi /etc/default/networking
--ココから
8行目付近
#EXCLUDE_INTERFACES=
↓(extswを指定)
EXCLUDE_INTERFACES=extsw
--ココまで

(cancer) $ systemctl is-enabled clvm
(cancer) $ sudo systemctl disable clvm
(cancer) $ systemctl is-enabled clvm

(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot

こんなところかな?

2017年4月13日木曜日

幾つか記事の修正を

結局、corosyncの起動失敗に関しては、結論が出なかった。
そのため、corosync/dlmとlibvirt関連、KVM関連、及びKVM/libvirtが使用するファイルシステムのマウントは、OS起動時ではなくOS起動後、手作業で実施することにしよう。

また、過去の記事もかなり誤りが見つかったので、この辺りの記事から見直して加筆修正する。
直接記事を加筆修正するので、一度確認してみて欲しい。
--2017/04/20追記ココから--
とりあえず記事を修正してみた。
まだ抜け漏れあるかもしれないけど、気付いたら追記していく。
--2017/04/20追記ココまで--

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 の起動関連が上手く行かず、ハングしてしまう。
  1. OpenvSwitchが完全に起動
  2. corosync起動
  3. dlm起動
  4. lvm2-cluster-activation起動
の順で起動して欲しいのだが、OpenvSwitchの起動処理が完全に終わる前にcorosyncが起動してしまい、その後の起動処理が不安定になってしまう。

そのため、起動順の制御と、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削除ココまで--

2017年2月10日金曜日

ファイルシステムマウント変更(/etc/fstab変更)

前回までで、gfs2をマウントする流れが理解できて設定方法も分かった。
はずなんだけど、1つ漏れていた。

/etc/fstabを書き換えた後、OS再起動させずに反映させるにはどうすれば?だ。

/etc/fstabを書き換えてOS再起動させると、/run/systemd/generatorに反映される。
これをOS再起動させずに反映させる方法だ。

で、調べてみたら、systemd.generatorのマニュアルエントリ(man systemd.generator)に書いてあった。
ちゃんと読めよ…。

/etc/fstabを書き換えたら
$ sudo systemctl daemon-reload
だ。
これで/run/systemd/generatorに反映される。
ついでに、ファイルシステムのマウントも、
$ sudo systemctl start /mnt/gfs2
という具合に、マウントポイントを指定すればマウントしてくれる。
(アンマウントは systemctl stop だ)

なんだ、すげー簡単じゃん…。

ちなみに今回のocfs2/gfs2に対応する/etc/fstabエントリは以下だ。
--ココから
/dev/mapper/vg--ocfs2-lv--ocfs /mnt/ocfs2 ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで
この2行を/etc/fstabに追記した後、
(gemini) $ sudo systemctl daemon-reload
を実行
(gemini) $ ls -l /run/systemd/generator
でエントリが出来ている(mnt-gfs2.mount と mnt-ocfs2.mount)のを確認して
(gemini) $ sudo systemctl start /mnt/ocfs2
(gemini) $ sudo systemctl start /mnt/gfs2
でマウント、
(gemini) $ grep -e /mnt/ocfs2 -e /mnt/gfs2 /etc/mtab
でマウントされているのを確認。

これでOKだ。
(OS再起動後は自動でマウントされるはずだぞ。)

ファイルシステム関連はこれにてオシマイ。
次こそCLVMの調査だ。

--2017/04/14追記
fstabのエントリはnoautoを付与しておくようにした。
自動マウントされると、ちょっと不便だった。(ボリュームアクティベートが失敗しているのにマウントしようとしたり…)
--2017/04/14追記終了

gfs2マウントについて(その2:手動マウント)

gfs2のファイルシステムを自動的にマウントする方法については、前回で確立できた。

gfs2の仕組み上、自動マウントで設定しておけば何も問題ない気がするけど、一応手動マウントについても確認してみた。

/etc/fstabにエントリが無い環境でgfs2をマウントした場合、シャットダウン前にアンマウントしておく必要がある、という点はこれまでと同じ。
今回は、/etc/fstabにnoautoでエントリを書いていた場合、だ。
具体的には、/etc/fstabのエントリが以下のようにnoautoを付けている状態。
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 noauto,_netdev,x-systemd.requires=dlm.service 0 0

結論から言えば、問題なしだ。
手動マウント→シャットダウン

手動マウント→手動アンマウント→シャットダウン
も問題ない。

更に言えば、マウントは
$ sudo mount /mnt/gfs2
でも
$ sudo systemctl start mnt-gfs2.mount
でもどちらでもいい。

アンマウントも全く同じで、
$ sudo umount /mnt/gfs2
でも
$ sudo systemctl stop mnt-gfs2.mount
でもどちらでもいい。

mount/umountコマンドを直接呼び出した場合でも、systemctlのステータスは変化してくれるので、systemctlコマンドを使用した場合と同じ結果になる。
何の心配もいらない。
前後に
$ systemctl status mnt-gfs2.mount
$ grep /mnt/gfs2 /etc/mtab
を叩いて確認してみるといい。

というわけで、gfs2ファイルシステムを使用するのなら、/etc/fstabにきちんと記載すること、という結論。

gfs2マウントについて(その1:自動マウント)

前回の記事で「gfs2がアンマウントされない」って記載した。
(実際には、ocfs2がアンマウントされない、と勘違いしていたが、実体はgfs2の方がアンマウントされない、だった。)

で、調べていくうちに、「手作業でmountした場合、シャットダウンする前に手作業でumountしないとダメだよ」というところまで分かった。

確かに、umountしておけばシャットダウン処理でハングすることもない。

だったら/etc/fstabに記載してあったらどうなんだ?ということで/etc/fstabに記載してみたが…起動時にマウントされない。
--/etc/fstabへの追記内容
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev 0 0
--追記ココまで

起動時に自動マウントされないが、/etc/fstabへの記載があるので手作業でマウントは出来る。
(gemini) $ sudo mount -a
もしくは
(gemini) $ sudo mount /mnt/gfs2
ただ、この状態でシャットダウンすると、やはりハングする。

どうしたものか…と調査を続けていったら、systemdにmnt-gfs2.mountというユニットが追加されていることが発覚。
どうやら、/etc/fstabから自動生成されている模様。
そして、これがマウント処理を行おうとして失敗している。

(gemini) $ systemctl status mnt-gfs2.mount
(gemini) $ journalctl -l --unit=mnt-gfs2.mount
(gemini) $ journalctl -o cat --unit=mnt-gfs2.mount
3つ目のコマンドで確認できるのは「mount: mount /dev/mapper/vg--gfs2-lv--gfs on /mnt/gfs2 failed: 通信端点が接続されていません」というメッセージだ。
これ、dlmの設定が出来ていない時にgfs2領域をmountしようとした時のメッセージじゃないか?
ってことは、dlmの起動処理が終わらないうちに、mountコマンドが走り出したってことじゃないだろうか?

このユニットの詳細を見てみたい。
(gemini) $ systemctl show mnt-gfs2.mount
(gemini) $ systemctl --no-pager show mnt-gfs2.mount | less
After宣言を見てみると、確かにdlm.serviceは前提として定義されていない。
でもこれ、設定を変えようにも変え方が分からない。

(gemini) $ systemctl show -p FragmentPath mnt-gfs2.mount
これを見る限り、/run/systemd/generator/mnt-gfs2.mountが設定ファイルなのだが…。
(gemini) $ cat /run/systemd/generator/mnt-gfs2.mount
確かに設定ファイルなのだが、このファイル自体、tmpfs上に作成されていて、OSブート時に自動的に生成されるもののようだ。

ということで、予めこのファイルをイジっておく、というわけにはいかない。

このファイル自体は、systemd-fstab-generatorというツールが作成しているようだ。
manを見てみるが…
(gemini) $ man systemd-fstab-generator
あまり詳しくは書かれていない。

が、systemd.mountも参照しろ、と書かれていた。
こちらも参照してみる。
(gemini) $ man systemd.mount
む?何かヒントっぽいことが書かれているぞ!?
x-systemd.requires=
というエントリだ。

う~ん。良くわからないがfstabを書き換えてみよう。
(gemini) $ sudo vi /etc/fstab
--ココから
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev 0 0

/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 _netdev,x-systemd.requires=dlm.service 0 0
--ココまで

再起動(gfs2領域はアンマウントしておくこと)
(gemini) $ sudo shutdown -r now

どうだろうか…
(gemini) $ grep gfs2 /etc/mtab
マウントされてる!

自動作成された設定は…?
(gemini) $ cat /run/systemd/generator/mnt-gfs2.mount
お!AfterとRequiresの定義が追加されて、それぞれdlm.serviceが指定されている!
どうやら期待通りの動きをしてくれたみたいだ。

さて、問題はシャットダウンだが…。
このまま再起動してみる。
(gemini) $ sudo shutdown -r now
普通に再起動出来た…。

これで起動時にマウントする設定が出来たよ…。

--2017/04/14追記
ちょっと不安定な部分があったので、/etc/fstabの中の/mnt/gfs2のマウントエントリ、noautoオプションを付けて、起動時に自動マウントされないようにしておく。
/dev/mapper/vg--gfs2-lv--gfs /mnt/gfs2 gfs2 noauto,_netdev,x-systemd.requires=dlm.service 0 0
こんな感じ
--2017/04/14追記終了