vSphere代替と話題になっているHPE VM EssentailsことUbuntu 22.04LTS KVM hypervisor with HP製管理GUIを試して見てる

vSphereがアレなことになってしまってから、いろいろ面倒なことになっています。

そんな中、HPEからHPE VM Essentialsなる仮想基盤を出すという話が・・・

2025/01/14にHPE VM Essentials trial というページが公開されているというのに気がついて、ダウンロードしてみました。

ただ、2025/02/04時点でもドキュメントの理解ができてないので、いまいち設定がよくわかりません・・・

まだ世間に設定してみた情報が少ないので、問題になった点とかのメモもかねて公開していきます。

2025/02/05 17:00時点の感想

v8.0.2.1を使用しての感想

・ドキュメントが足らなすぎる
・処理中なのかどうかもう少し表現してほしい
・仮想DVDドライブのメディア入れ替えが動作しないのと初期設定時以外に設定追加できないのなんとかしてほしい
iSCSIストレージの追加ってどこからやるの?
ローカルストレージの追加ってどこからやるの?
・ドキュメント上 /var/morpheus ディレクトリで容量使うってどこにも書いてない気がするんですが!!!
・作成した仮想マシンBIOS設定だったんだけど、UEFIへの切り替えはどこでやるの?
Secure Boot / vTPM への対応はするの?

配布パッケージについて

HPE VM Essentials trial というページにて公開されています。

登録後は My HPE Software Center から左側の「Software」を開き、Searchキーワードに「HPE VME」と入力して検索すると、Search Resultsにその時点での最新版が表示されます。

2024/01/14時点では、 HPE_VM_Essentials_SW_image_v8.0.1.1_S5Q83-11001.iso の中に、Ubuntu 22.04上へインストールするためのパッケージファイル(hpe-vm_1.0.2-1_amd64.deb)と、HPE Manager用の仮想ディスクイメージファイル(hpe-vme-8.0.1-1.qcow2.gz)が入っていました。

その後、2025/01/29付けで HPE_VM_Essentials_SW_image_8.0.2_1_S5Q83-11003.iso に差し替わり、こちらはパッケージファイルはそのまま(hpe-vm_1.0.2-1_amd64.deb)と、HPE Manager用の仮想ディスクイメージファイルが更新されて hpe-vme-8.0.2-1.qcow2.gz になっていました。

現状ではアップデートされたかどうかのお知らせが出ていないようなので、自分で確認する必要があるようです。

HPE VM Essentialsの構成について

HPE VM Essentialsのドキュメントページに下記の絵があります。

2025年1月末時点では、Ubuntu 22.04ベースのサーバ上に、HPE VM Consoleパッケージ(hpe-vm_1.0.2-1_amd64.deb)を追加する。

追加したサーバのうち1台の上に、中央管理サーバとなるHPE VME Manager仮想マシンを構築して起動する、というものになる。

ベースとなるUbuntu 22.04について

Ubuntu 22.04インストール時に最小インストールで実施してみたところ、hpe-vm_1.0.2-1_amd64.deb パッケージインストール時に足らないパッケージを全部持ってきてるようだったので、それで大丈夫だろう、と思って設定していたのですが、HPE VME Manager仮想マシンの構築で失敗するという問題が発生しました。

原因が半月以上わからないままだったのですが、ふと思いついてUbuntuの再インストール時に最小インストール “Ubuntu Server (minimized)” をやめたらすんなりと成功するいう・・・

Ubuntuインストール時のパーテーション構成について

ドキュメント上、特に記載がないが、動作をみたところ、/var/morpheus/kvm/ 以下にデフォルトのデータストア(仮想マシン格納場所)が作成されていた

このため、 /var/morpheus は別のパーテーションとして容量を確保した方がよいかと思われる。

ネットワーク設定について

とりあえず、普通に固定IPアドレスを割り当てたネットワークインタフェースが1つあれば、仮想マシンを動かす設定まで作れる。

ポイント的なものでいうと
・Ubuntu 22.04インストール時に使用するネットワークインタフェースに固定IPを割り当てる
・上記で使ったネットワークインタフェース名(たとえばeno5)は HPE VM Managerインストール時に何回か入力することになる
・Compute VLANを別に用意しなくても問題なく、管理用と同じで動作させることはできる

仮想環境で使用するネットワークについては、open vswitchを利用したものが作成される。

インストール直後は「default」だけだが、HPE VM Managerの初期セットアップとサーバの登録が終わると「Management」と「Compute」という設定ができている。(virsh net-listで確認できる)

hpe-vmパッケージインストール

Ubuntu 22.04 Serverをインストールした後、ISOイメージの中にある hpe-vmのdebパッケージをインストールすることで、HPE VM Essentailsで使用するhypervisor用サーバとなる。

「sudo apt install -f hpe-vm_1.0.2-1_amd64.deb」というふうに実行すると、必要なUbuntuパッケージとともにインストールされる。

ただ、パッケージインストール後、一度OS再起動した方が良さそうな気がします。

インストール直後の virsh net-list –all実行結果

vmadmin@hpevm:~$ virsh net-list --all
 Name   State   Autostart   Persistent
----------------------------------------

vmadmin@hpevm:~$

再起動後の実行結果

vmadmin@hpevm:~$ virsh net-list --all
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

vmadmin@hpevm:~$

HPE VME Manager仮想マシンのセットアップについて

hpe-vm パッケージをインストールすると、「hpe-vm」コマンドが実行できるようになります。

「sudo hpe-vm」で起動すると以下のような画面となります。

最初は「Keyboard Layout / TimeZone」でキーボードとタイムゾーンを設定します。

コマンドで「sudo timedatectl set-timezone Asia/Tokyo」でもよい。

VC Keymapを「sudo localectl set-keymap jp106」で設定しようかと思ったのですが、そちらはパッケージが足らないらしくエラーになりました(UIから選択すると自動的にインストールされる)

管理はHPE VME Manager仮想マシン経由で行うため、環境内に1台だけインストールを行う。

HPE VME Manager仮想マシンのインストールはhpe-vmの「Install Morpheus」から実施する。

以下のような形でセットアップパラメータを指定する

IP Address: HPE VME Manager仮想マシンのIPアドレス
Netmask, Gateway, DNS Serverは普通に設定

Appliance URLは、セットアップ完了後、HPE VME Manager仮想マシンの管理Webにアクセスする際のURLを指定する。https://ホスト名.ドメイン名 というようなDNSサーバで解決できる名前を指定することを推奨している模様。IPアドレス指定でも大丈夫だった。

Hostname はHPE VME Manager仮想マシンのホスト名

Admin User / Admin Password はHPE VME Manager仮想マシンにsshでログインする場合のユーザ情報

Select VM Sizeは「Small」「Medium」「Large」の3種類から選ぶが、現状のドキュメントでは仮想マシンスペックの違いしかかかれておらず、管理対象台数などがどう変わるかについては不明。

Host Configration Optionsの Management Interface には、ホストサーバで、管理用のIPアドレスがついているインタフェースを選んだ

インストールを開始すると、93%で一度長時間止まる。

これは初回起動にとても時間がかかるためで10分ちょい放置すると、サービスが起動したというウィンドウが表示される。

起動が終わる前に管理URLにアクセスすると以下のような表示が出る。(最初は ポート80しかあいてないが、そのうちポート443もアクセスできるようになる)

完了すると「Morpheus VM Installed」という表示が出る。(下記キャプチャはAppliance URLを IPアドレスで設定した場合のキャプチャ)

サービスの起動が完了したあとにAppliance URLで指定したURLにブラウザからアクセスすると、下記のようなログイン画面が表示される。

階層構造について

ドキュメントで解説している箇所がよくわからないが、以下のツリー構成になっているようだ。

テナント名
 └グループ名
  └クラウド名
   └クラスター名
    ├ホスト
    ├VM(仮想マシン)
    ├ネットワーク
    ├ストレージ
    └仮想イメージ

あと、上記とは直接関係なく「ラベル名」という区別のための識別符をつけることもできる。

テナント名: 初回ログイン時にマスターテナント名として指定

v8.0.2.1時点ではテナントの管理URLっぽいのにアクセスするとエラーになるので、これからなんか実装していくっぽい

グループ名:拠点などでわけることを想定していると思われるもの

クラウド名:「HPE VM Essentials環境」と「vSphere環境」の2種類を登録できる。

クラスター名:vSphereのクラスターとほぼ同じ意味合いでのクラスター。この下に実際の物理Ubuntuサーバ with HPE VMを登録する

初回ログイン時の設定項目について

初回ログイン時に設定が求められる項目として以下がある

マスターテナント名: 適当になんか名前を設定

マスターユーザーの作成で、主管理ユーザを作成。メールアドレスも必須

初期セットアップは、Install Morpheus で入力したものを指定

最後にライセンス登録。評価版の時はなにも入力しない

以上で初期セットアップ終了

HPE VM Managerセットアップ後のvirsh net-list –allを確認すると、設定が変わっている。

vmadmin@hpevm:~$ virsh net-list --all
 Name         State    Autostart   Persistent
-----------------------------------------------
 default      active   yes         yes
 Management   active   yes         yes

vmadmin@hpevm:~$

サーバ登録

初期設定が終わったらサーバ登録を行う。

「インフラストラクチャ」から「グループ」作成→「クラウド作成」

クラウド作成は多少時間がかかるので、ステータスが「INITIALIZING」から「OK」に変わるのを確認すること(自動更新をしないようなので再読み込みで確認)

で、作成されたこのクラウドのリンクをクリックして、「クラスター」を開く

クラスターの追加ウィザードの中で重要なポイントは以下の構成オプションのところ

hpe-vmパッケージをインストールしたUbuntuサーバをSSHホストとして指定

