Nutanix CE 2.1(AOS 6.8.1)をRyzen 3700UのESXi 8上で構築したときのメモ 2026/04/03版

各仮想環境で作成した仮想マシンハードウェアのlspci上での見た目の違いを確認しようと思って、Nutanix CE環境を新規で構築した

そのときに迷ったことのメモ

入手について

公式には「Nutanix Communitiy Edition」のページから遷移することになるがめんどくさい

マニュアル「Getting Started with Community Edition

リリースノートなどは、サポート契約を要求されていて読むことは出来ない

ソフトウェアのダウンロードは「Download Community Edition」から行う

2026/04/03時点でも、2024/08/19リリースの phoenix.x86_64-fnd_5.6.1_patch-aos_6.8.1_ga.iso が最新である模様

CE 2.1はAOS 6.8.1ですが、通常版は現在 AOS 7.3.0.1 である模様

インストールについて

ESXi 8の場合、「CPU ハードウェア仮想化:ハードウェア アシストによる仮想化をゲスト OS に公開」と「UEFI Secure boot 無効化」だけでいけるかと思いきや

インストーラが途中で/dev/sdbが見つからないとして失敗

NTNX日記の「ESXi で Nested Nutanix CE を構成してみる。(CE 2.1 / AOS 6.8.1 版)」に書いてある「1つめのハード ディスクは、デフォルトで作成されるものを 32GB に変更するか、いったん削除して再作成します。」がポイントだとは思いませんでした。

ゲストOSの種類はNTNX日記だと「Red Hat Enterprise Linux 8 (64 ビット)」だったのでそれで作ったのですが、open-vm-toolsを追加したところ「その他のLinux 6.x 以降(64ビット)」だ、と言われました。

初回ログイン時のユーザ情報は「Creating and Configuring a Cluster」を参照

AHVは「root」「nutanix/4u」
CVMは「nutanix」「nutanix/4u」
Web UIは「admin」「nutanix/4u」初回ログイン時にパスワード変更が求められるが制限がきつめ

Web初回ログイン時にNEXTアカウントを要求されるが、Nutanix NEXTのMy profileで表示されるユーザ名ではなく「メールアドレス」を入力する

その他メモ

LCMの動作にアクセスできるNTPサーバは必須

初期設定ではNTPサーバとして0.pool.ntp.org と 1.pool.ntp.org が登録されている

これらにアクセスできないとLCMでのInventoryが失敗する

error alert
Lcm prechecks detected 1 issue that would cause upgrade failures.

Check 'test_ntp_server_reachability' failed: Failure reason: Cannot upgrade if the configured NTP server(s): ['0.pool.ntp.org', '1.pool.ntp.org'] are not reachable. For details read article 6401

設定してあるのに上記エラーが出ているというときに、Hypervisor側でNTP動作状況確認のコマンドを実行

[root@NTNX-4bc9a811-A ~]# chronyc -n sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 163.5.56.11                   0   9     0     -     +0ns[   +0ns] +/-    0ns
^? 109.61.109.140                0   9     0     -     +0ns[   +0ns] +/-    0ns
^? 192.168.1.1                   0   8     0     -     +0ns[   +0ns] +/-    0ns
[root@NTNX-4bc9a811-A ~]#

hypervisor階層では問題無く動作している模様

CVMの方を確認すると、設定されていないように見える

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo chronyc -n sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

実際設定ファイルにもない

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo cat /etc/chrony.conf
# Auto generated by ChronyConfig on Thu Jul  9 01:28:04 2026

local stratum 10
driftfile /var/lib/chrony/drift
maxdistance 16.0
makestep 1.0 3
rtcsync
allow 0.0.0.0/0
allow 127.0.0.1
allow ::/0
allow ::1
leapsectz right/UTC
cmdport 0
logdir /var/log/chrony
log measurements statistics tracking
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~

hypervisorの方の /etc/chrony.confを確認すると、こちらにはNTPサーバ設定はある

[root@NTNX-4bc9a811-A ~]# cat /etc/chrony.conf
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Allow NTP client access from local network.
#allow 192.168.0.0/16

# Serve time even if not synchronized to a time source.
#local stratum 10

# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking
port 0
cmdport 0
server 1.pool.ntp.org maxpoll 10 iburst
server 0.pool.ntp.org maxpoll 10 iburst
server 192.168.1.1 maxpoll 10 iburst
[root@NTNX-4bc9a811-A ~]#

ncli clusterコマンドでNTPサーバ一覧を取得すると、サーバ群は登録されていることになっている

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ ncli cluster get-ntp-servers

    NTP Servers               : 0.pool.ntp.org, 1.pool.ntp.org, 192.168.1.1
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

