今の調査状況

--2017/04/20追記ココから--
ここで出ている問題は、前回分に追記した内容で解消したっぽい。
なので、無駄な記事になってしまった。
--2017/04/20追記ココまで--

全然解決しねぇ。

今のところ…

1. corosyncの自動起動にほぼ間違いなく失敗する。
2. corosyncの自動起動失敗に伴い、dlmも停止する。
3. o2cbの起動もほぼ間違いなく失敗する。
   (ただし、systemd的には成功しているように見える。)
4. OSの起動後、手作業でcorosyncを起動することは可能。
5. 同、手作業でdlmを起動することは可能。
   (corosyncが起動していない状態でdlmを手作業で起動すれば、corosyncも連動して起動する。)
6. corosyncのsystemd起動ファイル(/lib/systemd/system/corosync.service)のRequiresとAfterにopenvswitch-switchを追加することで、corosync/dlmの自動起動成功率は高まる。
   (必ず成功するわけではなく、自動起動失敗することもある。)
7. 両ノードでdlmが起動している状態で、片方のノードを停止させると、しばらくしてから生きている方のノードも自動でリブートする。
8. OS起動後、o2cbを手作業で起動(停止してから起動)は成功する。
9. corosync/dlmが停止している(起動失敗している)状態で、手作業でgfs2ファイルシステムをマウントしようとすると、corosync/dlmが自動起動してマウント成功する。
10. o2cbが正常起動している状態でなら、ocfs2ファイルシステムのマウントが可能。
11. o2cbの起動が上手く行っていない状態でocfs2ファイルシステムをマウントしようとすると、マウント失敗する。
12. o2cbを正常停止させている状態からocfs2ファイルシステムをマウントしようとすると、o2cbが自動起動してマウント成功する。
13. いずれも、openvswitch-switchが導入されていない環境では起きない問題。

辺りのことが分かってきた。

考え方的に、corosync/dlmとgfs2はセット、o2cbとocfs2がセット、となる。
今は両方に問題が出ているが、別モノとして整理、調査しないと混乱してしまうな。