Management Net Interface、Compute Net Interface、Overlay net Interfaceに使用するネットワークインタフェース名を入れる。全部同じインタフェースを使用しても動作した。

(Overlay net Interfaceを空欄で進めたら指定していないはずの eno0デバイスがないというエラーが出たので、指定しないとダメっぽい)

タグVLANを使う場合はCompute Net Interfaceに使うインタフェース名と、COMPUTE VLANSにタグVLANの値を列挙する。

レイアウトは「HPE VM 1.1 Cluster on Existing Ubuntu 22.04」と「HPE VM 1.1 HCI Ceph Cluster on Existing Ubuntu 22.04」の選択肢になっているのだが、HCI構成の場合の要求要件がわからないのでまだ手を付けていない

あと「CPU Model」のところで、そのクラスタで使用する仮想マシンに許可するCPU世代を指定できる。(VMware EVCみたいな感じか)

これで完了をクリックして、少し待つと、クラスターに登録される

登録した後は、情報同期が行われているようなので、10分ぐらい放置する

登録直後は、各サーバの詳細を見ると、下記のようにストレージ情報がありません、と出る。

しばらく待つとそのサーバのローカルディスクが表示される

他のタブでも同様の状態となっているのだが、情報更新中であることを示すアイコンがあるのかどうか現状不明なので、とりあえず再読み込みしてみるしかない模様

ある程度処理が進んでいると「virsh net-list」の実行結果が下記のように「Management」と「Compute」になっていて、最初合ったdefaultが消えている。

vmadmin@hpevm:~$ virsh net-list --all
 Name         State    Autostart   Persistent
-----------------------------------------------
 Compute      active   yes         yes
 Management   active   yes         yes

vmadmin@hpevm:~$

UEFI Secure BootとTPMについて

現状、以下の機能は実装されていない模様
・UEFI/BIOSの明示的な切り替え
・UEFI時のSecure Boot 有効/無効 切り替え
・TPMの有効化

このため、標準設定のWindows 11をインストールすることはできない。

とりあえず試験的にインストールしたWindowsとLinuxはBIOS構成となっていた。

Windowsのインストールについて

Windows Serverなどをインストールするとき、標準的なWindows ISOイメージにはKVM環境向けのvirtioドライバーが含まれていないため、インストーラ上からディスクを認識できない。

Nutanixなどであれば、途中で読み込ませるISOファイルをVirtioドライバISOに換えればよいのだが、HPE VM EssentailsのWeb UIからISOファイルを別のものに変更する操作が動作しない。

正解は仮想マシン新規作成時の「Advanced Options」の中にある「ATTACH VIRTIO DRIVERS」にチェックを入れる、というもの。

これによりOSインストール用のISOイメージの他に、virtioのISOイメージがマウントされた状態で起動するようになる。

なお、v8.0.2.1の状態ではGUI上で作成済みの仮想マシンに対してISOファイルマウントの設定を行うことはできない模様。

インストールに必要なもの

RedHat VirtIO SCSI controller :VEN_1AF4&DEV_1001 → viostor

デバイスマネージャで警告が表示されたもの

PCIシンプル通信コントローラ :VEN_1AF4&DEV_1003 → vioserial
PCIデバイス :VEN_1AF4&DEV_1002 → balloon
イーサネット コントローラー :VEN_1AF4&DEV_1000 → NetKVM
マルチメディア オーディオ コントローラ :VEN_8086&DEV_2415 → Intel(r) 82801AA AC’97 Audio Controller

マルチメディア オーディオコントローラ(Intel 82801AAエミュレーション)については、適用できるドライバが64bit向けがない?

そのほか virioのISOに含まれるドライバ

VEN_1AF4&DEV_1004 → vioscsi
VEN_1AF4&DEV_1005 → viorng
VEN_1AF4&DEV_1041 → NetKVM
VEN_1AF4&DEV_1044 → viorng
VEN_1AF4&DEV_1045 → balloon
VEN_1AF4&DEV_1050 → viogpudo
VEN_1AF4&DEV_1052 → vioinput
VEN_1AF4&DEV_105A → viofs
VEN_8086&DEV_2930 → smbus
VEN_1B36&DEV_0002 ~ DEV_0004 → qemupciserial
VEN_1B36&DEV_0100 → qxl(xp,win7,2008R2),qxldod (win2012~2019)

(VEN_1AF4,VEN_1B36はRedHat Inc、VEN_8086はIntel)

仮想マシンのコンソールについて

基本的にはWebブラウザから操作することになっている。

が、virtで管理されているので 「virsh dumpxml 仮想マシン名」を実行してみると下記のようなvncに関する設定項目があるのがわかる

    <graphics type='vnc' port='41001' autoport='no' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

上記の場合、サーバローカルに対してのみポート41001でアクセスする場合に使えるので、sshトンネルで127.0.0.1:41001にアクセスする設定をいれてやれば、他のマシンからでも接続できる

この状態で、Windowsにvirt-viewerをインストールして「”C:\Program Files\VirtViewer v11.0-256\bin\remote-viewer.exe” vnc://127.0.0.1:41001」を実行すると接続できる。

パスワードが求められるが、VNCのパスワードはなぜかdumpxmlでは表示されないので「virsh edit 仮想マシン名」を実行して探す必要がある

    <graphics type='vnc' port='41001' autoport='no' listen='127.0.0.1' passwd='Mo8lzACR'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

上記の場合、「Mo8lzACR」がパスワードとなる

iSCSIストレージの追加

まさかクラスター階層の「ストレージ」にiSCSIのターゲットIPの指定があるなんて・・・

これを指定することで、クラスタに所属するサーバ上でiSCSIストレージが追加されました。

vmadmin@hpevm:~$ sudo iscsiadm -m session
tcp: [1] 172.17.44.9:3260,2460 iqn.2007-11.com.nimblestorage:hpevme-v371c7edc5d1bd1e3.000000d2.6a07af3f (non-flash)
tcp: [2] 192.168.44.9:3260,2460 iqn.2007-11.com.nimblestorage:hpevme-v371c7edc5d1bd1e3.000000d2.6a07af3f (non-flash)
vmadmin@hpevm:~$ sudo lsblk
NAME                                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0                                 7:0    0  63.9M  1 loop  /snap/core20/2318
loop1                                 7:1    0    87M  1 loop  /snap/lxd/29351
loop2                                 7:2    0  38.8M  1 loop  /snap/snapd/21759
loop3                                 7:3    0  44.4M  1 loop  /snap/snapd/23545
loop4                                 7:4    0  63.7M  1 loop  /snap/core20/2434
loop5                                 7:5    0  89.4M  1 loop  /snap/lxd/31333
sda                                   8:0    0 447.1G  0 disk
tqsda1                                8:1    0     1G  0 part  /boot/efi
tqsda2                                8:2    0     2G  0 part  /boot
mqsda3                                8:3    0 444.1G  0 part
  tqubuntu--vg-ubuntu--lv           253:0    0   100G  0 lvm   /
  mqubuntu--vg-morpheus             253:1    0   300G  0 lvm   /var/morpheus
