続いて、cancer の IP を固定化する。
これ、ついでに OpenvSwitch も設定してしまう予定だ。
過去に何度か実施しているので、その辺りを探してみればいいけど、一応コマンド入れておく。
(cancer) $ ip link show
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ovs-vsctl add-br extsw
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo vi /etc/default/networking
--ココから
1行編集
#EXCLUDE_INTERFACES=
↓
EXCLUDE_INTERFACES=extsw
--ココまで
(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 vi /etc/network/interfaces
--ココから
2行コメント化
auto ens3
iface ens3 inet dhcp
↓
#auto ens3
#iface ens3 inet dhcp
--ココまで
(cancer) $ sudo ovs-vsctl add-port extsw ens3
(cancer) $ sudo ovs-vsctl show
(cancer) $ sudo ifup ens3
(cancer) $ sudo ifup extsw
(cancer) $ ip address show
(cancer) $ sudo systemctl daemon-reload
(cancer) $ sudo systemctl reboot
(cancer) $ ip address show
これで IP アドレスは元通りになったけど、ssh ホスト鍵が異なるので、ssh クライアントから接続する時にエラーになると思う。
クライアント側の known_hosts をいじることになるので、各クライアント毎に対処しよう。
あ、忘れてた。
合わせて、ssh鍵認証出来るように設定しておこう。
gemini の ~/.ssh/authorized_keys と同じ内容のファイルを、cancer 側の同じパスに作っておくだけでいいぞ。
2017年6月6日火曜日
そろそろ cancer を復活させよう
gemini とペアで使っていた cancer が吹っ飛んで、暫く片方で運用してた。
その cancer を復活させたいと思う。
吹っ飛んだのは cancer の仮想ディスクだけで、仮想マシン定義は残っている。
なので、cancer 用の新規仮想ディスクを作成する。
ディスクサイズは 72GB にする。
今回、ディスクレイアウトは変更する。
出来上がったら、gemini と同じ環境に揃えていくのだが、パッケージの導入によって、ユーザ・グループが自動作成されていく。
そのため、パッケージの導入順序が違うと、ユーザ名とUIDの対応が gemini と異なる結果になってしまう。
なのでまずは、ユーザ・グループの順番が揃うようにパッケージを導入していく。
gemini / cancer の /etc/group を比較していくと、どうやら最初に kvm グループが作成されているようだ。
ということは、qemu-kvm パッケージを最初に導入すべきかな？
(cancer) $ sudo apt-get install qemu-kvm
次はどうやら scanner 関連っぽい。(導入した記憶は無いのだが、何かの拍子に自動インストールされたのか？)
gemini の方を見てみると、 libsane:amd64 と libsane-common がインストールされているようだ。
それを導入。
(cancer) $ sudo apt-get install libsane:amd64 libsane-common
次は colord か…。
(cancer) $ sudo apt-get install colord
続いて、libvirt 関連。
(cancer) $ sudo apt-get install libvirt-bin
あと、gemini には statd というユーザが存在している。
これはどうやら nfs-common によって作成された代物のようだ。
(cancer) $ sudo apt-get install nfs-common
これで、gemini と cancer の間の /etc/passwd、/etc/group が同じになった(はず)。
但しこれでは、パッケージの導入状態が全く違うので、gemini からパッケージ一覧を取り出して、 cancer に一括適用しよう。
まずは gemini でパッケージ一覧の取得
(gemini) $ dpkg --get-selections > pack.list
この pack.list を、scp 等を用いて cancer へコピーしよう。
(cancer は今現在、dhcp クライアントになっていると思うので、IP アドレスはコンソールから ip address show 等を実行して確認すること。)
(gemini) $ scp pack.list (ユーザ名)@(canerのIP):~/
(gemini) $ rm pack.list
そうしたら、cancer 側でそのパッケージリストを適用する。
(ちょっと面倒かも)
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install dselect
(cancer) $ sudo dselect update
(cancer) $ sudo dpkg --clear-selections
(cancer) $ sudo dpkg --set-selections < pack.list
(cancer) $ sudo apt-get dselect-upgrade
げ、multipath-tools の処理中にエラーになった…。
なんでやろ…
おや？カーネルモジュールの古いのを参照しに行ってるわ。
カーネルは入れ替わってるから、一度再起動が必要だな。
(cancer) $ sudo systemctl reboot
(cancer) $ sudo apt-get install multipath-tools
これでヨシ。
途中でコケちゃったので、一度確認してみる。
(gemini) $ dpkg -l | grep ^ii | wc -l
(cancer) $ dpkg -l | grep ^ii | wc -l
どちらも 742 と出た。インストール済みパッケージの数は合うようだ。
一応クリーニング。
(cancer) $ sudo apt autoremove
コピーしたパッケージ一覧ファイルは削除しておこう。
(cancer) $ rm pack.list
あとは細々と設定を施していくわけだが…。
次回以降で実施することにしよう。
その cancer を復活させたいと思う。
吹っ飛んだのは cancer の仮想ディスクだけで、仮想マシン定義は残っている。
なので、cancer 用の新規仮想ディスクを作成する。
ディスクサイズは 72GB にする。
今回、ディスクレイアウトは変更する。
- vda1 : 512M : vfat
- vda2 : 512M : ext2
- vda3 : vg-root : lv-root : 10GB : ext4
- vda3 : vg-root : lv-swap-1 : 4GB : swap
- vda3 : vg-root : (未使用) : 残り全て
出来上がったら、gemini と同じ環境に揃えていくのだが、パッケージの導入によって、ユーザ・グループが自動作成されていく。
そのため、パッケージの導入順序が違うと、ユーザ名とUIDの対応が gemini と異なる結果になってしまう。
なのでまずは、ユーザ・グループの順番が揃うようにパッケージを導入していく。
gemini / cancer の /etc/group を比較していくと、どうやら最初に kvm グループが作成されているようだ。
ということは、qemu-kvm パッケージを最初に導入すべきかな？
(cancer) $ sudo apt-get install qemu-kvm
次はどうやら scanner 関連っぽい。(導入した記憶は無いのだが、何かの拍子に自動インストールされたのか？)
gemini の方を見てみると、 libsane:amd64 と libsane-common がインストールされているようだ。
それを導入。
(cancer) $ sudo apt-get install libsane:amd64 libsane-common
次は colord か…。
(cancer) $ sudo apt-get install colord
続いて、libvirt 関連。
(cancer) $ sudo apt-get install libvirt-bin
あと、gemini には statd というユーザが存在している。
これはどうやら nfs-common によって作成された代物のようだ。
(cancer) $ sudo apt-get install nfs-common
これで、gemini と cancer の間の /etc/passwd、/etc/group が同じになった(はず)。
但しこれでは、パッケージの導入状態が全く違うので、gemini からパッケージ一覧を取り出して、 cancer に一括適用しよう。
まずは gemini でパッケージ一覧の取得
(gemini) $ dpkg --get-selections > pack.list
この pack.list を、scp 等を用いて cancer へコピーしよう。
(cancer は今現在、dhcp クライアントになっていると思うので、IP アドレスはコンソールから ip address show 等を実行して確認すること。)
(gemini) $ scp pack.list (ユーザ名)@(canerのIP):~/
(gemini) $ rm pack.list
そうしたら、cancer 側でそのパッケージリストを適用する。
(ちょっと面倒かも)
(cancer) $ sudo apt-get update
(cancer) $ sudo apt-get install dselect
(cancer) $ sudo dselect update
(cancer) $ sudo dpkg --clear-selections
(cancer) $ sudo dpkg --set-selections < pack.list
(cancer) $ sudo apt-get dselect-upgrade
げ、multipath-tools の処理中にエラーになった…。
なんでやろ…
おや？カーネルモジュールの古いのを参照しに行ってるわ。
カーネルは入れ替わってるから、一度再起動が必要だな。
(cancer) $ sudo systemctl reboot
(cancer) $ sudo apt-get install multipath-tools
これでヨシ。
途中でコケちゃったので、一度確認してみる。
(gemini) $ dpkg -l | grep ^ii | wc -l
(cancer) $ dpkg -l | grep ^ii | wc -l
どちらも 742 と出た。インストール済みパッケージの数は合うようだ。
一応クリーニング。
(cancer) $ sudo apt autoremove
コピーしたパッケージ一覧ファイルは削除しておこう。
(cancer) $ rm pack.list
あとは細々と設定を施していくわけだが…。
次回以降で実施することにしよう。
2017年6月5日月曜日
使わなくなった iSCSI ボリュームの整理(sagittarius)
さて、最後に sagittarius だ。
こちらは調べてみたら、5LUNも未使用のディスクがある。
削除対象を、各レイヤーごとに記載しておく。
LVM
gpt
multipath
scsi-disk
さて、順番に削除だ。
(sagittarius) $ sudo vgchange -a n vg-kvm
(sagittarius) $ sudo lvremove vg-kvm/lv-etc-libvirt
(sagittarius) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(sagittarius) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(sagittairus) $ sudo vgremove vg-kvm
(sagittarius) $ sudo pvremove /dev/mapper/mpatha-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathb-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathc-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathd-part1
(sagittairus) $ sudo pvremove /dev/mapper/mpathe-part1
(sagittarius) $ sudo pvs
(sagittarius) $ sudo vgs
(sagittarius) $ lsblk
(sagittarius) $ sudo parted /dev/mapper/mpatha rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathb rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathc rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathd rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathe rm 1
(sagittarius) $ lsblk
あり？パーティション情報が消えてくれない。
でも、実際に parted で見ると消えてる。まぁいいや。
(sagittarius) $ sudo multipath -ll
(sagittarius) $ sudo multipath -f /dev/mapper/mpatha
(sagittarius) $ sudo multipath -f /dev/mapper/mpathb
(sagittarius) $ sudo multipath -f /dev/mapper/mpathc
(sagittarius) $ sudo multipath -f /dev/mapper/mpathd
(sagittarius) $ sudo multipath -f /dev/mapper/mpathe
(sagittarius) $ sudo multipath -ll
(sagittarius) $ sudo multipath -w /dev/sdj
(sagittarius) $ sudo multipath -w /dev/sdm
(sagittarius) $ sudo multipath -w /dev/sdn
(sagittarius) $ sudo multipath -w /dev/sdk
(sagittarius) $ sudo multipath -w /dev/sdl
(sagittarius) $ sudo vi /etc/multipath/wwids
(コメントになっているデバイス行を削除)
(sagittarius) $ sudo vi /etc/multipath/bindings
(mpatha,mpathb,mpathc,mpathd,mpatheを削除)
(sagittarius) $ sudo multipath -ll
(sagittarius) $ lsblk
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdj/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdm/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdn/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdk/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdl/device/delete"
(sagittarius) $ lsblk
ココからは iSCSI 関連だ。
(sagittarius) $ iscsiadm --mode session
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--logout
(sagittarius) $ iscsiadm --mode session
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op update \
--name node.startup \
--value manual
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op delete
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
iSCSI ストレージ側で不要な LUN、ターゲットの削除を行う。
最後に、念のために設定の再読み込み。(多分不要)
(sagittarius) $ sudo systemctl daemon-reload
これでオシマイ。だいぶすっきりした。
OS 再起動させたいところだけど、仮想マシンがガリガリ動いているので再起動しないでこのまま放置する。
こちらは調べてみたら、5LUNも未使用のディスクがある。
削除対象を、各レイヤーごとに記載しておく。
LVM
- vg-kvm/lv-etc-libvirt
- vg-kvm/lv-var-lib-libvirt
- vg-kvm/lv-var-log-libvirt
gpt
- /dev/mapper/mpatha-part1
- /dev/mapper/mpathb-part1
- /dev/mapper/mpathc-part1
- /dev/mapper/mpathd-part1
- /dev/mapper/mpathe-part1
multipath
- /dev/mapper/mpatha
- /dev/mapper/mpathb
- /dev/mapper/mpathc
- /dev/mapper/mpathd
- /dev/mapper/mpathe
scsi-disk
- /dev/sdj
- /dev/sdm
- /dev/sdn
- /dev/sdk
- /dev/sdl
さて、順番に削除だ。
(sagittarius) $ sudo vgchange -a n vg-kvm
(sagittarius) $ sudo lvremove vg-kvm/lv-etc-libvirt
(sagittarius) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(sagittarius) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(sagittairus) $ sudo vgremove vg-kvm
(sagittarius) $ sudo pvremove /dev/mapper/mpatha-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathb-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathc-part1
(sagittarius) $ sudo pvremove /dev/mapper/mpathd-part1
(sagittairus) $ sudo pvremove /dev/mapper/mpathe-part1
(sagittarius) $ sudo pvs
(sagittarius) $ sudo vgs
(sagittarius) $ lsblk
(sagittarius) $ sudo parted /dev/mapper/mpatha rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathb rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathc rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathd rm 1
(sagittarius) $ sudo parted /dev/mapper/mpathe rm 1
(sagittarius) $ lsblk
あり？パーティション情報が消えてくれない。
でも、実際に parted で見ると消えてる。まぁいいや。
(sagittarius) $ sudo multipath -ll
(sagittarius) $ sudo multipath -f /dev/mapper/mpatha
(sagittarius) $ sudo multipath -f /dev/mapper/mpathb
(sagittarius) $ sudo multipath -f /dev/mapper/mpathc
(sagittarius) $ sudo multipath -f /dev/mapper/mpathd
(sagittarius) $ sudo multipath -f /dev/mapper/mpathe
(sagittarius) $ sudo multipath -ll
(sagittarius) $ sudo multipath -w /dev/sdj
(sagittarius) $ sudo multipath -w /dev/sdm
(sagittarius) $ sudo multipath -w /dev/sdn
(sagittarius) $ sudo multipath -w /dev/sdk
(sagittarius) $ sudo multipath -w /dev/sdl
(sagittarius) $ sudo vi /etc/multipath/wwids
(コメントになっているデバイス行を削除)
(sagittarius) $ sudo vi /etc/multipath/bindings
(mpatha,mpathb,mpathc,mpathd,mpatheを削除)
(sagittarius) $ sudo multipath -ll
(sagittarius) $ lsblk
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdj/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdm/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdn/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdk/device/delete"
(sagittarius) $ sudo bash -c "echo 1 > /sys/block/sdl/device/delete"
(sagittarius) $ lsblk
ココからは iSCSI 関連だ。
(sagittarius) $ iscsiadm --mode session
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--logout
(sagittarius) $ iscsiadm --mode session
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op update \
--name node.startup \
--value manual
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
(sagittarius) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op delete
(sagittarius) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
iSCSI ストレージ側で不要な LUN、ターゲットの削除を行う。
最後に、念のために設定の再読み込み。(多分不要)
(sagittarius) $ sudo systemctl daemon-reload
これでオシマイ。だいぶすっきりした。
OS 再起動させたいところだけど、仮想マシンがガリガリ動いているので再起動しないでこのまま放置する。
使わなくなった iSCSI ボリュームの整理(gemini)
前回の続き。
sagittarius で実施する前に、 gemini の方で実施することにする。
流れとしてはほぼ同じだけど、gemini はまだ /var/log/libvirt が iSCSI ボリューム上に存在している。
これをローカルに移す作業が必要だ。
とは言え、過去に何度も実施したことのある手順なので、サクッと実施する。
(gemini) $ cd /var/log
(gemini) $ sudo tar cvf /tmp/libvirt.tar libvirt
(gemini) $ sudo systemctl stop /var/log/libvirt
(gemini) $ mountpoint /var/log/libvirt
(gemini) $ sudo tar xvf /tmp/libvirt.tar
(gemini) $ sudo rmdir /var/log/libvirt/lost+found
(gemini) $ sudo rm /tmp/libvirt.tar
(gemini) $ sudo vi /etc/fstab
(/var/log/libvirt のマウントエントリを無効化する）
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
これで、ボリュームが1つ削除出来るようになったはずだ。
また、現在未使用な領域で、fstab 上にエントリが残っているものとして、ocfs2 の領域(/mnt/ocfs2)と、gfs2テスト領域(/mnt/gfs2)がある。
こちらも、もう使うことが無いので、/etc/fstab からエントリを消しておこう。
(gemini) $ sudo vi /etc/fstab
(/mnt/ocfs2 と /mnt/gfs2 のマウント情報を削除)
(gemini) $ sudo systemctl daemon-reload
そしたら、不要な領域を削除していこう。
(gemini) $ lsblk
(gemini) $ sudo lvs
確認すると、
LVM操作前に、/etc/lvm/lvm.conf で自動アクティベートになっていないか確認し、必要なら削除しておく。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近の以下の行を削除する
auto_activation_volume_list = [ "gemini-vg", "vg-kvm", "vg-gfs2" ]
--ココまで
不要な領域を一つずつ削除していく。
(gemini) $ sudo lvremove vg-ocfs2/lv-ocfs
(gemini) $ sudo vgremove vg-ocfs2
(gemini) $ sudo vgchange -a n vg-kvm
(gemini) $ sudo lvremove vg-kvm/lv-etc-libvirt
(gemini) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(gemini) $ sudo vgremove vg-kvm
(gemini) $ sudo lvchange -a n vg-gfs2/lv-gfs
(gemini) $ sudo lvremove vg-gfs2/lv-gfs
(gemini) $ sudo lvchange -a n vg-gfs2/backup
(gemini) $ sudo lvremove vg-gfs2/backup
(gemini) $ lsblk
(gemini) $ sudo pvremove /dev/mapper/ocfs2-001
(gemini) $ sudo pvremove /dev/sdb1
(gemini) $ lsblk
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb rm 1
(gemini) $ sudo parted /dev/sdb print
LVM 情報が整理出来たら、次は multipath 関連だ。
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -f /dev/mapper/ocfs2-001
(gemini) $ sudo multipath -ll
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo cat /etc/multipath/bindings
(gemini) $ sudo multipath -w /dev/sda
(gemini) $ sudo cat /etc/multipath/bindings
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo vi /etc/multipath/wwids
(コメント化された行を削除する。)
(gemini) $ sudo vi /etc/multipath/bindings
(ocfs2-001 の行を削除する。)
multipath の整理が終わったら、デバイスの削除。
(gemini) $ lsblk
(gemini) $ sudo bash -c "echo 1 > /sys/block/sda/device/delete"
(gemini) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(gemini) $ lsblk
iSCSI ターゲットは2つ繋いでいるが、そのうちの1つは削除可能。
もう1つは、LUNを1つ削除するだけでターゲットは消さない形になる。
この辺りは、各自がどのように iSCSI ボリュームを作っていたかに依存するので、チェックするように。
まずは、自動ログインの解除からだ。
(gemini) $ iscsiadm --mode session
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
両ターゲット名と、それぞれへの自動ログインが automatic になっていることを確認しておく。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--logout
(gemini) $ iscsiadm --mode session
ログアウトしたことを確認する。
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
この時点では自動ログインはまだ automatic のままだ。
自動ログインを解除する。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op update \
--name node.startup \
--value manual
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
使用しない方のターゲットが manual に変化したことを確認する。
続いて、使用しない方のターゲットのエントリを削除する。
前回は削除する方法が分からず discovery を実行したが、削除する方法が分かったのでその方法を実施。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op delete
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
エントリが一つ消えて、残っている方のログインは automatic のままだ。
ココまで出来たら、iSCSI ストレージ側で不要な LUN、ターゲットを削除しよう。
最後に、念のために設定の再読み込み。(多分不要)
(gemini) $ sudo systemctl daemon-reload
これで gemini は完了。
必要に応じて、再起動して確認しよう。
sagittarius で実施する前に、 gemini の方で実施することにする。
流れとしてはほぼ同じだけど、gemini はまだ /var/log/libvirt が iSCSI ボリューム上に存在している。
これをローカルに移す作業が必要だ。
とは言え、過去に何度も実施したことのある手順なので、サクッと実施する。
(gemini) $ cd /var/log
(gemini) $ sudo tar cvf /tmp/libvirt.tar libvirt
(gemini) $ sudo systemctl stop /var/log/libvirt
(gemini) $ mountpoint /var/log/libvirt
(gemini) $ sudo tar xvf /tmp/libvirt.tar
(gemini) $ sudo rmdir /var/log/libvirt/lost+found
(gemini) $ sudo rm /tmp/libvirt.tar
(gemini) $ sudo vi /etc/fstab
(/var/log/libvirt のマウントエントリを無効化する）
(gemini) $ sudo systemctl daemon-reload
(gemini) $ cd
これで、ボリュームが1つ削除出来るようになったはずだ。
また、現在未使用な領域で、fstab 上にエントリが残っているものとして、ocfs2 の領域(/mnt/ocfs2)と、gfs2テスト領域(/mnt/gfs2)がある。
こちらも、もう使うことが無いので、/etc/fstab からエントリを消しておこう。
(gemini) $ sudo vi /etc/fstab
(/mnt/ocfs2 と /mnt/gfs2 のマウント情報を削除)
(gemini) $ sudo systemctl daemon-reload
そしたら、不要な領域を削除していこう。
(gemini) $ lsblk
(gemini) $ sudo lvs
確認すると、
- /dev/sda → /dev/mapper/ocfs2-001 → /dev/vg-ocfs2/lv-ocfs2
- /dev/sdb → /dev/sdb1 → /dev/vg-kvm(3LV全て)
- /dev/sdc → /dev/mapper/gfs2-001 → /dev/vg-gfs2/lv-gfs
- /dev/sdc → /dev/mapper/gfs2-001 → /dev/vg-gfs2/backup(ココで作成したバックアップ用領域)
LVM操作前に、/etc/lvm/lvm.conf で自動アクティベートになっていないか確認し、必要なら削除しておく。
(gemini) $ sudo vi /etc/lvm/lvm.conf
--ココから
1156行目付近の以下の行を削除する
auto_activation_volume_list = [ "gemini-vg", "vg-kvm", "vg-gfs2" ]
--ココまで
不要な領域を一つずつ削除していく。
(gemini) $ sudo lvremove vg-ocfs2/lv-ocfs
(gemini) $ sudo vgremove vg-ocfs2
(gemini) $ sudo vgchange -a n vg-kvm
(gemini) $ sudo lvremove vg-kvm/lv-etc-libvirt
(gemini) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(gemini) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(gemini) $ sudo vgremove vg-kvm
(gemini) $ sudo lvchange -a n vg-gfs2/lv-gfs
(gemini) $ sudo lvremove vg-gfs2/lv-gfs
(gemini) $ sudo lvchange -a n vg-gfs2/backup
(gemini) $ sudo lvremove vg-gfs2/backup
(gemini) $ lsblk
(gemini) $ sudo pvremove /dev/mapper/ocfs2-001
(gemini) $ sudo pvremove /dev/sdb1
(gemini) $ lsblk
(gemini) $ sudo parted /dev/sdb print
(gemini) $ sudo parted /dev/sdb rm 1
(gemini) $ sudo parted /dev/sdb print
LVM 情報が整理出来たら、次は multipath 関連だ。
(gemini) $ sudo multipath -ll
(gemini) $ sudo multipath -f /dev/mapper/ocfs2-001
(gemini) $ sudo multipath -ll
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo cat /etc/multipath/bindings
(gemini) $ sudo multipath -w /dev/sda
(gemini) $ sudo cat /etc/multipath/bindings
(gemini) $ sudo cat /etc/multipath/wwids
(gemini) $ sudo vi /etc/multipath/wwids
(コメント化された行を削除する。)
(gemini) $ sudo vi /etc/multipath/bindings
(ocfs2-001 の行を削除する。)
multipath の整理が終わったら、デバイスの削除。
(gemini) $ lsblk
(gemini) $ sudo bash -c "echo 1 > /sys/block/sda/device/delete"
(gemini) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(gemini) $ lsblk
iSCSI ターゲットは2つ繋いでいるが、そのうちの1つは削除可能。
もう1つは、LUNを1つ削除するだけでターゲットは消さない形になる。
この辺りは、各自がどのように iSCSI ボリュームを作っていたかに依存するので、チェックするように。
まずは、自動ログインの解除からだ。
(gemini) $ iscsiadm --mode session
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
両ターゲット名と、それぞれへの自動ログインが automatic になっていることを確認しておく。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--logout
(gemini) $ iscsiadm --mode session
ログアウトしたことを確認する。
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
この時点では自動ログインはまだ automatic のままだ。
自動ログインを解除する。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op update \
--name node.startup \
--value manual
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
使用しない方のターゲットが manual に変化したことを確認する。
続いて、使用しない方のターゲットのエントリを削除する。
前回は削除する方法が分からず discovery を実行したが、削除する方法が分かったのでその方法を実施。
(gemini) $ sudo iscsiadm --mode node \
--targetname (使用しない方のターゲット名) \
--op delete
(gemini) $ sudo iscsiadm --mode node \
--op show \
| grep -e node.name -e node.startup
エントリが一つ消えて、残っている方のログインは automatic のままだ。
ココまで出来たら、iSCSI ストレージ側で不要な LUN、ターゲットを削除しよう。
最後に、念のために設定の再読み込み。(多分不要)
(gemini) $ sudo systemctl daemon-reload
これで gemini は完了。
必要に応じて、再起動して確認しよう。
2017年6月4日日曜日
使わなくなった iSCSI ボリュームの整理(aquarius)
そういえば、過去に作って現在使用していない iSCSI ボリュームが、aquarius / sagittarius ともに残っていた。
もう使わないので整理してしまおう。
まずは aqaurius から。
(aquarius) $ lsblk
これを見てみると、 /dev/sdb → /dev/mapper/mpatha → /dev/vg-kvm が未使用になっている。
＃何度か再起動しているウチに、自動的に multipath 制御下になったようだ。
まずは、/etc/lvm/lvm.conf に当該ボリューム(vg)が定義されていないか確認。
(aquarius) $ grep vg-kvm /etc/lvm/lvm.conf
もし定義されていたら、削除しておこう。
続いて、lvm 構成情報の削除。
(aquarius) $ sudo vgchange -a n vg-kvm
(aquarius) $ sudo lvremove vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(aquarius) $ sudo vgremove vg-kvm
(aquarius) $ lsblk
続いて、multipath から削除
(aquarius) $ sudo multipath -ll
(aquarius) $ sudo multipath -f /dev/mapper/mpatha
(aquarius) $ sudo multipath -ll
(aquarius) $ sudo cat /etc/multipath/wwids
(aquarius) $ sudo cat /etc/multipath/bindings
(aquarius) $ sudo multipath -w /dev/sdb
(aquarius) $ sudo cat /etc/multipath/bindings
(aquarius) $ sudo cat /etc/multipath/wwids
wwids ファイルはコメント化、bindings ファイルにはエントリが残っている状態なので、この際削除してしまおう。
(aquarius) $ sudo vi /etc/multipath/bindings
(mpatha の行を削除)
(aquarius) $ sudo vi /etc/multipath/wwids
(コメント化された行を削除)
続いて、OS から当該デバイスの削除だ。
(aqaurius) $ lsblk
(aquarius) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(aquarius) $ lsblk
この領域は iSCSI で、当該ターゲットはこの1つしか LUN が無い。
そのため、この iSCSI ターゲットにはログインする必要も無く、ログイン用の設定も不要だ。
その辺りの整理を行う。
(aquarius) $ iscsiadm --mode session
(iSCSI ターゲットの名前を確認)
(aquarius) $ sudo iscsiadm --mode node \
--targetname (先程確認したターゲット名) \
--logout
(aquarius) $ iscsiadm --mode session
(ログアウトしたことを確認する)
(aquarius) $ sudo iscsiadm --mode node \
--targetname (先程確認したターゲット名) \
--op update \
--name node.startup \
--value manual
(aquarius) $ sudo iscsiadm --mode node \
--op show \
--targetname (先程確認したターゲット名)
(node.startup が manual になったことを確認)
これで、iSCSI ターゲットへの自動ログインは無くなったはずだ。
ここまで来たら、次はストレージ側で当該 LUN と iSCSI ターゲットを削除しよう。
ストレージ側で削除が完了しても、 aquarius 側は当該 iSCSI ターゲットの情報は残っている。
どうやって削除するのか良くわからないので、iSCSI ターゲットを再スキャンしてしまおう。
(aquarius) $ sudo iscsiadm --mode discovery \
--type sendtargets \
--portal (NASのIPアドレス)
(aquarius) $ sudo ls -F /etc/iscsi/nodes/
使わなくなった iSCSI ターゲットのエントリが消えたはずだ。
が、何故かここまでの手順を踏むと、もう1つの iSCSI ターゲット(kvmcluster)への自動ログインも解除されてしまう。
合わせて自動ログイン設定しておこう。
(aquarius) $ sudo iscsiadm --mode node \
--targetname (有効にしたい方のターゲット名) \
--op update \
--name node.startup \
--value automatic
念のために、設定情報をリロードしておく。(多分不要)
(aquarius) $ sudo systemctl daemon-reload
これで完了だ。必要なら再起動もしておこう。
次回、同じように sagittarius に実施する。
もう使わないので整理してしまおう。
まずは aqaurius から。
(aquarius) $ lsblk
これを見てみると、 /dev/sdb → /dev/mapper/mpatha → /dev/vg-kvm が未使用になっている。
＃何度か再起動しているウチに、自動的に multipath 制御下になったようだ。
まずは、/etc/lvm/lvm.conf に当該ボリューム(vg)が定義されていないか確認。
(aquarius) $ grep vg-kvm /etc/lvm/lvm.conf
もし定義されていたら、削除しておこう。
続いて、lvm 構成情報の削除。
(aquarius) $ sudo vgchange -a n vg-kvm
(aquarius) $ sudo lvremove vg-kvm/lv-etc-libvirt
(aquarius) $ sudo lvremove vg-kvm/lv-var-lib-libvirt
(aquarius) $ sudo lvremove vg-kvm/lv-var-log-libvirt
(aquarius) $ sudo vgremove vg-kvm
(aquarius) $ lsblk
続いて、multipath から削除
(aquarius) $ sudo multipath -ll
(aquarius) $ sudo multipath -f /dev/mapper/mpatha
(aquarius) $ sudo multipath -ll
(aquarius) $ sudo cat /etc/multipath/wwids
(aquarius) $ sudo cat /etc/multipath/bindings
(aquarius) $ sudo multipath -w /dev/sdb
(aquarius) $ sudo cat /etc/multipath/bindings
(aquarius) $ sudo cat /etc/multipath/wwids
wwids ファイルはコメント化、bindings ファイルにはエントリが残っている状態なので、この際削除してしまおう。
(aquarius) $ sudo vi /etc/multipath/bindings
(mpatha の行を削除)
(aquarius) $ sudo vi /etc/multipath/wwids
(コメント化された行を削除)
続いて、OS から当該デバイスの削除だ。
(aqaurius) $ lsblk
(aquarius) $ sudo bash -c "echo 1 > /sys/block/sdb/device/delete"
(aquarius) $ lsblk
この領域は iSCSI で、当該ターゲットはこの1つしか LUN が無い。
そのため、この iSCSI ターゲットにはログインする必要も無く、ログイン用の設定も不要だ。
その辺りの整理を行う。
(aquarius) $ iscsiadm --mode session
(iSCSI ターゲットの名前を確認)
(aquarius) $ sudo iscsiadm --mode node \
--targetname (先程確認したターゲット名) \
--logout
(aquarius) $ iscsiadm --mode session
(ログアウトしたことを確認する)
(aquarius) $ sudo iscsiadm --mode node \
--targetname (先程確認したターゲット名) \
--op update \
--name node.startup \
--value manual
(aquarius) $ sudo iscsiadm --mode node \
--op show \
--targetname (先程確認したターゲット名)
(node.startup が manual になったことを確認)
これで、iSCSI ターゲットへの自動ログインは無くなったはずだ。
ここまで来たら、次はストレージ側で当該 LUN と iSCSI ターゲットを削除しよう。
ストレージ側で削除が完了しても、 aquarius 側は当該 iSCSI ターゲットの情報は残っている。
どうやって削除するのか良くわからないので、iSCSI ターゲットを再スキャンしてしまおう。
(aquarius) $ sudo iscsiadm --mode discovery \
--type sendtargets \
--portal (NASのIPアドレス)
(aquarius) $ sudo ls -F /etc/iscsi/nodes/
使わなくなった iSCSI ターゲットのエントリが消えたはずだ。
が、何故かここまでの手順を踏むと、もう1つの iSCSI ターゲット(kvmcluster)への自動ログインも解除されてしまう。
合わせて自動ログイン設定しておこう。
(aquarius) $ sudo iscsiadm --mode node \
--targetname (有効にしたい方のターゲット名) \
--op update \
--name node.startup \
--value automatic
念のために、設定情報をリロードしておく。(多分不要)
(aquarius) $ sudo systemctl daemon-reload
これで完了だ。必要なら再起動もしておこう。
次回、同じように sagittarius に実施する。
カーネルの自動アップデートの停止
Ubuntu16.04 導入時、「自動アップデートの適用可否」という選択肢が出てきたので、「アップデートしない」にしておいた。
が、カーネルを含むセキュリティアップデートは自動で適用されてしまっているようだ。
他のパッケージならともかく、カーネルの自動アップデートが走ると、(カーネルは入れ替えじゃないため)どんどんディスクを消費していってしまう。
過去、とあるサーバで、気付いたら / がパンクしていてにっちもさっちも行かない状態になったことがある。
常に運用監視するサーバなら、自動アップデートは適用しつつ、適宜再起動を行ってカーネルを最新にしておくべきだが、ウチのマシンはそこまでガチガチに運用するツモリは無い。
また、一応外部(The Internet側)からは、ssh鍵が無いと入れないようにしているため、sshdのセキュリティにだけ気を付けていれば、とりあえず大丈夫なはずだ。
(いや、sshd の手前のネットワークドライバに問題があれば、ssh セキュリティ関係無く突破されてしまうか…)
というわけで、カーネルの自動アップデートだけは禁止にしておきたい。
その代わり、出来るだけ高頻度に、手作業で apt-get upgrade や apt-get install linux-headers-generic linux-signed-generic linux-signed-image-generic を実施するように。
で、どうも調べてみたら、
セキュリティアップデートを停止させるのは /etc/apt/apt.conf.d/50unattended-upgrades というファイルをいじるようだ。
セキュリティフィックスを適用するのを停止したかったら、このファイルの Unattended-Upgraede::Allowed-Origins {} の定義の "${distroid}:${distro_codename}-security"; を無効化すればいいっぽいけど、これを実施すると、全てのセキュリティフィックスが自動適用されなくなる。
ちょっと目的が違う。
今回は、カーネルの自動アップデートだけ避けたい。
この場合は、Unattended-Upgrade::Package-Blacklist {} に当該パッケージを指定すればいいっぽい。
というわけで、gemini / sagittarius / aquarius に実施してみる。
(cancer はまだ死んだまま、復活させていないので。)
$ sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
--ココから
16行目付近
Unattended-Upgrade::Package-Blacklist {
// "vim";
↓3行追記
Unattended-Upgrade::Package-Blacklist {
"linux-headers-generic";
"linux-signed-generic";
"linux-signed-image-generic";
// "vim";
--ココまで
これで期待した動きをするのか…？
暫く様子見することにする。
今回はココまで
が、カーネルを含むセキュリティアップデートは自動で適用されてしまっているようだ。
他のパッケージならともかく、カーネルの自動アップデートが走ると、(カーネルは入れ替えじゃないため)どんどんディスクを消費していってしまう。
過去、とあるサーバで、気付いたら / がパンクしていてにっちもさっちも行かない状態になったことがある。
常に運用監視するサーバなら、自動アップデートは適用しつつ、適宜再起動を行ってカーネルを最新にしておくべきだが、ウチのマシンはそこまでガチガチに運用するツモリは無い。
また、一応外部(The Internet側)からは、ssh鍵が無いと入れないようにしているため、sshdのセキュリティにだけ気を付けていれば、とりあえず大丈夫なはずだ。
(いや、sshd の手前のネットワークドライバに問題があれば、ssh セキュリティ関係無く突破されてしまうか…)
というわけで、カーネルの自動アップデートだけは禁止にしておきたい。
その代わり、出来るだけ高頻度に、手作業で apt-get upgrade や apt-get install linux-headers-generic linux-signed-generic linux-signed-image-generic を実施するように。
で、どうも調べてみたら、
セキュリティアップデートを停止させるのは /etc/apt/apt.conf.d/50unattended-upgrades というファイルをいじるようだ。
セキュリティフィックスを適用するのを停止したかったら、このファイルの Unattended-Upgraede::Allowed-Origins {} の定義の "${distroid}:${distro_codename}-security"; を無効化すればいいっぽいけど、これを実施すると、全てのセキュリティフィックスが自動適用されなくなる。
ちょっと目的が違う。
今回は、カーネルの自動アップデートだけ避けたい。
この場合は、Unattended-Upgrade::Package-Blacklist {} に当該パッケージを指定すればいいっぽい。
というわけで、gemini / sagittarius / aquarius に実施してみる。
(cancer はまだ死んだまま、復活させていないので。)
$ sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
--ココから
16行目付近
Unattended-Upgrade::Package-Blacklist {
// "vim";
↓3行追記
Unattended-Upgrade::Package-Blacklist {
"linux-headers-generic";
"linux-signed-generic";
"linux-signed-image-generic";
// "vim";
--ココまで
これで期待した動きをするのか…？
暫く様子見することにする。
今回はココまで
2017年6月1日木曜日
ホスト停止時にゲストを停止(本適用)
とりあえず、物理ホストである sagittarius / aquarius に、ホスト停止時にゲストを自動停止させる処理を組み込もう。
まずは、ゲストを稼働させていない aquarius から。
(aquarius) $ sudo vi /etc/default/libvirt-guests
--ココから
25行目付近
#ON_SHUTDOWN=shutdown
↓
ON_SHUTDOWN=shutdown
--ココまで
反映
(aquarius) $ sudo systemctl daemon-reload
ゲストが動いていないので、普通の再起動を確認してみる。
(aquarius) $ sudo systemctl reboot
問題無さそうだ。
qemu-guest-agent が動いている仮想マシン、Windows と Linux を用意して、aquarius 上で起動してみる。
仮想マシン名は pisces と wolf とする。
(wolf は過去のブログで作っていないが、コソっと作っている。Win7機だ。)
そしたら、再起動をかけてみよう。(無事に再起動してくれればいいが…)
(aquarius) $ sudo systemctl reboot
リブートは問題なかった。ゲストOSを稼働させて、起動時のメッセージも確認しておくこと。
問題無ければ、ゲストOSが稼働している sagittarius でも実施してみる。
(sagittarius) $ sudo vi /etc/default/libvirt-guests
--ココから
25行目付近
#ON_SHUTDOWN=shutdown
↓
ON_SHUTDOWN=shutdown
--ココまで
反映
(sagittarius) $ sudo systemctl daemon-reload
sagittarius はゲストが稼働していて、そのゲストは今は落とせないので、設定反映させるだけに留めておく。
次回は…何にしよう…？まぁ適当に。
まずは、ゲストを稼働させていない aquarius から。
(aquarius) $ sudo vi /etc/default/libvirt-guests
--ココから
25行目付近
#ON_SHUTDOWN=shutdown
↓
ON_SHUTDOWN=shutdown
--ココまで
反映
(aquarius) $ sudo systemctl daemon-reload
ゲストが動いていないので、普通の再起動を確認してみる。
(aquarius) $ sudo systemctl reboot
問題無さそうだ。
qemu-guest-agent が動いている仮想マシン、Windows と Linux を用意して、aquarius 上で起動してみる。
仮想マシン名は pisces と wolf とする。
(wolf は過去のブログで作っていないが、コソっと作っている。Win7機だ。)
そしたら、再起動をかけてみよう。(無事に再起動してくれればいいが…)
(aquarius) $ sudo systemctl reboot
リブートは問題なかった。ゲストOSを稼働させて、起動時のメッセージも確認しておくこと。
問題無ければ、ゲストOSが稼働している sagittarius でも実施してみる。
(sagittarius) $ sudo vi /etc/default/libvirt-guests
--ココから
25行目付近
#ON_SHUTDOWN=shutdown
↓
ON_SHUTDOWN=shutdown
--ココまで
反映
(sagittarius) $ sudo systemctl daemon-reload
sagittarius はゲストが稼働していて、そのゲストは今は落とせないので、設定反映させるだけに留めておく。
次回は…何にしよう…？まぁ適当に。
登録:
投稿 (Atom)