ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--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の設定がおかしいようだ………
ヘルプに書かれている設定方法じゃダメっぽい………
整理して書き直す…。
0 件のコメント:
コメントを投稿