CVM内部からNTPサーバ群へのNTPポート123へのアクセスは成功する

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ nc -vz -u 192.168.1.1 123
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.1.1:123.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.02 seconds.
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ nc -vz -u 163.5.56.11 123
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 163.5.56.11:123.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ nc -vz -u 109.61.109.140 123
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 109.61.109.140:123.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.02 seconds.
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

とりあえずCVMの/etc/chrony.confを直接編集してみた

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo vi /etc/chrony.conf
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo cat /etc/chrony.conf
# Auto generated by ChronyConfig on Thu Jul  9 01:28:04 2026

local stratum 10
driftfile /var/lib/chrony/drift
maxdistance 16.0
makestep 1.0 3
rtcsync
allow 0.0.0.0/0
allow 127.0.0.1
allow ::/0
allow ::1
leapsectz right/UTC
cmdport 0
logdir /var/log/chrony
log measurements statistics tracking
server 192.168.1.1 maxpoll 10 iburst
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo systemctl restart chronyd
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo chronyc -n sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 192.168.1.1                   0   6     0     -     +0ns[   +0ns] +/-    0ns
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

とりあえずNTPを使えるようにした

CLIでcheck_ntpを実行

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ ncc health_checks network_checks check_ntp

####################################################
# TIMESTAMP : Thu Jul 09 01:52:10 2026 (UTC +0000) #
####################################################
Cluster Name: cvm
Cluster Id: 3772327690115644291
Cluster UUID: 00064e84-58d6-fd69-345a-000c29b67b83
Cluster Version: 6.8.1
NCC Version: 5.0.1-83db8d0f
    CVM ID(Svmid)            : 2
    CVM external IP          : 192.168.1.14
    Hypervisor IP            : 192.168.1.13
    Hypervisor version       : Nutanix 20230302.101026
    Node serial              : 61e640f9-e1fe-4ba3-a4cc-8c2384c95c9a
    Model                    : CommunityEdition
    Node Position            : A
    Block S/N                : 4bc9a811


Running : health_checks network_checks check_ntp
[==================================================] 100%
/health_checks/network_checks/check_ntp                                              [ WARN ]
---------------------------------------------------------------------------------------------+