sdb                                   8:16   0 447.1G  0 disk
mqsdb1                                8:17   0 447.1G  0 part
sdc                                   8:32   0 447.1G  0 disk
sdd                                   8:48   0 447.1G  0 disk
sde                                   8:64   0 447.1G  0 disk
sdf                                   8:80   0 447.1G  0 disk
sdg                                   8:96   1     0B  0 disk
sdh                                   8:112  0     1T  0 disk
mq22674a991c8b22b4c6c9ce9003faf076a 253:2    0     1T  0 mpath
sdi                                   8:128  0     1T  0 disk
mq22674a991c8b22b4c6c9ce9003faf076a 253:2    0     1T  0 mpath
sr0                                  11:0    1  1024M  0 rom
vmadmin@hpevm:~$ sudo multipath -ll
22674a991c8b22b4c6c9ce9003faf076a dm-2 Nimble,Server
size=1.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 8:0:0:0 sdh 8:112 active ready running
  `- 9:0:0:0 sdi 8:128 active ready running
vmadmin@hpevm:~$

ただ、認識したiSCSIのLUNは、そのままでは利用できず、ファイルシステム作成が必要そうな気配が・・・

セットアップ失敗は再インストールからやり直し

仮想環境上にUbuntu をインストールして、hpe-vmパッケージインストールして、Install morpheusを実施してみたところ、なぜか仮想マシンが作られない

確認したらCPUのハードウェア仮想化/IOMMUを有効化してないせいで、KVMが正常に動かないためだった。

それはいいんだけど、問題なのは、/var/log 以下のどこにもそういったログが見当たらない、ということ。

で・・・有効化して再度実施すればいいのかな?と実行してみたところ、open vswitch側の設定が変なことになっていたらしく、Ubuntu=>VM Managerのping疎通が通らない、という状況に

どこを修正すればいいのかわからない状態なので、Ubuntu OSインストールからやり直すことになりました。(それでうまくいった)

HPE VM Manager仮想マシンのコンソールを開く

VM Manager側の仮想マシンからの疎通確認できるかな?とvirsh edit “VM Managerの名前” でVNCの接続情報を見てvirt-viewerからコンソールを開いてみる

↑はまだセットアップ中だった模様

↓でログインできるようになっていたら初期化が終わってる

Install Morpheusで指定したユーザ名とパスワードでログインできる

HPE VME Manager上にaptレポジトリが作成される

HPE VME Managerからサーバを登録すると、 /etc/apt/sources.list.d/morpheus.list に下記にような内容が追加される

$ cat /etc/apt/sources.list.d/morpheus.list
deb [signed-by=/etc/apt/trusted.gpg.d/morpheus.asc] https://172.17.44.169/apt morpheus main
$

vTPMを有効化する手法

Windows 11仮想マシンを作る場合、vTPMを有効にする必要がある。

インスタンス側の設定項目がないなぁ、と思っていたら、ISOイメージファイルを登録する「仮想イメージ」にて設定項目があるとは思わなかった

ISOイメージ登録時に通常は折りたたまれている「高度」オプションの中にある「UEFI」「VTPM ENABLED」「SECURE BOOT」にチェックを入れておくと、このISOイメージを指定してインスタンスを作成した場合に有効になっている、という仕組みである模様

NFSデータストアは移動しないでクロスvCenter vMotionを実施

vSphere 7環境サーバ群からvSphere 8環境サーバ群に移管するにあたり、vCenterサーバおよびESXiサーバ側についてはまるっきり新設定にするけど、NFSデータストアストレージについては引き続き利用する、ということになった

新環境に仮想マシンを移動させるのに、Advanced Cross vCenter vMotionを使って仮想マシンを稼働状態のまま移動できないか確認した。

必要な設定

・ESXiのvmkernelで、旧環境と新環境間で通信がネットワークにvMotionを設定
・旧環境と新環境は、同じNFSバージョンでマウントする(データストア名は別でも良い)
・旧環境と新環境で同じホスト名解決が出来ること

実験して得た注意点

新旧環境で使えるネットワークにvMotionを設定する

vSphere間の仮想マシンデータの移行でもvMotionを使用するため、新旧環境の両方で通信がとれるvmkernelにvMotion設定を行う必要がある

NFSバージョンは揃える

旧環境NFS v3でマウント、新環境NFS v4.1でマウント、とした場合、別のデータストアとして認識されるようで、同じデータストアの実体でありながらコピー処理が発生した。

その際、元の仮想マシン名のディレクトリに「_1」を付与したディレクトリが作成され、そこにコピーが実施されたため、一時的に倍の容量を使用することになることに注意

データストア名は別でも大丈夫

旧環境と新環境でNFSマウントするときに、データストア名を別の名前でマウントしてみたが、同じデータストアだと認識されるようで、コピー処理は発生しなかった

vMotionキャンセルは旧環境側で実施

今回、新環境側で仮想マシンインポートする、という手法でvMotionを実施した。

この場合、新環境側の「最近のタスク」ではキャンセルが実行できない

旧環境側の「最近のタスク」からだとキャンセルが実行できる

仮想マシン停止状態なら一瞬で終わる

仮想マシン停止状態にしてからNFSストレージは移動させない形でのAdvanced Cross vCenter vMotionを実施したところ、一瞬で移行が完了しました。

テスト用に作ったceph環境でOSDが落ちまくるので osd heartbeat grace を変更してみた(様子見中

Proxmox VEのcephストレージ環境の動作を確認するためESXi上に RAM 16GBの仮想マシンを4台作ってテスト中(+1台 corosync qnetdサーバがいてProxmox VEクラスタの維持に使用)

で、あるタイミングから、各ノード上のosdのdownが多発するようになった

root@pve37:~# ceph osd df tree
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME
-1         0.62549         -  480 GiB  210 GiB  204 GiB  178 KiB  5.4 GiB  270 GiB  43.65  1.00    -          root default
-3         0.15637         -  160 GiB   59 GiB   58 GiB   47 KiB  1.4 GiB  101 GiB  36.92  0.85    -              host pve36
 0    hdd  0.03909   1.00000   40 GiB   15 GiB   14 GiB    7 KiB  403 MiB   25 GiB  36.27  0.83   36      up          osd.0
 1    hdd  0.03909   1.00000   40 GiB   18 GiB   17 GiB   13 KiB  332 MiB   22 GiB  44.03  1.01   52      up          osd.1
 2    hdd  0.03909   1.00000   40 GiB   11 GiB   10 GiB   18 KiB  337 MiB   29 GiB  26.46  0.61   27      up          osd.2
 3    hdd  0.03909   1.00000   40 GiB   16 GiB   16 GiB    9 KiB  393 MiB   24 GiB  40.91  0.94   48      up          osd.3
-5         0.15637         -  160 GiB   67 GiB   66 GiB   75 KiB  1.6 GiB   93 GiB  41.95  0.96    -              host pve37
 4    hdd  0.03909   1.00000   40 GiB   19 GiB   18 GiB   24 KiB  443 MiB   21 GiB  46.87  1.07   51      up          osd.4
 5    hdd  0.03909   1.00000   40 GiB   11 GiB   11 GiB   21 KiB  201 MiB   29 GiB  28.58  0.65   30      up          osd.5
 6    hdd  0.03909   1.00000   40 GiB   16 GiB   16 GiB   12 KiB  294 MiB   24 GiB  39.51  0.91   40      up          osd.6
 7    hdd  0.03909   1.00000   40 GiB   21 GiB   20 GiB   18 KiB  693 MiB   19 GiB  52.84  1.21   61      up          osd.7
-7         0.15637         -   80 GiB   49 GiB   47 GiB   36 KiB  1.3 GiB   31 GiB  60.91  1.40    -              host pve38
 8    hdd  0.03909         0      0 B      0 B      0 B      0 B      0 B      0 B      0     0    0    down          osd.8
 9    hdd  0.03909         0      0 B      0 B      0 B      0 B      0 B      0 B      0     0    0    down          osd.9
10    hdd  0.03909   1.00000   40 GiB   20 GiB   20 GiB   17 KiB  415 MiB   20 GiB  51.02  1.17   53      up          osd.10
11    hdd  0.03909   1.00000   40 GiB   28 GiB   27 GiB   19 KiB  922 MiB   12 GiB  70.80  1.62   73      up          osd.11
-9         0.15637         -   80 GiB   35 GiB   34 GiB   20 KiB  1.1 GiB   45 GiB  43.27  0.99    -              host pve39
12    hdd  0.03909   1.00000   40 GiB   20 GiB   20 GiB    7 KiB  824 MiB   20 GiB  50.81  1.16   63      up          osd.12
13    hdd  0.03909         0      0 B      0 B      0 B      0 B      0 B      0 B      0     0    0    down          osd.13
14    hdd  0.03909   1.00000   40 GiB   14 GiB   14 GiB   13 KiB  303 MiB   26 GiB  35.72  0.82    0    down          osd.14
15    hdd  0.03909         0      0 B      0 B      0 B      0 B      0 B      0 B      0     0    0    down          osd.15
                       TOTAL  480 GiB  210 GiB  204 GiB  183 KiB  5.4 GiB  270 GiB  43.65
MIN/MAX VAR: 0.61/1.62  STDDEV: 11.55
root@pve37:~#

pve38のosd.8とosd.9がdownになっているので、pve38にログインしてプロセスを確認すると、–id 8 と –id 9のceph-osdサービスが起動していないので、これらを再起動する

root@pve38:~# ps -ef|grep osd
ceph        1676       1  1 12:14 ?        00:02:01 /usr/bin/ceph-osd -f --cluster ceph --id 10 --setuser ceph --setgroup ceph
ceph        1681       1  2 12:14 ?        00:02:45 /usr/bin/ceph-osd -f --cluster ceph --id 11 --setuser ceph --setgroup ceph
root       30916   30893  0 14:10 pts/0    00:00:00 grep osd
root@pve38:~# systemctl restart ceph-osd@8
root@pve38:~# systemctl restart ceph-osd@9
root@pve38:~#

しばらく待つとupになる

root@pve38:~# ceph osd df tree
ID  CLASS  WEIGHT   REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL    %USE   VAR   PGS  STATUS  TYPE NAME
-1         0.62549         -  600 GiB  227 GiB  221 GiB  229 KiB  5.6 GiB  373 GiB  37.84  1.00    -          root default
-3         0.15637         -  160 GiB   53 GiB   52 GiB   47 KiB  1.4 GiB  107 GiB  33.11  0.88    -              host pve36
 0    hdd  0.03909   1.00000   40 GiB   13 GiB   12 GiB    7 KiB  403 MiB   27 GiB  31.50  0.83   28      up          osd.0
 1    hdd  0.03909   1.00000   40 GiB   16 GiB   16 GiB   13 KiB  332 MiB   24 GiB  40.30  1.07   47      up          osd.1
 2    hdd  0.03909   1.00000   40 GiB  9.7 GiB  9.4 GiB   18 KiB  337 MiB   30 GiB  24.21  0.64   22      up          osd.2
 3    hdd  0.03909   1.00000   40 GiB   15 GiB   14 GiB    9 KiB  393 MiB   25 GiB  36.41  0.96   41      up          osd.3
-5         0.15637         -  160 GiB   61 GiB   59 GiB   75 KiB  1.6 GiB   99 GiB  37.89  1.00    -              host pve37
 4    hdd  0.03909   1.00000   40 GiB   16 GiB   15 GiB   24 KiB  443 MiB   24 GiB  39.75  1.05   41      up          osd.4
 5    hdd  0.03909   1.00000   40 GiB   10 GiB   10 GiB   21 KiB  201 MiB   30 GiB  25.52  0.67   26      up          osd.5
 6    hdd  0.03909   1.00000   40 GiB   14 GiB   13 GiB   12 KiB  278 MiB   26 GiB  34.26  0.91   32      up          osd.6
 7    hdd  0.03909   1.00000   40 GiB   21 GiB   20 GiB   18 KiB  693 MiB   19 GiB  52.02  1.37   52      up          osd.7
-7         0.15637         -  120 GiB   57 GiB   55 GiB   54 KiB  1.5 GiB   63 GiB  47.17  1.25    -              host pve38
 8    hdd  0.03909   1.00000   40 GiB   14 GiB   14 GiB   18 KiB  132 MiB   26 GiB  35.75  0.94   30      up          osd.8
 9    hdd  0.03909   1.00000      0 B      0 B      0 B      0 B      0 B      0 B      0     0   22      up          osd.9
10    hdd  0.03909   1.00000   40 GiB   18 GiB   18 GiB   17 KiB  419 MiB   22 GiB  45.92  1.21   42      up          osd.10
11    hdd  0.03909   1.00000   40 GiB   24 GiB   23 GiB   19 KiB  939 MiB   16 GiB  59.84  1.58   42      up          osd.11
-9         0.15637         -  160 GiB   57 GiB   56 GiB   53 KiB  1.2 GiB  103 GiB  35.51  0.94    -              host pve39
12    hdd  0.03909   1.00000   40 GiB   15 GiB   14 GiB    7 KiB  841 MiB   25 GiB  37.05  0.98   37      up          osd.12
13    hdd  0.03909   1.00000   40 GiB   16 GiB   16 GiB   16 KiB  144 MiB   24 GiB  39.70  1.05   42      up          osd.13
14    hdd  0.03909   1.00000   40 GiB   14 GiB   14 GiB   16 KiB   84 MiB   26 GiB  35.82  0.95   39      up          osd.14
15    hdd  0.03909   1.00000   40 GiB   12 GiB   12 GiB   14 KiB  127 MiB   28 GiB  29.48  0.78   30      up          osd.15
                       TOTAL  600 GiB  227 GiB  221 GiB  236 KiB  5.6 GiB  373 GiB  37.84
MIN/MAX VAR: 0/1.58  STDDEV: 12.91
root@pve38:~#

が・・・またしばらくすると、他のosdが落ちる、などしていた

RedHat Ceph Storage 7 トラブルシューティングガイドの「第5章 Ceph OSD のトラブルシューティング5.1.7. OSDS のフラップ を確認すると、osdに指定されているディスクが遅いから、ということになるようだ。

osd_heartbeat_grace_time というパラメータをデフォルトの20秒から変更すると、タイムアウトまでの値を緩和できるのかな、と思ったのだが、どうやって設定するのかが不明…

ceph.orgのOSD Setting を見ると /etc/ceph/ceph.conf (PVEの場合、 /etc/pve/ceph.conf )に追加すればいいのかな?というところなんだけど、OSD Config Reference , Configuring Monitor/OSD Interaction を見ても osd_heartbeat_grace_time というパラメータが無い…(osd_heartbeat_grace ならあった)

RedHatドキュメントの続きに書いてある「この問題を解決するには、以下を行います。」のところを見ると、「ceph osd set noup」「ceph osd set nodown」を設定して、OSDをdownおよびupとしてマークするのを停止する、とある。

試しにnoup,nodownの療法を設定してみたところ、OSDサービスを起動してもceph osd df treeで確認するとdownのままとなっていた。

まあ、upになったとしてもupのマークを付けないのが「noup」だから当然ですね・・・

そんなわけで、「ceph osd unset noup」「ceph osd set nodown」でdownにしない、という設定を入れてみた

設定を入れると「ceph osd stat」での状態確認で「flags nodown」と表示されるようになる。

root@pve38:~# ceph osd stat
16 osds: 16 up (since 62m), 16 in (since 62m); epoch: e4996
flags nodown
root@pve38:~#

とりあえず、これで一時的なごまかしはできた。

ただ、これは、OSDで使用しているディスクが壊れたとしても downにならない、ということでもある。

なので、「nodown」フラグを設定しっぱなしで使う、というのはとても不適切となる。

ちゃんとした対処を行うためには、具体的に何が問題になっているのかを「ceph health detail」を実行して、具体的にSlow OSD heartbeats がどれくらい遅いのかを確認する

root@pve38:~# ceph health detail
HEALTH_WARN nodown flag(s) set; Slow OSD heartbeats on back (longest 5166.450ms); Slow OSD heartbeats on front (longest 5467.151ms)
[WRN] OSDMAP_FLAGS: nodown flag(s) set
[WRN] OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 5166.450ms)
    Slow OSD heartbeats on back from osd.13 [] to osd.8 [] 5166.450 msec
    Slow OSD heartbeats on back from osd.13 [] to osd.0 [] 3898.044 msec
    Slow OSD heartbeats on back from osd.12 [] to osd.9 [] 3268.881 msec
    Slow OSD heartbeats on back from osd.10 [] to osd.3 [] 2610.064 msec possibly improving
    Slow OSD heartbeats on back from osd.12 [] to osd.8 [] 2588.321 msec
    Slow OSD heartbeats on back from osd.6 [] to osd.14 [] 2565.141 msec
    Slow OSD heartbeats on back from osd.8 [] to osd.7 [] 2385.851 msec possibly improving
    Slow OSD heartbeats on back from osd.13 [] to osd.11 [] 2324.505 msec
    Slow OSD heartbeats on back from osd.8 [] to osd.12 [] 2305.474 msec possibly improving
    Slow OSD heartbeats on back from osd.14 [] to osd.11 [] 2275.033 msec
    Truncated long network list.  Use ceph daemon mgr.# dump_osd_network for more information
[WRN] OSD_SLOW_PING_TIME_FRONT: Slow OSD heartbeats on front (longest 5467.151ms)
    Slow OSD heartbeats on front from osd.13 [] to osd.8 [] 5467.151 msec
    Slow OSD heartbeats on front from osd.13 [] to osd.0 [] 3956.364 msec
    Slow OSD heartbeats on front from osd.12 [] to osd.9 [] 3513.493 msec
    Slow OSD heartbeats on front from osd.12 [] to osd.8 [] 2657.999 msec
    Slow OSD heartbeats on front from osd.6 [] to osd.14 [] 2657.486 msec
    Slow OSD heartbeats on front from osd.10 [] to osd.3 [] 2610.558 msec possibly improving
    Slow OSD heartbeats on front from osd.8 [] to osd.7 [] 2436.661 msec possibly improving
    Slow OSD heartbeats on front from osd.14 [] to osd.11 [] 2351.914 msec
    Slow OSD heartbeats on front from osd.14 [] to osd.10 [] 2351.812 msec
    Slow OSD heartbeats on front from osd.13 [] to osd.11 [] 2335.698 msec
    Truncated long network list.  Use ceph daemon mgr.# dump_osd_network for more information
root@pve38:~#

osd.7のログが出てるpve37にログインして /var/log/ceph/ceph-osd.7.log から「no replay from」と「osd.8」でgrep をかけてログを確認

おそらく「Slow OSD heartbeats on front from osd.8 [] to osd.7 [] 2436.661 msec」に相当するあたりがコレなのかな?というところ


2024-11-14T14:46:05.457+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:02.037605+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:06.454+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:02.037605+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:07.467+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:07.338127+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:08.418+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:07.338127+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:09.371+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:09.038264+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:10.416+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:09.038264+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)
2024-11-14T14:46:11.408+0900 7e72364006c0 -1 osd.7 4996 heartbeat_check: no reply from 172.17.44.38:6802 osd.8 since back 2024-11-14T14:46:11.338592+0900 front 2024-11-14T14:45:41.850539+0900 (oldest deadline 2024-11-14T14:46:05.334473+0900)

oldset deadlineにある時刻と、その前にある時刻の差は20秒なので、 osd_heartbeat_grace もしくは osd_heartbeat_grace_time のデフォルト値 20 が効いてるんだろうなぁ、と推定できる

設定手法について記載を探してみたのだがなかなかない

 Ceph Block Device 3rd Party Integration »  Ceph iSCSI Gateway »  iSCSI Gateway Requirements に下記のような設定例がある

[osd]
osd heartbeat grace = 20
osd heartbeat interval = 5

また、下記のように個別OSDに対して値を設定することも可能であるようだ

ceph tell osd.* config set osd_heartbeat_grace 20
ceph tell osd.* config set osd_heartbeat_interval 5
ceph daemon osd.0 config set osd_heartbeat_grace 20
ceph daemon osd.0 config set osd_heartbeat_interval 5

ceph tellの書式を確認すると「ceph tell osd.* config get osd_heartbeat_grace」で値がとれる模様

root@pve37:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
    "osd_heartbeat_grace": "20"
}
osd.1: {
    "osd_heartbeat_grace": "20"
}
osd.2: {
    "osd_heartbeat_grace": "20"
}
osd.3: {
    "osd_heartbeat_grace": "20"
}
osd.4: {
    "osd_heartbeat_grace": "20"
}
osd.5: {
    "osd_heartbeat_grace": "20"
}
osd.6: {
    "osd_heartbeat_grace": "20"
}
osd.7: {
    "osd_heartbeat_grace": "20"
}
osd.8: {
    "osd_heartbeat_grace": "20"
}
osd.9: {
    "osd_heartbeat_grace": "20"
}
osd.10: {
    "osd_heartbeat_grace": "20"
}
osd.11: {
    "osd_heartbeat_grace": "20"
}
osd.12: {
    "osd_heartbeat_grace": "20"
}
osd.13: {
    "osd_heartbeat_grace": "20"
}
osd.14: {
    "osd_heartbeat_grace": "20"
}
osd.15: {
    "osd_heartbeat_grace": "20"
}
root@pve37:~#

とりあえず「ceph tell osd.* config set osd_heartbeat_grace 30」と実行し、30に設定してみる

root@pve37:~# ceph tell osd.* config set osd_heartbeat_grace 30
osd.0: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.1: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.2: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.3: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.4: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.5: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.6: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.7: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.8: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.9: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.10: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.11: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.12: {
    "success": "osd_heartbeat_grace = '' (not observed, change may require restart) "
}
osd.13: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.14: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
osd.15: {
    "success": "osd_delete_sleep = '' osd_delete_sleep_hdd = '' osd_delete_sleep_hybrid = '' osd_delete_sleep_ssd = '' osd_heartbeat_grace = '' (not observed, change may require restart) osd_max_backfills = '' osd_pg_delete_cost = '' (not observed, change may require restart) osd_recovery_max_active = '' osd_recovery_max_active_hdd = '' osd_recovery_max_active_ssd = '' osd_recovery_sleep = '' osd_recovery_sleep_hdd = '' osd_recovery_sleep_hybrid = '' osd_recovery_sleep_ssd = '' osd_scrub_sleep = '' osd_snap_trim_sleep = '' osd_snap_trim_sleep_hdd = '' osd_snap_trim_sleep_hybrid = '' osd_snap_trim_sleep_ssd = '' "
}
root@pve37:~#

すべて「”success”」ではあるので設定変更は完了しているのだと思うが、応答が2種類あるのはなんなのだろうか?

設定が変更されたかどうかを確認

root@pve37:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
    "osd_heartbeat_grace": "30"
}
osd.1: {
    "osd_heartbeat_grace": "30"
}
osd.2: {
    "osd_heartbeat_grace": "30"
}
osd.3: {
    "osd_heartbeat_grace": "30"
}
osd.4: {
    "osd_heartbeat_grace": "30"
}
osd.5: {
    "osd_heartbeat_grace": "30"
}
osd.6: {
    "osd_heartbeat_grace": "30"
}
osd.7: {
    "osd_heartbeat_grace": "30"
}
osd.8: {
    "osd_heartbeat_grace": "30"
}
osd.9: {
    "osd_heartbeat_grace": "30"
}
osd.10: {
    "osd_heartbeat_grace": "30"
}
osd.11: {
    "osd_heartbeat_grace": "30"
}
osd.12: {
    "osd_heartbeat_grace": "30"
}
osd.13: {
    "osd_heartbeat_grace": "30"
}
osd.14: {
    "osd_heartbeat_grace": "30"
}
osd.15: {
    "osd_heartbeat_grace": "30"
}
root@pve37:~#

とはいえ、set時の出力に「(not observed, change may require restart)」とあるとおり、ceph-osdの再起動が必須であるようだ

/etc/pve/ceph.conf に変更したパラメータは反映されてない模様なので、 osd.4~osd.7があるサーバを再起動してからもう一度値を確認してみたら、20に戻っていた。

root@pve38:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
    "osd_heartbeat_grace": "30"
}
osd.1: {
    "osd_heartbeat_grace": "30"
}
osd.2: {
    "osd_heartbeat_grace": "30"
}
osd.3: {
    "osd_heartbeat_grace": "30"
}
osd.4: {
    "osd_heartbeat_grace": "20"
}
osd.5: {
    "osd_heartbeat_grace": "20"
}
osd.6: {
    "osd_heartbeat_grace": "20"
}
osd.7: {
    "osd_heartbeat_grace": "20"
}
osd.8: {
    "osd_heartbeat_grace": "30"
}
osd.9: {
    "osd_heartbeat_grace": "30"
}
osd.10: {
    "osd_heartbeat_grace": "30"
}
osd.11: {
    "osd_heartbeat_grace": "30"
}
osd.12: {
    "osd_heartbeat_grace": "30"
}
osd.13: {
    "osd_heartbeat_grace": "30"
}
osd.14: {
    "osd_heartbeat_grace": "30"
}
osd.15: {
    "osd_heartbeat_grace": "30"
}
root@pve38:~#

/etc/pve/ceph.conf の最後に下記を追加

[osd]
        osd heartbeat grace = 30

設定後、再起動してから確認すると、想定通り30になっているのを確認。そもそも、osd_heartbeat_grace についてはceph tellコマンドでの設定変更後、再起動しないでも大丈夫、というやつなんでは?

root@pve38:~# ceph tell osd.* config get osd_heartbeat_grace
osd.0: {
    "osd_heartbeat_grace": "30"
}
osd.1: {
    "osd_heartbeat_grace": "30"
}
osd.2: {
    "osd_heartbeat_grace": "30"
}
osd.3: {
    "osd_heartbeat_grace": "30"
}
osd.4: {
    "osd_heartbeat_grace": "30"
}
osd.5: {
    "osd_heartbeat_grace": "30"
}
osd.6: {
    "osd_heartbeat_grace": "30"
}
osd.7: {
    "osd_heartbeat_grace": "30"
}
osd.8: {
    "osd_heartbeat_grace": "30"
}
osd.9: {
    "osd_heartbeat_grace": "30"
}
osd.10: {
    "osd_heartbeat_grace": "30"
}
osd.11: {
    "osd_heartbeat_grace": "30"
}
osd.12: {
    "osd_heartbeat_grace": "30"
}
osd.13: {
    "osd_heartbeat_grace": "30"
}
osd.14: {
    "osd_heartbeat_grace": "30"
}
osd.15: {
    "osd_heartbeat_grace": "30"
}
root@pve38:~#

Proxmox VEクラスタをUPSで停止する手法のメモ(調査段階

Proxmox VE環境でcephによるストレージ領域を作成して、物理的にディスクを共有していない状態で複数サーバ間を1ファイルシステムで運用できる環境についての試験中。

Proxmox VEクラスタをUPS連動で停止する場合の処理について確認しているのだが、公式ドキュメントにそのまま使えるようなものがないので、情報を集めているところ・・・

Proxmox VE公式ドキュメント:Shutdown Proxmox VE + Ceph HCI cluster
これはceph側の処理だけかかれていて、ceph側を止める前には仮想マシンを停止しなければならないのに、そこについて触れていない。

Proxmox VEフォーラムを探す
Clean shutdown of whole cluster (2023/01/16)
Shutdown of the Hyper-Converged Cluster (CEPH) (2020/04/05)

ここらのスクリプトが使えそうだが、仮想マシン/コンテナを停止するのは「各ノードで pvenode stopallを実行」ではなく、「APIを使ってすべてを停止する」が推奨される模様。

ここから試験

「pvesh get /nodes」でノードリストを作って、「ssh ホスト名 pvenode stopall」で仮想マシンを停止できるか試してみたが、管理Web上は「VMとコンテナの一括シャットダウン」と出力されるのだが、仮想マシンの停止が実行されなかった。

3.11.3. Bulk Guest Power Management を見ると止まっても良さそうなんだけど・・・

pvesh コマンドを調べるとこちらでも停止させることができる模様なので下記で実施

for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`; do for vmid in `pvesh ls /nodes/$hostname/qemu/|awk '{ print $2 }'`; do pvesh create /nodes/$hostname/qemu/$vmid/status/shutdown; done; done

