投稿

投稿日:

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:~$

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

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

投稿日:

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

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

(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データストアは作成できた。

投稿日:

sambaで作ったActive DirectoryではGet-ADDomainコマンドなどはエラーになる

sambaで作ったActive Directoryサーバ環境で、Windows ServerからPowerShellのGet-ADDomainコマンドを実行してみたところエラーとなった

PS C:\Users\administrator.ADSAMPLE> Get-ADDomain
Get-ADDomain : Active Directory Web サービスが実行されている状態で既定のサーバーを検索することはできません。
発生場所 行:1 文字:1
+ Get-ADDomain
+ ~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (ADSAMPLE:ADDomain) [Get-ADDomain], ADServerDownException
    + FullyQualifiedErrorId : ActiveDirectoryServer:1355,Microsoft.ActiveDirectory.Management.Commands.GetADDomain

PS C:\Users\administrator.ADSAMPLE>

サーバ名を指定すればいけるかな？と「Get-ADDomain -Server サーバ名」にしてもエラー

PS C:\Users\administrator.ADSAMPLE> Get-ADDomain -Server adsample.local
Get-ADDomain : サーバーと通信できません。サーバーが存在しないか、現在ダウンしているか、サーバー上で Active Directory Web サービスが実行されていない可能性があります。
発生場所 行:1 文字:1
+ Get-ADDomain -Server adsample.local
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [Get-ADDomain], ADServerDownException
    + FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.GetADDomain

PS C:\Users\administrator.ADSAMPLE>

今度は「Active Directory Web サービスが実行されていない」ことがエラーの原因とされている。

Active Directory Web サービス について確認すると、どうやらsamba では提供されていないようだ。

2021年4月13日に作成されたsamba wikiのページ「ADWS / AD Powershell compatibility」に、「Samba does not support many of the AD PowerShell commands that manipulate AD objects,」とある

そこによると、2016年頃に「samba-adws」というPowerShellコマンドを使えるようにするプロジェクトが立ち上がって、開発中とのこと。

masterブランチの最終更新は2018年12月であるが、「garming-main」ブランチを見ると、2024年9月頃までなんかやっていたようで、それは https://github.com/GSam/samba-adws にておもに開発してたようで、それは https://github.com/GSam/samba で公開されているパッチ版で利用できるようだ

ただ、どちらにせよ、１年以上更新はされていないようだ

このため、PowerShellのActive Directory関連のコマンドレット群はsamba環境で使用できない、ということになるようだ

投稿日:

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”を設定でも変わらず

上記３つに 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以降では活用されていない設定なのか？