Detailed information for check_ntp:
Node 192.168.1.14:
WARN: NTP servers configured on CVM (['192.168.1.1']) differ from those configured in the cluster (['0.pool.ntp.org', '1.pool.ntp.org', '192.168.1.1']).
WARN: The host (192.168.1.13) is not synchronizing with any NTP server. This might occur if none of the configured NTP servers are available or you are currently experiencing network instability determined by the high offset/high jitter.
Refer to KB 4519 (http://portal.nutanix.com/kb/4519) for details on check_ntp or Recheck with: ncc health_checks network_checks check_ntp --cvm_list=192.168.1.14
+-----------------------+
| State         | Count |
+-----------------------+
| Warning       | 1     |
| Total Plugins | 1     |
+-----------------------+
Plugin output written to /home/nutanix/data/logs/ncc-output-latest.log
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

NTPサーバ群の数が違うのでダメか

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo vi /etc/chrony.conf
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo cat /etc/chrony.conf
# Auto generated by ChronyConfig on Thu Jul  9 01:28:04 2026

local stratum 10
driftfile /var/lib/chrony/drift
maxdistance 16.0
makestep 1.0 3
rtcsync
allow 0.0.0.0/0
allow 127.0.0.1
allow ::/0
allow ::1
leapsectz right/UTC
cmdport 0
logdir /var/log/chrony
log measurements statistics tracking
server 192.168.1.1 maxpoll 10 iburst
server 1.pool.ntp.org maxpoll 10 iburst
server 0.pool.ntp.org maxpoll 10 iburst
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo systemctl restart chronyd
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo chronyc -n sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^? 192.168.1.1                   0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 122.215.240.52                0   6     0     -     +0ns[   +0ns] +/-    0ns
^? 46.250.253.227                0   6     0     -     +0ns[   +0ns] +/-    0ns
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

再チェック

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ ncc health_checks network_checks check_ntp

####################################################
# TIMESTAMP : Thu Jul 09 01:57:28 2026 (UTC +0000) #
####################################################
Cluster Name: cvm
Cluster Id: 3772327690115644291
Cluster UUID: 00064e84-58d6-fd69-345a-000c29b67b83
Cluster Version: 6.8.1
NCC Version: 5.0.1-83db8d0f
    CVM ID(Svmid)            : 2
    CVM external IP          : 192.168.1.14
    Hypervisor IP            : 192.168.1.13
    Hypervisor version       : Nutanix 20230302.101026
    Node serial              : 61e640f9-e1fe-4ba3-a4cc-8c2384c95c9a
    Model                    : CommunityEdition
    Node Position            : A
    Block S/N                : 4bc9a811


Running : health_checks network_checks check_ntp
[==================================================] 100%
/health_checks/network_checks/check_ntp                                              [ ERR  ]
---------------------------------------------------------------------------------------------+

Detailed information for check_ntp:
Node 192.168.1.14:
ERR : node (service_vm_id: 2) : NTP synchronized to server which is neither in the cluster nor in the list of allowed NTP servers
WARN: The host (192.168.1.13) is not synchronizing with any NTP server. This might occur if none of the configured NTP servers are available or you are currently experiencing network instability determined by the high offset/high jitter.
Refer to KB 4519 (http://portal.nutanix.com/kb/4519) for details on check_ntp or Recheck with: ncc health_checks network_checks check_ntp --cvm_list=192.168.1.14

One or more plugins generated ERROR as there were insufficient data to validate results. Please resolve other reported issues and re-run the health checks.
+-----------------------+
| State         | Count |
+-----------------------+
| Error         | 1     |
| Total Plugins | 1     |
+-----------------------+
Plugin output written to /home/nutanix/data/logs/ncc-output-latest.log
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

KB-16363 を参照してみると、「sudo chronyc tracking」を実行して「Reference ID」のところにNTPサーバ名が出てるか確認、とある・・・ない

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo chronyc tracking
Reference ID    : 7F7F0101 ()
Stratum         : 10
Ref time (UTC)  : Thu Jul 09 02:06:19 2026
System time     : 0.000000004 seconds slow of NTP time
Last offset     : +0.000000000 seconds
RMS offset      : 0.000000000 seconds
Frequency       : 5.919 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 0.000000000 seconds
Root dispersion : 0.000000000 seconds
Update interval : 0.0 seconds
Leap status     : Normal
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

[root@NTNX-4bc9a811-A ~]# chronyc tracking
Reference ID    : 00000000 ()
Stratum         : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time     : 0.000000000 seconds slow of NTP time
Last offset     : +0.000000000 seconds
RMS offset      : 0.000000000 seconds
Frequency       : 5.788 ppm slow
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 1.000000000 seconds
Root dispersion : 1.000000000 seconds
Update interval : 0.0 seconds
Leap status     : Not synchronised
[root@NTNX-4bc9a811-A ~]#

いろいろ試行していたところ、結局のところopenwrtで提供しようとしていたNTPに問題が出ていたようなので、別のLinuxでchronydによるNTPサーバを立てて見たところ、そちらではなんとかなった

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ ncc health_checks network_checks check_ntp --cvm_list=192.168.1.14

####################################################
# TIMESTAMP : Thu Jul 09 06:07:56 2026 (UTC +0000) #
####################################################
Cluster Name: cvm
Cluster Id: 3772327690115644291
Cluster UUID: 00064e84-58d6-fd69-345a-000c29b67b83
Cluster Version: 6.8.1
NCC Version: 5.0.1-83db8d0f
    CVM ID(Svmid)            : 2
    CVM external IP          : 192.168.1.14
    Hypervisor IP            : 192.168.1.13
    Hypervisor version       : Nutanix 20230302.101026
    Node serial              : 61e640f9-e1fe-4ba3-a4cc-8c2384c95c9a
    Model                    : CommunityEdition
    Node Position            : A
    Block S/N                : 4bc9a811


Running : health_checks network_checks check_ntp
[==================================================] 100%
/health_checks/network_checks/check_ntp                                              [ WARN ]
---------------------------------------------------------------------------------------------+

Detailed information for check_ntp:
Node 192.168.1.14:
WARN: NTP servers configured on CVM (['0.pool.ntp.org', '192.168.1.1', '1.pool.ntp.org']) differ from those configured in the cluster (['0.pool.ntp.org', '1.pool.ntp.org', '192.168.1.1', '192.168.1.10']).
Refer to KB 4519 (http://portal.nutanix.com/kb/4519) for details on check_ntp or Recheck with: ncc health_checks network_checks check_ntp --cvm_list=192.168.1.14
+-----------------------+
| State         | Count |
+-----------------------+
| Warning       | 1     |
| Total Plugins | 1     |
+-----------------------+
Plugin output written to /home/nutanix/data/logs/ncc-output-latest.log
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

CVM内の/etc/chrony.confも書き換わっていた

nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$ sudo cat /etc/chrony.conf
# Auto generated by ChronyConfig on Thu Jul  9 06:11:50 2026

pool 0.pool.ntp.org iburst maxpoll 10
server 192.168.1.10 iburst maxpoll 10
pool 1.pool.ntp.org iburst maxpoll 10
server 192.168.1.1 iburst maxpoll 10
local stratum 10
driftfile /var/lib/chrony/drift
maxdistance 16.0
makestep 1.0 3
rtcsync
allow 0.0.0.0/0
allow 127.0.0.1
allow ::/0
allow ::1
leapsectz right/UTC
cmdport 0
logdir /var/log/chrony
log measurements statistics tracking
nutanix@NTNX-4bc9a811-A-CVM:192.168.1.14:~$

HPE VMEのクラスタ制御関連のメモ

HPE VMEクラスタを作った場合、実際にクラスタ状態を制御してるのはなんなのか、というメモ

問題があった時に遭遇したものを書いてるだけなので、他にも仕組みがあるかもしれない

GFS2ファイルシステム周り

複数サーバでGFS2ファイルシステムを使う場合、制御に pacemaker+corosyncを利用していた。

サーバ3台構成で組んだ場合に、GFS2構築後に、停止状態から起動させると、しばらくGFS2ファイルシステムがマウントされていない状態になっている

これはpacemaker+corosyncにより所属サーバの過半数から得票がとれなければ正常に動作していないと判断され、GFS2ファイルシステムをマウントしない、ということから来ている。

GFS2ファイルシステムのマウント制御について確認する場合、まずは「sudo pcs status」コマンドを実行して、確認をする。下記は3サーバ構成で全て起動している場合のもの

pcuser@hpevme1:~$ sudo pcs status
Cluster name: 2rouf0rh0q94m4i
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: hpevme2 (version 2.1.6-6fdc9deea29) - partition with quorum
  * Last updated: Wed Mar  4 10:57:03 2026 on hpevme1
  * Last change:  Fri Feb 27 17:56:49 2026 by root via cibadmin on hpevme3
  * 3 nodes configured
  * 7 resource instances configured

Node List:
  * Online: [ hpevme1 hpevme2 hpevme3 ]

Full List of Resources:
  * Clone Set: dlm-clone [dlm]:
    * Started: [ hpevme1 hpevme2 hpevme3 ]
  * hpevm_gfs2_scsi     (stonith:fence_scsi_hpevm):      Started hpevme1
  * Clone Set: gfs2datastore_1ffa9-clone [gfs2datastore_1ffa9]:
    * Started: [ hpevme1 hpevme2 hpevme3 ]

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
pcuser@hpevme1:~$

“Daemon Status”に表示されているようにcorosync, pacemakerが関連していることがわかる

「sudo pcs status –full」を実行すると詳細表示

pcuser@hpevme1:~$ sudo pcs status --full
Cluster name: 2rouf0rh0q94m4i
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: hpevme2 (2) (version 2.1.6-6fdc9deea29) - partition with quorum
  * Last updated: Wed Mar  4 10:57:07 2026 on hpevme1
  * Last change:  Fri Feb 27 17:56:49 2026 by root via cibadmin on hpevme3
  * 3 nodes configured
  * 7 resource instances configured

Node List:
  * Node hpevme1 (1): online, feature set 3.17.4
  * Node hpevme2 (2): online, feature set 3.17.4
  * Node hpevme3 (3): online, feature set 3.17.4

Full List of Resources:
  * Clone Set: dlm-clone [dlm]:
    * dlm       (ocf:pacemaker:controld):        Started hpevme2
    * dlm       (ocf:pacemaker:controld):        Started hpevme1
    * dlm       (ocf:pacemaker:controld):        Started hpevme3
  * hpevm_gfs2_scsi     (stonith:fence_scsi_hpevm):      Started hpevme1
  * Clone Set: gfs2datastore_1ffa9-clone [gfs2datastore_1ffa9]:
    * gfs2datastore_1ffa9       (ocf:heartbeat:Filesystem):      Started hpevme2
    * gfs2datastore_1ffa9       (ocf:heartbeat:Filesystem):      Started hpevme1
    * gfs2datastore_1ffa9       (ocf:heartbeat:Filesystem):      Started hpevme3

Migration Summary:

Fencing History:
  * unfencing of hpevme2 successful: delegate=hpevme2, client=pacemaker-fenced.2051, origin=hpevme3, completed='2026-03-04 10:50:33.927998 +09:00'
  * unfencing of hpevme1 successful: delegate=hpevme1, client=pacemaker-controld.1993, origin=hpevme2, completed='2026-03-04 10:50:33.860998 +09:00'
  * unfencing of hpevme3 successful: delegate=hpevme3, client=pacemaker-controld.1993, origin=hpevme2, completed='2026-03-04 10:50:33.718998 +09:00'

Tickets:

PCSD Status:
  hpevme1: Online
  hpevme2: Online
  hpevme3: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
pcuser@hpevme1:~$

pcsコマンドの下層に、corosyncがある、という構造になっているので、corosync側のステータスを確認することもできる

過半数をどうやって調査しているか、という部分はcorosyncのquorumで行っているので、そのステータスを確認するために「sudo corosync-quorumtool -s」を実行

pcuser@hpevme1:~$ sudo corosync-quorumtool -s
Quorum information
------------------
Date:             Wed Mar  4 11:04:48 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.3d
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
         1          1 hpevme1 (local)
         2          1 hpevme2
         3          1 hpevme3
pcuser@hpevme1:~$

corosyncで行う各サーバ間の通信がどのIPで行われているかは「sudo corosync-cfgtool -n」

pcuser@hpevme1:~$ sudo corosync-cfgtool -n
Local node ID 1, transport knet
nodeid: 2 reachable
   LINK: 0 udp (192.168.1.51->192.168.1.52) enabled connected mtu: 1397

nodeid: 3 reachable
   LINK: 0 udp (192.168.1.51->192.168.1.53) enabled connected mtu: 1397

pcuser@hpevme1:~$ sudo corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 192.168.1.51
        status:
                nodeid:          1:     localhost
                nodeid:          2:     connected
                nodeid:          3:     connected
pcuser@hpevme1:~$

なお、上記例では「192.168.1.0/24」のネットワークを使っているが、このIPアドレス帯はマネージメント用として各物理サーバおよびHPE VME Managerサーバに使用しているものとなる。(Webアクセスや、sshアクセスで使うもの)

corosync用のネットワークを別のサブネットに設定する、といった設定GUIはv8.0.13でもなかったような・・・


サーバ1台止めた場合のコマンド出力

「sudo pcs status」

pcuser@hpevme2:~$ sudo pcs status
[sudo] password for pcuser:
Cluster name: 2rouf0rh0q94m4i
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: hpevme2 (version 2.1.6-6fdc9deea29) - partition with quorum
  * Last updated: Wed Mar  4 13:11:33 2026 on hpevme2
  * Last change:  Fri Feb 27 17:56:49 2026 by root via cibadmin on hpevme3
  * 3 nodes configured
  * 7 resource instances configured

Node List:
  * Online: [ hpevme2 hpevme3 ]
  * OFFLINE: [ hpevme1 ]

Full List of Resources:
  * Clone Set: dlm-clone [dlm]:
    * Started: [ hpevme2 hpevme3 ]
    * Stopped: [ hpevme1 ]
  * hpevm_gfs2_scsi     (stonith:fence_scsi_hpevm):      Started hpevme2
  * Clone Set: gfs2datastore_1ffa9-clone [gfs2datastore_1ffa9]:
    * Started: [ hpevme2 hpevme3 ]
    * Stopped: [ hpevme1 ]

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
pcuser@hpevme2:~$

「sudo pcs status –full」

pcuser@hpevme2:~$ sudo pcs status --full
Cluster name: 2rouf0rh0q94m4i
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: hpevme2 (2) (version 2.1.6-6fdc9deea29) - partition with quorum
  * Last updated: Wed Mar  4 13:12:26 2026 on hpevme2
  * Last change:  Fri Feb 27 17:56:49 2026 by root via cibadmin on hpevme3
  * 3 nodes configured
  * 7 resource instances configured

Node List:
  * Node hpevme1 (1): OFFLINE
  * Node hpevme2 (2): online, feature set 3.17.4
  * Node hpevme3 (3): online, feature set 3.17.4

Full List of Resources:
  * Clone Set: dlm-clone [dlm]:
    * dlm       (ocf:pacemaker:controld):        Started hpevme2
    * dlm       (ocf:pacemaker:controld):        Started hpevme3
    * dlm       (ocf:pacemaker:controld):        Stopped
  * hpevm_gfs2_scsi     (stonith:fence_scsi_hpevm):      Started hpevme2
  * Clone Set: gfs2datastore_1ffa9-clone [gfs2datastore_1ffa9]:
    * gfs2datastore_1ffa9       (ocf:heartbeat:Filesystem):      Started hpevme2
    * gfs2datastore_1ffa9       (ocf:heartbeat:Filesystem):      Started hpevme3
    * gfs2datastore_1ffa9       (ocf:heartbeat:Filesystem):      Stopped

Migration Summary:

Fencing History:
  * reboot of hpevme1 successful: delegate=hpevme2, client=stonith-api.30408, origin=hpevme2, completed='2026-03-04 13:05:43.082713 +09:00'
  * unfencing of hpevme2 successful: delegate=hpevme2, client=pacemaker-fenced.2051, origin=hpevme3, completed='2026-03-04 10:50:33.986998 +09:00'
  * unfencing of hpevme1 successful: delegate=hpevme1, client=pacemaker-controld.1993, origin=hpevme2, completed='2026-03-04 10:50:33.916998 +09:00'
  * unfencing of hpevme3 successful: delegate=hpevme3, client=pacemaker-controld.1993, origin=hpevme2, completed='2026-03-04 10:50:33.773998 +09:00'

Tickets:

PCSD Status:
  hpevme1: Offline
  hpevme2: Online
  hpevme3: Online

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled
pcuser@hpevme2:~$

「sudo corosync-quorumtool -s」

pcuser@hpevme2:~$ sudo corosync-quorumtool -s
Quorum information
------------------
Date:             Wed Mar  4 13:13:02 2026
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          2
Ring ID:          2.41
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
         2          1 hpevme2 (local)
         3          1 hpevme3
pcuser@hpevme2:~$

「sudo corosync-cfgtool -n」

pcuser@hpevme2:~$ sudo corosync-cfgtool -n
Local node ID 2, transport knet
nodeid: 3 reachable
   LINK: 0 udp (192.168.1.52->192.168.1.53) enabled connected mtu: 1397

pcuser@hpevme2:~$ sudo corosync-cfgtool -s
Local node ID 2, transport knet
LINK ID 0 udp
        addr    = 192.168.1.52
        status:
                nodeid:          1:     disconnected
                nodeid:          2:     localhost
                nodeid:          3:     connected
pcuser@hpevme2:~$

HPE VMEでのiSCSIストレージ登録とGFS2データストア作成

HPE VME ver 8.0.13環境を作ってみたところ、以前と比べてGFS2データストア作成プロセスが改善されていたのでメモ

2026/06/17 HPE VME ver 9.0.0でいくつか変わったところがあるので修正

(0) HPE VME側でInitiatorName名を確認

[インフラストラクチャ]-[コンピュート]でホスト一覧を表示

各ホストのリンクをクリックし[概要]タブを開くと「iSCSI Initiator Name」を確認することができる

(1) HPE VME側でiSCSIターゲットIP登録

[インフラストラクチャ]-[クラスター]で該当クラスタを選択し、[ストレージ]-[iSCSI]にてiSCSIストレージのターゲットIPアドレスを登録

これを行うと、しばらくすると各サーバの /etc/iscsi/initiatorname.iscsi  の InitiatorName に設定されている名前で、iSCSIストレージに対してアクセスが実施される

(2) iSCSIストレージ側でInitiatorNameを登録

iSCSIストレージ側で、各サーバの /etc/iscsi/initiatorname.iscsi  の InitiatorName の名前を登録し、アクセスを許可する

NetAppの例

しばらく待っても接続ステータスが変更されない場合は、該当のVMEサーバにログインして「sudo iscsiadm -m session –rescan」を実行してスキャンを行う

pcuser@hpevme1:~$ sudo iscsiadm -m session --rescan
Rescanning session [sid: 1, target: iqn.1992-08.com.netapp:sn.588844e7ec3411f0a4bd000c292a75e7:vs.8, portal: 192.168.3.35,3260]
Rescanning session [sid: 2, target: iqn.1992-08.com.netapp:sn.588844e7ec3411f0a4bd000c292a75e7:vs.8, portal: 192.168.2.35,3260]
pcuser@hpevme1:~$

(3) HPE VME側でディスクが認識されているか確認

[インフラストラクチャ]-[クラスター]で該当クラスタを選択し、[ストレージ]-[データストア]にて「追加」をクリックして表示される「データストアの追加」にて

「Type:GFS2 Pool (Global File System 2)」を選択し、「BLOCK DEVICE」の選択を確認する

上記の様に「/dev/mapper/~」というディスクが認識されていれば、マルチパスで認識されているiSCSIディスクとなる。

mapperというデバイスが認識されていない場合、iSCSIマルチパスが動作しているかを確認する

まずはディスクデバイスが認識されているかを「sudo iscsiadm -m session -P 3」を実行して、「Attached SCSI devices:」の後に「scsi ??? Channel 00 ID 0 Lun :1」といった形でディスクが認識されていることを確認

pcuser@hpevme1:~$ sudo iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 2.1.9
Target: iqn.1992-08.com.netapp:sn.588844e7ec3411f0a4bd000c292a75e7:vs.8 (non-flash)
        Current Portal: 192.168.3.35:3260,1028
        Persistent Portal: 192.168.3.35:3260,1028
                **********
                Interface:
                **********
                Iface Name: default
                Iface Transport: tcp
                Iface Initiatorname: iqn.2024-12.com.hpe:hpevme1:42939
                Iface IPaddress: 192.168.3.51
                Iface HWaddress: default
                Iface Netdev: default
                SID: 1
                iSCSI Connection State: LOGGED IN
                iSCSI Session State: LOGGED_IN
                Internal iscsid Session State: NO CHANGE
                *********
                Timeouts:
                *********
                Recovery Timeout: 5
                Target Reset Timeout: 30
                LUN Reset Timeout: 30
                Abort Timeout: 15
                *****
                CHAP:
                *****
                username: <empty>
                password: ********
                username_in: <empty>
                password_in: ********
                ************************
                Negotiated iSCSI params:
                ************************
                HeaderDigest: None
                DataDigest: None
                MaxRecvDataSegmentLength: 262144
                MaxXmitDataSegmentLength: 65536
                FirstBurstLength: 65536
                MaxBurstLength: 1048576
                ImmediateData: Yes
                InitialR2T: Yes
                MaxOutstandingR2T: 1
                ************************
                Attached SCSI devices:
                ************************
                Host Number: 33 State: running
                scsi33 Channel 00 Id 0 Lun: 1
                        Attached scsi disk sdc          State: running
        Current Portal: 192.168.2.35:3260,1027
        Persistent Portal: 192.168.2.35:3260,1027
                **********
                Interface:
                **********
                Iface Name: default
                Iface Transport: tcp
                Iface Initiatorname: iqn.2024-12.com.hpe:hpevme1:42939
                Iface IPaddress: 192.168.2.51
                Iface HWaddress: default
                Iface Netdev: default
                SID: 2
                iSCSI Connection State: LOGGED IN
                iSCSI Session State: LOGGED_IN
                Internal iscsid Session State: NO CHANGE
                *********
                Timeouts:
                *********
                Recovery Timeout: 5
                Target Reset Timeout: 30
                LUN Reset Timeout: 30
                Abort Timeout: 15
                *****
                CHAP:
                *****
                username: <empty>
                password: ********
                username_in: <empty>
                password_in: ********
                ************************
                Negotiated iSCSI params:
                ************************
                HeaderDigest: None
                DataDigest: None
                MaxRecvDataSegmentLength: 262144
                MaxXmitDataSegmentLength: 65536
                FirstBurstLength: 65536
                MaxBurstLength: 1048576
                ImmediateData: Yes
                InitialR2T: Yes
                MaxOutstandingR2T: 1
                ************************
                Attached SCSI devices:
                ************************
                Host Number: 34 State: running
                scsi34 Channel 00 Id 0 Lun: 1
                        Attached scsi disk sdb          State: running
pcuser@hpevme1:~$

これが認識されていないようであればiSCSIストレージ側のLUNマッピング設定やイニシエータのマッピング設定を見直す

マルチパスが動作しているかを確認する場合は「sudo multipath -ll」を実行して確認

pcuser@hpevme1:~$ sudo multipath -ll
3600a09807770457a795d5a554c634a58 dm-1 NETAPP,LUN C-Mode
size=100G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 34:0:0:1 sdb 8:16 active ready running
  `- 33:0:0:1 sdc 8:32 active ready running
pcuser@hpevme1:~$

上記の様に、ツリーが表示されていればマルチパスが動作している

以前のバージョンではmultipathの設定を手動で行っていたが、ver 8.0.13では不要だった。

(4) HPE VME側でGFS2ファイルシステムの作成

[インフラストラクチャ]-[クラスター]で該当クラスタを選択し、[ストレージ]-[データストア]にて「追加」をクリックして表示される「データストアの追加」にて

「Type:GFS2 Pool (Global File System 2)」を選択し、「BLOCK DEVICE」の選択/dev/mapper/で始まるマルチパスデバイスを指定

しばらくファイルシステム作成が実施される

ver8.0.13時点ではファイルシステムが完成しても通知はなかったので、リロードなどして表示を更新する

これでGFS2データストアは作成できた。

Ryzen 5 3500U環境でnested esxiを作ろうとしたらディスクが見えない

GMKtec NucBox G10 mini にESXi8 Freeをインストールして使っているんだけど、ESXi 7からESXi 8へのバージョンアップ手順を確認したくて、nested esxi環境を作ろうとした・・・

仮想マシンを[その他]-[VMware ESXi 7.x]で作成して

仮想マシンのCPU設定は詳細を開いて「ハードウェア仮想化」「IOMMU」「パフォーマンスカウンター」にチェックを入れて

SCSIコントローラは「VMware Paravirtual(PVSCSI)」で、ディスクはscsi0 で接続して作成

これでインストールを進めると選択できるディスクがない

この状態で、AlmaLinux 9.7のISOで起動すると普通にインストールできて起動してくる。

いろいろ悩んだ結果・・・

「IOMMU」と「パフォーマンスカウンター」のチェックを外してみたところ

ディスクが見えるようになりました

Intel N97環境でNested ESXiをインストールした際は、IOMMIとパフォーマンスカウンターにチェックが入っていてもディスクを認識してくれたのに、Ryzen 5 3500U環境ではダメなようです。

vSphere上の仮想マシンに物理サーバのBIOS情報を見せる

vSphere上の仮想マシンは、vSphere仮想基盤が提供している仮想のBIOS情報を参照している

この状態だと、物理サーバのBIOS内にあるキー情報などが読み取れないため、OEM版Windowsライセンスの認証が行えない。

これを解消するために「SMBIOS.reflectHost=TRUE」という設定を入れる、という話がある

DELLでも「Dell PowerEdgeシステムでROKメディアを使用するためのハイパーバイザーを準備する」にて vmxファイルにsmbios.reflectHost = TRUE を追加する、と記載している

他にBIOS情報を仮想マシンに反映するための設定ってあるのか?と探してみると「How to Pass Host Hardware Information to a VMware Workstation VM」に下記の様な記述が

I powered off the VM and used Notepad to add these three lines to the end of the VMX file:

SMBIOS.reflectHost = “TRUE”
SMBIOS.noOEMStrings = “TRUE”
smbios.addHostVendor = “TRUE”

SMBIOS.noOEMStrings 設定について調べると、例えば富士通/エフサスの出している「VMware vSphere 9 ソフトウェア説明書」の”PRIMERGY添付のWindows OS メディアの使用」の項目に、smbios.reflectHost=TRUE と SMBIOS.noOEMStrings=TRUE を追加する、と記載している。

他に調べると https://github.com/magliocchetti/SafeExamPwner/blob/main/AddToYourVmxFile.txt を発見

SMBIOS.reflectHost = "TRUE"
SMBIOS.assettag = "INTEL"
SMBIOS.useShortSerialNumber = "TRUE"
SMBIOS.noOEMStrings = "TRUE"
SMBIOS.addHostVendor = "TRUE"

これらをTRUE/FALSE設定していって状況を確認

lshwコマンドの出力結果

標準状態はコレ

localhost.localdomain
    description: Computer
    product: VMware20,1
    vendor: VMware, Inc.
    version: None
    serial: VMware-56 4d e4 49 78 d4 97 14-30 0a 2d e4 84 66 f9 db

SMBIOS.reflectHost = “TRUE” だけを設定

localhost.localdomain
    description: Computer
    product: NucBox_G10
    vendor: GMKtec
    version: None
    serial: Default string

注:GMKtec NucBox_G10 にはシリアルがちゃんと設定されていないのでこんな値になっている

SMBIOS.useShortSerialNumber = “TRUE”だけを設定

localhost.localdomain
    description: Computer
    product: VMware20,1
    vendor: VMware, Inc.
    version: None
    serial: VMWVk3kSXjUlxQwCi3khGb52w

SMBIOS.reflectHost = “TRUE” と SMBIOS.useShortSerialNumber = “TRUE” を設定

localhost.localdomain
    description: Computer
    product: NucBox_G10
    vendor: GMKtec
    version: None
    serial: Default string

このことから「SMBIOS.useShortSerialNumber」はVMwareが生成するserialに関する設定であるため、SMBIOS.reflectHost = “TRUE” を設定した際には効果がないと判断できる

SMBIOS.noOEMStrings , smbios.addHostVendor, SMBIOS.assettag については、試験した環境では lshw 上で有意な変化が見られなかった。(一部のUSBバスの番号が変わったりしたけど)

結論としては、基本的には「SMBIOS.reflectHost = “TRUE” 」を設定するだけで問題ない、ということになるかと思う


2026/02/20追記

ESXiをインストールする時にいろいろトラブルがあった影響で知った「localcli hardware platform get」コマンドで関連する情報が見れると知って試してみた

標準状態

SMBIOS.assettag = “TEST”だけ設定すると、「BIOS Asset Tag」に設定した文字列が入る

SMBIOS.noOEMStrings = “TRUE”とSMBIOS.assettag = “TEST”を設定では、変化無し

SMBIOS.noOEMStrings = “TRUE”、SMBIOS.addHostVendor = “TRUE”、SMBIOS.assettag = “TEST”を設定でも変わらず

上記3つに SMBIOS.useShortSerialNumber = “TRUE” を追加すると、”Serial Number”の文字列が変わる

ここにSMBIOS.reflectHost=TRUEを追加すると、”Product Name”,”Vendor Name”, “Serial Number”が物理サーバ由来の値に置き換わるが、”BIOS Asset Tag”については設定値を引き継いでいる

今度は逆にいくつかFALSEに変更

SMBIOS.noOEMStrings と SMBIOS.useShortSerialNumbeをFALSEとし、SMBIOS.reflectHostとSMBIOS.addHostVendor はTRUEのままとした場合、reflectHostの設定が最も優先されているので、状況に変化がない

SMBIOS.reflectHostだけTRUE(他はfalse)としても変化はない

SMBIOS.noOEMStrings と SMBIOS.addHostVendor はESXi 7.0以降では活用されていない設定なのか?