実行例

root@pve36:~# for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`
> do for vmid in `pvesh ls /nodes/$hostname/qemu/|awk '{ print $2 }'`
>   do
>     pvesh create /nodes/$hostname/qemu/$vmid/status/shutdown
>   done
> done
VM 102 not running

Requesting HA stop for VM 102
UPID:pve36:00014A47:0018FC0A:6731A591:hastop:102:root@pam:
VM 100 not running
Requesting HA stop for VM 100"UPID:pve37:00013A71:0018FDDC:6731A597:hastop:100:root@pam:"
VM 101 not running
Requesting HA stop for VM 101"UPID:pve38:000144BF:00192F03:6731A59D:hastop:101:root@pam:"
Requesting HA stop for VM 103"UPID:pve38:000144DC:0019305D:6731A5A0:hastop:103:root@pam:"
root@pve36:~#

これで、停止することを確認

次に仮想マシンの停止確認

root@pve36:~# pvesh get /nodes/pve36/qemu
lqqqqqqqqqwqqqqqqwqqqqqqwqqqqqqwqqqqqqqqqqqwqqqqqqqqqqwqqqqqqqqqwqqqqqwqqqqqqqqqqqwqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqqwqqqqqqwqqqqqqqqk
x status  x vmid x cpus x lock x   maxdisk x   maxmem x name    x pid x qmpstatus x running-machine x running-qemu x tags x uptime x
tqqqqqqqqqnqqqqqqnqqqqqqnqqqqqqnqqqqqqqqqqqnqqqqqqqqqqnqqqqqqqqqnqqqqqnqqqqqqqqqqqnqqqqqqqqqqqqqqqqqnqqqqqqqqqqqqqqnqqqqqqnqqqqqqqqu
x stopped x  102 x    2 x      x 32.00 GiB x 2.00 GiB x testvm2 x     x           x                 x              x      x     0s x
mqqqqqqqqqvqqqqqqvqqqqqqvqqqqqqvqqqqqqqqqqqvqqqqqqqqqqvqqqqqqqqqvqqqqqvqqqqqqqqqqqvqqqqqqqqqqqqqqqqqvqqqqqqqqqqqqqqvqqqqqqvqqqqqqqqj
root@pve36:~#

ヘッダーを付けない形式で出力

root@pve36:~# pvesh get /nodes/pve36/qemu --noborder --noheader
stopped  102    2      32.00 GiB 2.00 GiB testvm2                                                 0s
root@pve36:~#

“stopped” となってない行があればまだ停止していない、ということになるので「pvesh get /nodes/pve36/qemu –noborder –noheader|grep -v “stopped”」の出力結果があるかどうかで判断できそう

また、これらはqemu仮想マシンについてのみなので、lxcコンテナについては含まれないので、そちらについても対応する

停止

for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`; do for vmid in `pvesh ls /nodes/$hostname/lxc/|awk '{ print $2 }'`; do pvesh create /nodes/$hostname/lxc/$vmid/status/shutdown;done;done

仮想マシンが止まったかを判断するには、すべての仮想マシンの状態が”stopped”になっているか、で判定するなら下記

for hostname in `pvesh ls /nodes/|awk '{ print $2 }'`; do  echo "=== $hostname ===";    flag=0;  while [ $flag -eq 0 ];  do    pvesh get /nodes/$hostname/qemu --noborder --noheader|grep -v "stopped" > /dev/null;    flag=$?;    echo $flag;  done; done

すべての仮想マシンの状態で”running”がないことなら

for hostname in pvesh ls /nodes/|awk '{ print $2 }'; do echo “=== $hostname ===”; flag=0; while [ $flag -eq 0 ]; do pvesh get /nodes/$hostname/qemu –noborder –noheader|grep “running” > /dev/null ; flag=$?; echo $flag; done; done

どっちがいいかは悩むところ


Cephの停止についてはRedHatの「2.10. Red Hat Ceph Storage クラスターの電源をオフにして再起動」とProxmoxの「Shutdown Proxmox VE + Ceph HCI cluster 」を確認

Proxmox VE側だと下記だけ

ceph osd set noout
ceph osd set norecover
ceph osd set norebalance
ceph osd set nobackfill
ceph osd set nodown
ceph osd set pause

RedHat側にはこれらを実行する前にcephfsを停止するための手順が追加されている。

ceph fs set FS_NAME max_mds 1
ceph mds deactivate FS_NAME:1 # rank 2 of 2
ceph status # wait for rank 1 to finish stopping
ceph fs set FS_NAME cluster_down true
ceph mds fail FS_NAME:0

ceph fs setで設定しているmax_mdsとcluster_downの値はどうなっているのかを確認

root@pve36:~# ceph fs get cephfs
Filesystem 'cephfs' (1)
fs_name cephfs
epoch   65
flags   12 joinable allow_snaps allow_multimds_snaps
created 2024-11-05T14:29:45.941671+0900
modified        2024-11-11T11:04:06.223151+0900
tableserver     0
root    0
session_timeout 60
session_autoclose       300
max_file_size   1099511627776
max_xattr_size  65536
required_client_features        {}
last_failure    0
last_failure_osd_epoch  3508
compat  compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,7=mds uses inline data,8=no anchor table,9=file layout v2,10=snaprealm v2}
max_mds 1
in      0
up      {0=784113}
failed
damaged
stopped
data_pools      [3]
metadata_pool   4
inline_data     disabled
balancer
bal_rank_mask   -1
standby_count_wanted    1
[mds.pve36{0:784113} state up:active seq 29 addr [v2:172.17.44.36:6800/1472122357,v1:172.17.44.36:6801/1472122357] compat {c=[1],r=[1],i=[7ff]}]
root@pve36:~#

cluster_downはない?

root@pve36:~# ceph mds stat
cephfs:1 {0=pve36=up:active} 1 up:standby
root@pve36:~# ceph mds compat show
compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=no anchor table,9=file layout v2,10=snaprealm v2}
root@pve36:~#

んー? ceph fsのcluster_down を実行してみる

root@pve36:~# ceph fs set cephfs cluster_down true
cephfs marked not joinable; MDS cannot join as newly active. WARNING: cluster_down flag is deprecated and will be removed in a future version. Please use "joinable".
root@pve36:~#

joinableを使えとあるので、この記述は古いらしい

おや?と思って再度探したところRedHatのドキュメントが古かった。RedHat「2.5. Red Hat Ceph Storage クラスターの電源をオフにして再起動」、もしくはIBMの「Ceph File System ・クラスターの停止

ceph fs set FS_NAME max_mds 1
ceph fs fail FS_NAME
ceph status
ceph fs set FS_NAME joinable false

IBM手順の方だとmax_mdsの操作は行わずに実施している

root@pve36:~# ceph fs status
cephfs - 4 clients
======
RANK  STATE    MDS      ACTIVITY     DNS    INOS   DIRS   CAPS
 0    active  pve36  Reqs:    0 /s    21     20     16     23
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   122G
  cephfs_data      data    31.8G   122G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# ceph fs fail cephfs
cephfs marked not joinable; MDS cannot join the cluster. All MDS ranks marked failed.
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE   MDS  ACTIVITY  DNS  INOS  DIRS  CAPS
 0    failed
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   122G
  cephfs_data      data    31.8G   122G
STANDBY MDS
   pve37
   pve36
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# ceph fs fail cephfs
cephfs marked not joinable; MDS cannot join the cluster. All MDS ranks marked failed.
root@pve36:~# echo $?
0
root@pve36:~#  ceph fs set cephfs joinable false
cephfs marked not joinable; MDS cannot join as newly active.
root@pve36:~# echo $?
0
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE   MDS  ACTIVITY  DNS  INOS  DIRS  CAPS
 0    failed
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   122G
  cephfs_data      data    31.8G   122G
STANDBY MDS
   pve37
   pve36
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~#

…止めてしまったら、dfコマンドが実行できなくなるので注意

root@pve36:~# ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3599
root@pve36:~# ceph osd set noout
noout is set
root@pve36:~# ceph osd set norecover
norecover is set
root@pve36:~# ceph osd set norebalance
norebalance is set
root@pve36:~# ceph osd set nobackfill
nobackfill is set
root@pve36:~# ceph osd set nodown
nodown is set
root@pve36:~# ceph osd set pause
pauserd,pausewr is set
root@pve36:~# ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~#

ドキュメントに「重要 上記の例は、OSD ノード内のサービスと各 OSD を停止する場合のみであり、各 OSD ノードで繰り返す必要があります。」とあるので、各サーバで確認してみたが、別に各サーバで実行する必要はなさそうである。

root@pve36:~# ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~# ssh pve37 ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~# ssh pve38 ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~# ssh pve39 ceph osd stat
16 osds: 16 up (since 6h), 16 in (since 3d); epoch: e3605
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~#

このあと、各サーバに対してshutdown -h nowを実行して止めた

起動後

root@pve36:~# ceph status
  cluster:
    id:     4647497d-17da-46f4-8e7b-231365d96e42
    health: HEALTH_ERR
            1 filesystem is degraded
            1 filesystem is offline
            pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover flag(s) set

  services:
    mon: 3 daemons, quorum pve36,pve37,pve38 (age 41s)
    mgr: pve38(active, since 30s), standbys: pve37, pve36
    mds: 0/1 daemons up (1 failed), 2 standby
    osd: 16 osds: 16 up (since 48s), 16 in (since 3d)
         flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover

  data:
    volumes: 0/1 healthy, 1 failed
    pools:   4 pools, 193 pgs
    objects: 17.68k objects, 69 GiB
    usage:   206 GiB used, 434 GiB / 640 GiB avail
    pgs:     193 active+clean

root@pve36:~# ceph osd stat
16 osds: 16 up (since 69s), 16 in (since 3d); epoch: e3621
flags pauserd,pausewr,nodown,noout,nobackfill,norebalance,norecover
root@pve36:~#

root@pve36:~# ceph fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE   MDS  ACTIVITY  DNS  INOS  DIRS  CAPS
 0    failed
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
   pve36
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~#

復帰のためのコマンド群1

root@pve36:~# ceph osd unset noout
noout is unset
root@pve36:~# ceph osd unset norecover
norecover is unset
root@pve36:~# ceph osd unset norebalance
norebalance is unset
root@pve36:~#  ceph osd unset nobackfill
nobackfill is unset
root@pve36:~# ceph osd unset nodown
nodown is unset
root@pve36:~# ceph osd unset pause
pauserd,pausewr is unset
root@pve36:~# ceph osd stat
16 osds: 16 up (since 100s), 16 in (since 3d); epoch: e3627
root@pve36:~# ceph status
  cluster:
    id:     4647497d-17da-46f4-8e7b-231365d96e42
    health: HEALTH_ERR
            1 filesystem is degraded
            1 filesystem is offline

  services:
    mon: 3 daemons, quorum pve36,pve37,pve38 (age 102s)
    mgr: pve38(active, since 90s), standbys: pve37, pve36
    mds: 0/1 daemons up (1 failed), 2 standby
    osd: 16 osds: 16 up (since 108s), 16 in (since 3d)

  data:
    volumes: 0/1 healthy, 1 failed
    pools:   4 pools, 193 pgs
    objects: 17.68k objects, 69 GiB
    usage:   206 GiB used, 434 GiB / 640 GiB avail
    pgs:     193 active+clean

  io:
    client:   21 KiB/s rd, 0 B/s wr, 9 op/s rd, 1 op/s wr

root@pve36:~#

ファイルシステム再開

root@pve36:~# ceph fs set cephfs joinable true
cephfs marked joinable; MDS may join as newly active.
root@pve36:~# ceph fs status
cephfs - 4 clients
======
RANK    STATE     MDS   ACTIVITY   DNS    INOS   DIRS   CAPS
 0    reconnect  pve36              10     10      6      0
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# ceph osd stat
16 osds: 16 up (since 2m), 16 in (since 3d); epoch: e3627
root@pve36:~# cpeh status
-bash: cpeh: command not found
root@pve36:~# ceph status
  cluster:
    id:     4647497d-17da-46f4-8e7b-231365d96e42
    health: HEALTH_WARN
            1 filesystem is degraded

  services:
    mon: 3 daemons, quorum pve36,pve37,pve38 (age 2m)
    mgr: pve38(active, since 2m), standbys: pve37, pve36
    mds: 1/1 daemons up, 1 standby
    osd: 16 osds: 16 up (since 2m), 16 in (since 3d)

  data:
    volumes: 0/1 healthy, 1 recovering
    pools:   4 pools, 193 pgs
    objects: 17.68k objects, 69 GiB
    usage:   206 GiB used, 434 GiB / 640 GiB avail
    pgs:     193 active+clean

root@pve36:~#
root@pve36:~# ceph fs status
cephfs - 4 clients
======
RANK  STATE    MDS   ACTIVITY   DNS    INOS   DIRS   CAPS
 0    rejoin  pve36              10     10      6      0
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# df
Filesystem           1K-blocks     Used Available Use% Mounted on
udev                   8156156        0   8156156   0% /dev
tmpfs                  1638000     1124   1636876   1% /run
/dev/mapper/pve-root  28074060 14841988  11780656  56% /
tmpfs                  8189984    73728   8116256   1% /dev/shm
tmpfs                     5120        0      5120   0% /run/lock
/dev/fuse               131072       36    131036   1% /etc/pve
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-2
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-0
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-1
tmpfs                  8189984       28   8189956   1% /var/lib/ceph/osd/ceph-3
tmpfs                  1637996        0   1637996   0% /run/user/0
root@pve36:~# ceph fs status
cephfs - 0 clients
======
RANK  STATE    MDS      ACTIVITY     DNS    INOS   DIRS   CAPS
 0    active  pve36  Reqs:    0 /s    10     10      6      0
      POOL         TYPE     USED  AVAIL
cephfs_metadata  metadata   244M   125G
  cephfs_data      data    31.8G   125G
STANDBY MDS
   pve37
MDS version: ceph version 18.2.4 (2064df84afc61c7e63928121bfdd74c59453c893) reef (stable)
root@pve36:~# df
Filesystem                               1K-blocks     Used Available Use% Mounted on
udev                                       8156156        0   8156156   0% /dev
tmpfs                                      1638000     1128   1636872   1% /run
/dev/mapper/pve-root                      28074060 14841992  11780652  56% /
tmpfs                                      8189984    73728   8116256   1% /dev/shm
tmpfs                                         5120        0      5120   0% /run/lock
/dev/fuse                                   131072       36    131036   1% /etc/pve
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-2
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-0
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-1
tmpfs                                      8189984       28   8189956   1% /var/lib/ceph/osd/ceph-3
tmpfs                                      1637996        0   1637996   0% /run/user/0
172.17.44.36,172.17.44.37,172.17.44.38:/ 142516224 11116544 131399680   8% /mnt/pve/cephfs
root@pve36:~#

ただ、これだと通常のPVE起動プロセスで実行される「VMとコンテナの一括起動」で仮想マシンが実行されなかった。おや?と思ったら、設定が変わってた

root@pve36:~# ha-manager status
quorum OK
master pve39 (active, Mon Nov 11 18:24:13 2024)
lrm pve36 (idle, Mon Nov 11 18:24:15 2024)
lrm pve37 (idle, Mon Nov 11 18:24:18 2024)
lrm pve38 (idle, Mon Nov 11 18:24:18 2024)
lrm pve39 (idle, Mon Nov 11 18:24:15 2024)
service vm:100 (pve37, stopped)
service vm:101 (pve38, stopped)
service vm:102 (pve36, stopped)
service vm:103 (pve38, stopped)
root@pve36:~# ha-manager config
vm:100
        state stopped

vm:101
        state stopped

vm:102
        state stopped

vm:103
        state stopped

root@pve36:~#

27ヶ月前に設定した Oracle VM Manager が動かなくなった件

久しぶりに稼働させたOracle VM環境を操作するため、Oracle VM Managerにブラウザからログインしようとしたら応答がない・・・

Oracle VM Managerを稼働させているLinuxにログインして「systemctl status」を実行してもサービスの起動に失敗しているわけでもなさそうだ。

「systemctl status ovmm」でも特にコレといったものはない。

/var/log 以下にそれっぽいログがないので、ドキュメントを確認・・・Oracle VM 管理者ガイド「13.3 Oracle VM Managerのトラブルシューティング」に /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/logs ディレクトリにログが出力されている、ということなので確認

ざらざらーっと、AdminServer.log ログを見ていくと、「com.oracle.appfw.ovm.coreinferface.ventprocessing.EventPollerTask」で「com.sun.jersey.api.client.ClientHandlerException: jav a.net.ConnectException: 接続を拒否されました (Connection refused)」といったものが多数見受けられる。

おそらくなにかサービスがうまく動作していないんだろうなぁ、とさらに見ていくと、SSL証明書を読み込んだログのあたりで「Identity certificate has expired:」とか「Signature: ~ の期限が切れています。」といったものが・・・

お?これが問題か?とさらに深掘り

Oracle VM 管理者ガイド「2.2.2 証明書構成の表示」に/u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh show コマンドで状態確認などができる、ということがわかった。

続いて「Oracle VM Manager SSL Certificates ReGeneration with ovmkeytool.sh」に、SSL証明書の更新を行うという、そのものの手順があることを見つけた。

しかし・・・試してみると、ovmkeytool.shの実行にはOracle VM Managerインストール時にweblogicユーザに対して設定したパスワードが必要とのことだった。

Oracle VM管理者ガイド「4.2 Oracle VM Managerのユーザー・パスワードの変更」にあるように、通常は、Oracle VM Managerのadminアカウントと一緒にしてることが多いらしい

が・・・それを使ってみても接続できなかった。

weblogicユーザのパスワードを初期化する方法がないかを確認していたところ、WebLogicを自動起動させる仕組みで使われているAESで暗号化されたユーザ名とパスワード文字列がかかれたテキストファイルを利用すると、設定されているパスワードがなんであるのかを確認できる、ということがわかった。

How to Decrypt/Encrypt WebLogic and Datasource Password via WLSDM?

上記はweblogic汎用の手順になっているので、Oracle VM Managerの場合に即した手順で確認していく。

まず、WebLogic Scripting Tool(WLST)を起動する必要があるので、そのパスを確認する。

[root@ovm security]# find /u01 -print |grep wlst.sh
/u01/app/oracle/Middleware/oracle_common/common/bin/wlst.sh
/u01/app/oracle/Middleware/wlserver/common/bin/wlst.sh
/u01/app/oracle/ovm-manager-3/ovm_wlst/bin/wlst.sh
[root@ovm security]#

3種類出てきたが、ovm-manager-3以下にあるやつだろう、とそれを使う

また、WebLogic起動時に読み込まれているファイルは /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/security/boot.properties なので、その内容を確認

[root@ovm security]# cat /u01/app/oracle/ovm-manager-3/domains/ovm_domain/servers/AdminServer/security/boot.properties
# Generated by Configuration Wizard on Fri May 28 17:13:40 JST 2021
username={AES}<文字列>=
password={AES}<文字列>=
[root@ovm security]#

WLSTは環境変数MW_HOMEを設定する必要があるので、/u01/app/oracle/Middlewareと設定して起動

[root@ovm security]# export  MW_HOME=/u01/app/oracle/Middleware
[root@ovm security]# echo  $MW_HOME
/u01/app/oracle/Middleware
[root@ovm security]# /u01/app/oracle/ovm-manager-3/ovm_wlst/bin/wlst.sh

WebLogic Scripting Tool(WLST)を初期化しています...

WebLogic Server Administration Scripting Shellへようこそ

使用可能なコマンドに関するヘルプを表示するには、help()と入力してください

wls:/offline> 

Oracle VM Managerではdomainに相当するディレクトリは /u01/app/oracle/ovm-manager-3/domains/ovm_domain であるようなので、以下を設定

wls:/offline> domain="/u01/app/oracle/ovm-manager-3/domains/ovm_domain"
wls:/offline> service = weblogic.security.internal.SerializedSystemIni.getEncryptionService(domain)
wls:/offline> 

最後に暗号化文字列を埋め込んでrintコマンドを実行

wls:/offline> print "Weblogic server Admin password : %s" %encryption.decrypt("{AES}<文字列>=")
Weblogic server Admin password : Password123
wls:/offline>

え・・・なんでPassword123 なんて設定してんの???と疑問がわきつつも、とりあえずweblogicユーザのパスワード解読に成功


続いて本題のSSL証明書の更新を実施

証明書関連ファイルは下記に配置されているようだ
 /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security
 /u01/app/oracle/ovm-manager-3/domains/ovm_domain/config

更新は「/u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh check」を実行して行う

基本的に標準値でよいのだが、いくつか気をつけるべきポイントがあった。

[root@ovm security]# /u01/app/oracle/ovm-manager-3/ovm_upgrade/bin/ovmkeytool.sh setup
6 12, 2024 1:22:41 午後 oracle.security.jps.JpsStartup start
情報: JPSの初期化中です。
6 12, 2024 1:22:42 午後 oracle.security.jps.JpsStartup start
情報: Jpsが開始されました。
Oracle VM Manager is currently configured to use CA keystore at:
        /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmca.jks
Do you wish to generate a new key and/or specify a different keystore? [yes]
Generate new CA keystore (as opposed to specifying an existing keystore)? [yes]
Path for CA keystore: [/u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmca.jks]
A file already exists at the path /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmca.jks
Is it ok to ovewrite this file with your new keystore? [no] yes

1個目が↑の既存ファイルを置き換えるか、というもの

置き換えるので「yes」と入力

Oracle VM Manager is currently configured to use the SSL Trust-store at:
        /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmtrust.jks
Do you wish to use this existing trust-store location? [yes]
Validity in months: [120]
Key distinguished name is "CN=OVM CA 0004fb0000010000615876ff13b9da0d, OU=Oracle VM Manager, O=Oracle Corporation, L=Redwood City, ST=California, C=US".  Use these values? [yes]
You may either specify passwords or use random passwords.
If you choose to use a random password, only WebLogic, the Oracle VM Manager,
and this application will have access to the information stored in this
keystore.
Use random passwords? [yes]
Generating CA key and certificate and persisting them to the keystore...

Oracle VM Manager is currently configured to use SSL keystore at:
        /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmssl.jks
Do you wish to generate a new key and/or specify a different keystore? [yes]
Generate new SSL keystore (as opposed to specifying an existing keystore)? [yes]
Path for SSL keystore: [/u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmssl.jks]
A file already exists at the path /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmssl.jks
Is it ok to ovewrite this file with your new keystore? [no] yes

2個目も上書きするか、なので「yes」

The hostname should be the fully qualified hostname of the system
(this is the hostname you'd use to access this system from outside the
local domain).  Depending on your machine setup the value below may not be
correct.
Fully qualified hostname: [ovm]
Validity in months: [27] 120

で、3つ目が最大の罠でした。

証明書の有効期限、初期値が「27ヶ月」でした。

これを設定した関係者に聞くと、あー、たしかにそれくらいの時期にインストールしてたな、とのこと・・・

このせいで止まってたのか。

とりあえず120ヶ月を指定して進めた

Key distinguished name is "CN=ovm, OU=Oracle VM Manager, O=Oracle Corporation, L=Redwood City, ST=California, C=US".  Use these values? [yes]
Alternate hostnames (separated by commas): [ovm]
Generating SSL key and certificate and persisting them to the keystore...

Updating keystore information in WebLogic
Oracle MiddleWare Home (MW_HOME): [/u01/app/oracle/Middleware]
WebLogic domain directory: [/u01/app/oracle/ovm-manager-3/domains/ovm_domain]
WebLogic server name: [AdminServer]
WebLogic username: [weblogic]
WebLogic password: [********]
WLST session logged at: /tmp/wlst-session138870891195064865.log

[root@ovm security]#

これで証明書更新に成功

Oracle VM Managerを再起動

[root@ovm security]# systemctl stop ovmm
[root@ovm security]# systemctl start ovmm
[root@ovm security]# 

再起動後、WebLogicとアプリケーション間でいろいろ設定が必要なようで、用意されている証明書更新スクリプトを実行 /u01/app/oracle/ovm-manager-3/bin/configure_client_cert_login.sh

[root@ovm logs]# /u01/app/oracle/ovm-manager-3/bin/configure_client_cert_login.sh

WebLogic Scripting Tool(WLST)を初期化しています...

WebLogic Server Administration Scripting Shellへようこそ

使用可能なコマンドに関するヘルプを表示するには、help()と入力してください

2024-06-12 13:30:12,297 [main] INFO  ovm.wlst.commands - Connecting using URL t3://localhost:7001

ロケーションがserverRuntimeツリーに移動しました。これは、DomainMBeanをルートとする読取り専用のツリーです。
詳細は、help('domainConfig')を使用してください

2024-06-12 13:30:13,823 [main] INFO  ovm.wlst.commands - Undeploying ovm_console
アプリケーションovm_consoleをアンデプロイしています ...
<2024/06/12 13時30分14秒 JST> <Info> <J2EE Deployment SPI> <BEA-260121> <アプリケーションovm_console [アーカイブ: null]のundeploy操作をAdminServer に初期化しています。>
.アプリケーションのアンデプロイメントが完了しました(ステータスcompleted)
現在のデプロイメント・ステータス:
デプロイメント・コマンドのタイプ: undeploy
デプロイメント状態: completed
デプロイメント・メッセージ: メッセージなし
すでにドメイン構成ツリーを参照しています

2024-06-12 13:30:17,654 [main] INFO  ovm.wlst.commands - Undeploying ovm_core
アプリケーションovm_coreをアンデプロイしています ...
<2024/06/12 13時30分17秒 JST> <Info> <J2EE Deployment SPI> <BEA-260121> <アプリケーションovm_core [アーカイブ: null]のundeploy操作をAdminServer に初期 化しています。>
........アプリケーションのアンデプロイメントが完了しました(ステータスcompleted)
現在のデプロイメント・ステータス:
デプロイメント・コマンドのタイプ: undeploy
デプロイメント状態: completed
デプロイメント・メッセージ: メッセージなし
2024-06-12 13:30:42,942 [main] INFO  ovm.wlst.domainbuilder.Domain - Stopping AdminServer...
Stopping Weblogic Server...

WebLogic Scripting Tool(WLST)を初期化しています...

WebLogic Server Administration Scripting Shellへようこそ

使用可能なコマンドに関するヘルプを表示するには、help()と入力してください

ユーザーID weblogicでt3://localhost:7001に接続しています ...
ドメイン"ovm_domain"に属する管理サーバー"AdminServer"に。が正常に接続されました

警告: サーバーへの接続に安全でないプロトコルが使用
されました。通信セキュリティを確保するには、かわりにSSLポートまたは
管理ポートを使用する必要があります。

AdminServerへの接続中にサーバーAdminServerをforce=falseで停止しています...
WebLogic Serverから切断されました: AdminServer
WLSTからWebLogic Serverへの接続が失われました。
これは、サーバーが停止されたか、または分離された場合に
発生することがあります。サーバーが使用可能になったら再接続する必要が
あります。
WebLogic Serverから切断されました: AdminServer


WebLogic Scripting Toolを終了しています。

Done
Stopping Derby Server...
WLSTからWebLogic Serverへの接続が失われました。
これは、サーバーが停止されたか、または分離された場合に
発生することがあります。サーバーが使用可能になったら再接続する必要が
あります。
Derby server stopped.
WebLogic Serverから切断されました: AdminServer
2024-06-12 13:30:48,511 [main] INFO  ovm.wlst.domainbuilder.Domain - Starting AdminServer...
2024-06-12 13:30:48,516 [main] INFO  ovm.wlst.domainbuilder.Domain - Trying to connect to t3://localhost:7001...
2024-06-12 13:30:58,591 [main] INFO  ovm.wlst.domainbuilder.Domain - Trying to connect to t3://localhost:7001...
2024-06-12 13:31:09,546 [main] INFO  ovm.wlst.domainbuilder.Domain - Trying to connect to t3://localhost:7001...
2024-06-12 13:31:20,692 [main] INFO  ovm.wlst.domainbuilder.Domain - Trying to connect to t3://localhost:7001...

2024-06-12 13:31:21,695 [main] INFO  ovm.wlst.domainbuilder.Domain - Connected.
2024-06-12 13:31:21,799 [main] INFO  ovm.wlst.domainbuilder.Domain - AdminServer state is RUNNING
2024-06-12 13:31:21,799 [main] INFO  ovm.wlst.commands - Deploying ovm_core
/u01/app/oracle/ovm-manager-3/ovm_wlst/deploy/ovm_core/app/ovm_core_3.4.7.244.earのアプリケーションをターゲットAdminServerにデプロイしています(upload=false) ...
<2024/06/12 13時31分22秒 JST> <Info> <J2EE Deployment SPI> <BEA-260121> <アプリケーションovm_core [アーカイブ: /u01/app/oracle/ovm-manager-3/ovm_wlst/deploy/ovm_core/app/ovm_core_3.4.7.244.ear]のdeploy操作をAdminServer に初期化しています。>
...アプリケーションのデプロイメントが完了しました(ステータスcompleted)
現在のデプロイメント・ステータス:
デプロイメント・コマンドのタイプ: deploy
デプロイメント状態: completed
デプロイメント・メッセージ: メッセージなし
すでにドメイン構成ツリーを参照しています


すでにドメイン構成ツリーを参照しています


2024-06-12 13:31:32,213 [main] INFO  ovm.wlst.domainbuilder.Domain - Created a user named appframework
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/u01/app/oracle/ovm-manager-3/ovm_cli/lib/slf4j-log4j12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/u01/app/oracle/Middleware/wlserver/modules/features/weblogic.server.merged.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
6 12, 2024 1:31:32 午後 oracle.security.jps.JpsStartup start
情報: JPSの初期化中です。
6 12, 2024 1:31:34 午後 oracle.security.jps.JpsStartup start
情報: Jpsが開始されました。
2024-06-12 13:31:35,978 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Writing cacert.pem
2024-06-12 13:31:35,979 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Importing cacert.pem with alias ovmca
2024-06-12 13:31:36,350 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Generating key pair for appframework in /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmclient.jks
2024-06-12 13:31:37,016 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Exporting clientcert.pem from /u01/app/oracle/ovm-manager-3/domains/ovm_domain/security/ovmclient.jks
2024-06-12 13:31:37,238 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Reading clientcert.pem
2024-06-12 13:31:37,239 [main] INFO  com.oracle.appfw.ovm.ws.client.SSLClientUtil - Signing certificate
2024-06-12 13:31:37,321 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Writing clientcert.pem
2024-06-12 13:31:37,321 [main] INFO  com.oracle.appfw.ovm.ws.client.KeytoolHelper - Importing clientcert.pem with alias appframework
2024-06-12 13:31:37,991 [main] INFO  com.oracle.appfw.ovm.ws.client.SSLClientUtil - Deleting cacert.pem
2024-06-12 13:31:37,991 [main] INFO  com.oracle.appfw.ovm.ws.client.SSLClientUtil - Deleting clientcert.pem
2024-06-12 13:31:38,004 [main] INFO  ovm.wlst.commands - Deploying ovm_console
/u01/app/oracle/ovm-manager-3/ovm_wlst/deploy/ovm_console/app/ovm_console_3.4.7.244.earのアプリケーションをターゲットAdminServerにデプロイしています(upload=false) ...
<2024/06/12 13時31分38秒 JST> <Info> <J2EE Deployment SPI> <BEA-260121> <アプリケーションovm_console [アーカイブ: /u01/app/oracle/ovm-manager-3/ovm_wlst/deploy/ovm_console/app/ovm_console_3.4.7.244.ear]のdeploy操作をAdminServer に初期化しています。>
..........アプリケーションのデプロイメントが完了しました(ステータスcompleted)
現在のデプロイメント・ステータス:
デプロイメント・コマンドのタイプ: deploy
デプロイメント状態: completed
デプロイメント・メッセージ: メッセージなし
<2024/06/12 13時32分08秒 JST> <Warning> <JNDI> <BEA-050001> <WLContext.close()が作成されたスレッドとは別のスレッドで呼び出されました。>

Client certificate login configuration complete

[root@ovm logs]#

これで、更新がおわったようで、Oracle VM ManagerのWeb管理画面にログインできるようになりました。