Intel N95搭載PCでUSB NICをつけてESXi 8.0を使った場合再起動すると通信できなくなる件の対処方法

Intel N95搭載のミニPC TRIGKEY MINI PC Key N に32GBメモリを載せたので、仮想基盤にしてみるかと、VMware ESXi 8.0の無償ライセンス版をインストールしてようと思った。

標準状態ではオンボードNICを認識してくれず、インストール不可。

手持ちのUSB NICをさしたところNICとして認めてくれたようで、ESXiのインストールが出来た。

ただ、動作が少しおかしい

再起動するとネットワーク接続ができなくなる

ESXiのコンソールでみるとIPアドレスはきちんと割り当てられている

しかし[Configure Management Network]-[Network Adapters]を確認すると、アダプタの割り当てが外れている

チェックを入れ直して設定保存するとESXi自体のネットワークが通るようになる

この設定を行うまでは、ESXiサーバから外部へのping/sshはできないし、外部からESXiのWebアクセスもできない

原因調査

Ctrl-Alt-F1でESXi shellを開いて「esxcli network vswitch standard list」で設定を取ると、再起動直後は下記で、UplinkにNICが登録されていない

[root@esxi:~] esxcli network vswitch standard list vSwitch0
   Name: vSwitch0
   Class: cswitch
   Num Ports: 2560
   Used Ports: 2
   Configured Ports: 128
   MTU: 1500
   CDP Status: listen
   Beacon Enabled: false
   Beacon Interval: 1
   Beacon Threshold: 3
   Beacon Required By:
   Uplinks:
   Portgroups: VM Network, Management Network
[root@esxi:~] 

ESXiコンソールから設定修正を行ったあとは以下に変わる

[root@esxi:~] esxcli network vswitch standard list vSwitch0
   Name: vSwitch0
   Class: cswitch
   Num Ports: 2560
   Used Ports: 4
   Configured Ports: 128
   MTU: 1500
   CDP Status: listen
   Beacon Enabled: false
   Beacon Interval: 1
   Beacon Threshold: 3
   Beacon Required By:
   Uplinks: vusb0
   Portgroups: VM Network, Management Network
[root@esxi:~] 

Uplinksが未割り当てとなったことが原因の様に見えるのでESXiコンソールからの操作の代わりに「esxcli network vswitch standard uplink add –vswitch-namevSwitch0 –uplink-name=vusb0」を実行してみたものの ネットワークがつながらず、ESXiコンソール操作を実行しなければならなかった。

ESXiコンソール操作の変更反映画面に「Configure Management Network」とあるのでvSwitchの設定だけではなくポートグループ設定周りも見直す必要があるのでは?と esxcli network vswitch standard のオプション類をいろいろ探していくと、esxcli network vswitch standard portgroup policy failover にて怪しい状況を発見

[root@esxi:~] esxcli network vswitch standard portgroup policy failover get --portgroup-name="Management Network"
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters:
   Standby Adapters:
   Unused Adapters: vusb0
   Override Vswitch Load Balancing: true
   Override Vswitch Network Failure Detection: true
   Override Vswitch Notify Switches: true
   Override Vswitch Failback: true
   Override Vswitch Uplinks: true
[root@esxi:~] esxcli network vswitch standard portgroup policy failover get --portgroup-name="VM Network"
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters:
   Standby Adapters:
   Unused Adapters: vusb0
   Override Vswitch Load Balancing: false
   Override Vswitch Network Failure Detection: false
   Override Vswitch Notify Switches: false
   Override Vswitch Failback: false
   Override Vswitch Uplinks: false
[root@esxi:~] 

「Management Network」と「VM Network」のポートグループに割り当てられているはずのvusb0が「Unused Adapters」に割り当てられている

これらを 「Active Adapters」に割り当て直せばいいのか?とCLIで設定変更を行ってみる

[root@esxi:~] esxcli network vswitch standard portgroup policy failover set --portgroup-name="Management Network" --active-uplinks=vusb0
[root@esxi:~] esxcli network vswitch standard portgroup policy failover set --portgroup-name="Management Network"
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters: vusb0
   Standby Adapters:
   Unused Adapters:
   Override Vswitch Load Balancing: true
   Override Vswitch Network Failure Detection: true
   Override Vswitch Notify Switches: true
   Override Vswitch Failback: true
   Override Vswitch Uplinks: true
[root@esxi:~] 

ポートグループManagement Networkについての設定変更でESXi上から外部ネットワークへ通信が可能となった

この状況では仮想マシンを起動しても、VM NetworkのActive Adaptersが設定されていないため外部ネットワークに接続できない。

続いてVM NetworkのUnsed Adapterについて設定変更を実施

[root@esxi:~] esxcli network vswitch standard portgroup policy failover set --portgroup-name="VM Network" --active-uplinks=vusb0
[root@esxi:~] 
   Load Balancing: srcport
   Network Failure Detection: link
   Notify Switches: true
   Failback: true
   Active Adapters: vusb0
   Standby Adapters:
   Unused Adapters:
   Override Vswitch Load Balancing: false
   Override Vswitch Network Failure Detection: false
   Override Vswitch Notify Switches: false
   Override Vswitch Failback: false
   Override Vswitch Uplinks: true
[root@esxi:~] 

この設定実行後、仮想マシンからの外部への通信も成功した

ESXi再起動後、再設定を行い、再現性があることも確認した。

ESXiのパラメータ設定で対応可能

最初は後述の「起動時にコマンドを自動実行させる方法」を使っていたのだが、unused adapterで調べ直すと usbBusFullScanOnBootEnabled パラメータを設定することで対処できる、という話を発見

ESXi 7.0 Update 2 enhancement for USB NIC only installations」の後半に書かれている

ESXiの起動時、ESXiのvSwitch設定プロセスよりあとにUSB NICの認識が行われていることで登録できない、という状態であるため、最初にUSBデバイスの認識を行う、という順序に変える、というパラメータのようである。

設定の出典を調べると現存しない VMware Flings時代の「USB Network Native Driver for ESXi」の「Persisting USB NIC Bindings」に下記の様に記載されているものだった。

Persisting USB NIC Bindings
Option 1: Run the following ESXCLI command which will enable the driver parameter to perform a full USB bus scan during startup:
esxcli system module parameters set -p “usbBusFullScanOnBootEnabled=1” -m vmkusb_nic_fling

これらの記事は古いので、ESXi 8.0 Update 3eでも該当するモジュール vmkusb_nic_fling とパラメータ usbBusFullScanOnBootEnabled があるのかを確認してみる

[root@esxi:~] esxcli system module list|grep nic
vmkusb_nic_fling                     true        true
[root@esxi:~] esxcli system module list|grep usb
vmkusb_nic_fling                     true        true
[root@esxi:~]

モジュール vmkusb_nic_fling は、ESXi 8.0でも存在している。

モジュールに対して設定できるパラメータを確認。

[root@esxi:~] esxcli system module parameters list -m vmkusb_nic_fling
Name                         Type    Value  Description
---------------------------  ------  -----  -----------
usbBusFullScanOnBootEnabled  int            Enable USB Bus full scan on system boot: 0 No (Default), 1 Yes
usbCdromPassthroughEnabled   int            Enable USB CDROM device for USB passtrough: 0 No (Default), 1 Yes
usbStorageRegisterDelaySecs  int            Delay to register cached USB storage device: Min: 0 second, Max: 600 seconds, Default: 10 seconds
vusb0_mac                    string         Persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb10_mac                   string         Persist vusb10 MAC Address: xx:xx:xx:xx:xx:xx
vusb11_mac                   string         Persist vusb11 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                    string         Persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                    string         Persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                    string         Persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                    string         Persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                    string         Persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                    string         Persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                    string         Persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
vusb8_mac                    string         Persist vusb8 MAC Address: xx:xx:xx:xx:xx:xx
vusb9_mac                    string         Persist vusb9 MAC Address: xx:xx:xx:xx:xx:xx
[root@esxi:~]

usbBusFullScanOnBootEnabled が初期値0で存在していることを確認

(“Persisting VMkernel to USB NIC mappings”に記載されている複数のUSB NICがある時に、指す場所を変えてもvusbの番号が変わらないようにするための設定も引き続きある)

現段階のesxcliでの正式オプションに修正して、「esxcli system module parameters set –module=vmkusb_nic_fling –parameter-string=”usbBusFullScanOnBootEnabled=1″」と実行する

[root@esxi:~] esxcli system module parameters set --module=vmkusb_nic_fling --parameter-string="usbBusFullScanOnBootEnabled=1"
[root@esxi:~] esxcli system module parameters list -m vmkusb_nic_fling
Name                         Type    Value  Description
---------------------------  ------  -----  -----------
usbBusFullScanOnBootEnabled  int     1      Enable USB Bus full scan on system boot: 0 No (Default), 1 Yes
usbCdromPassthroughEnabled   int            Enable USB CDROM device for USB passtrough: 0 No (Default), 1 Yes
usbStorageRegisterDelaySecs  int            Delay to register cached USB storage device: Min: 0 second, Max: 600 seconds, Default: 10 seconds
vusb0_mac                    string         Persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb10_mac                   string         Persist vusb10 MAC Address: xx:xx:xx:xx:xx:xx
vusb11_mac                   string         Persist vusb11 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                    string         Persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                    string         Persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                    string         Persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                    string         Persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                    string         Persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                    string         Persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                    string         Persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
vusb8_mac                    string         Persist vusb8 MAC Address: xx:xx:xx:xx:xx:xx
vusb9_mac                    string         Persist vusb9 MAC Address: xx:xx:xx:xx:xx:xx
[root@esxi:~]

設定後、ESXiを再起動してもネットワーク接続に問題ないことを確認した。

起動時にコマンドを自動実行させる方法

usbBusFullScanOnBootEnabled パラメータの手法を発見する前は、起動時にこれらの設定を自動的に実行するように設定して対応していた。

ESXi 5.1時代にVMware HA有効時に仮想マシンの自動起動をしたい で使用した rc.local 設定 について調べると 2025年8月更新のKB「Modifying the rc.local or local.sh file in VMware vSphere ESXi to execute commands while booting」にて、vSphere 8でも使用可能とあるため、これを使う

初期状態の /etc/rc.local.d/local.sh の内容を確認

[root@esxi:~] ls -l /etc/rc.local.d
total 32
-r-xr-xr-x    1 root     root           378 Apr  3  2025 009.vsanwitness.sh
drwxr-xr-x    1 root     root           512 Oct  3 00:25 autodeploy
-r-xr-xr-x    1 root     root          2249 Apr  3  2025 backupPrevBootLogs.py
-r-xr-xr-x    1 root     root          2071 Apr  3  2025 cleanupStatefulHost.py
-r-xr-xr-x    1 root     root          2567 Apr  3  2025 kickstart.py
-rwxr-xr-t    1 root     root           506 Apr  3  2025 local.sh
-r-xr-xr-x    1 root     root           397 Apr  3  2025 psaScrub.sh
-r-xr-xr-x    1 root     root          1190 Apr  3  2025 raiseConfigStoreVob.py
[root@esxi:~] cat /etc/rc.local.d/local.sh
#!/bin/sh ++group=host/vim/vmvisor/boot

# local configuration options

# Note: modify at your own risk!  If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading.  Changes are not supported unless under direction of
# VMware support.

# Note: This script will not be run when UEFI secure boot is enabled.

exit 0
[root@esxi:~]

今回実行したesxcliのコマンド群を追加

[root@esxi:~] vi /etc/rc.local.d/local.sh
[root@esxi:~] cat /etc/rc.local.d/local.sh
#!/bin/sh ++group=host/vim/vmvisor/boot

# local configuration options

# Note: modify at your own risk!  If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading.  Changes are not supported unless under direction of
# VMware support.

# Note: This script will not be run when UEFI secure boot is enabled.

esxcli network vswitch standard uplink add --vswitch-name=vSwitch0 --uplink-name=vusb0
esxcli network vswitch standard portgroup policy failover set --portgroup-name="Management Network" --active-uplinks=vusb0
esxcli network vswitch standard portgroup policy failover set --portgroup-name="VM Network" --active-uplinks=vusb0

exit 0
[root@esxi:~]

以前は auto-backup.sh を手動で実行する必要があったけど、2025/10/03時点のKBには記載がないが、下記で行ったように現時点でもauto-backup.shを実行しないと設定が消えてしまうと思われる。

[root@esxi:~] date
Fri Oct  3 00:57:12 UTC 2025
[root@esxi:~] ls -ltr /bootbank/
total 261895
<略>
-rwx------    1 root     root          1797 Sep 17 16:34 boot.cfg
-rwx------    1 root     root           102 Oct  3 00:25 jumpstrt.gz
-rwx------    1 root     root        266977 Oct  3 00:31 state.tgz
[root@esxi:~]

/bootbank/state.tgz が更新されていない

[root@esxi:~] auto-backup.sh
ConfigStore has been modified since the last backup
Bootbank lock is /var/lock/bootbank/f43b0450-7e4d6762-c6be-52e6552cc1f8
INFO: Successfully claimed lock file for pid 526790
Saving current state in /bootbank
Ssh configuration synced to configstore
Creating ConfigStore Backup
Locking esx.conf
Creating archive
Unlocked esx.conf
Using key ID d27fa69c-5edc-424d-bc0f-61d7966bf4d4 to encrypt
Clock updated.
Time: 00:57:21   Date: 10/03/2025   UTC
[root@esxi:~]

auto-backup.shを実行後を確認

[root@esxi:~] ls -ltr /bootbank/
total 261895
<略>
-rwx------    1 root     root          1797 Sep 17 16:34 boot.cfg
-rwx------    1 root     root           102 Oct  3 00:25 jumpstrt.gz
-rwx------    1 root     root        266974 Oct  3 00:57 state.tgz
[root@esxi:~]

/bootbank/state.tgz が更新された

更新後、ESXiを再起動してみると、ちゃんとネットワークに接続できる状態でESXiが起動することを確認できた


2025/11/03 追記

VMware flingsで配布している「USB Network Native Driver for ESXi」からvmkusb_nic_fling ドライバをインストールすると、使えるUSB NICの種類が増える

[root@esxi:/vmfs/volumes/6908722d-a37ea8a3-525a-4d150daf152f/iso] esxcli software vib install -d /vmfs/volumes/datastore1/iso/ESXi8
03-VMKUSB-NIC-FLING-76444229-component-24179899.zip
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   VIBs Installed: VMW_bootbank_vmkusb-nic-fling_1.14-2vmw.803.0.0.76444229
   VIBs Removed:
   VIBs Skipped:
   Reboot Required: true
   DPU Results:
[root@esxi:/vmfs/volumes/6908722d-a37ea8a3-525a-4d150daf152f/iso]

インストール後、再起動は必須

Surface Pro 7を買ったのでWindows 11 をインストールしてみた

秋葉原でSurface Pro 7の黒が14400円だったので買ってきた

ちゃんとした手順を踏むのであれば、”Surface の USB 回復ドライブの作成と使用“を使うのだが、あえて普通のWindows 11 24H2メディアを使ってインストールを試みた。

この場合も、Surface 用のドライバーとファームウェアをダウンロードする から 「Surface Pro 7 Drivers and Firmware」のドライバ/Firmwareセットをダウンロードすれば終わりなのだが、あえてこれを使わない場合の再インストールを行ってみた。

Windows 11 24H2 メディアのみでの再インストール手法

まず、注意点として、標準的なWindows 11 24H2メディアではSurface Pro 7のタッチパネル操作が行えないため、別途マウスを用意する必要がある。

さて、Surface Pro 7を標準的なWindows 11 24H2メディアでインストールした直後は、下記のように認識していないデバイスがある。

ただ、これらについては、下記のようにWindows Updateを実施すればすべて解消する

解消するのだが、再起動が3回必要だった。

よく見たら上記のWindows Updateで適用されているSurface Firmwareのバージョンは2025/09/30付けで単体ダウンロードが可能になってるFirmwareと同じですね

回復メディアを使用しての再インストール手法

次に、Surface Pro 7の回復メディアを作成してWindows 11 24H2のインストールを行った。

この場合は、インストール直後ですべてのデバイスは認識しているものの、Windows Updateでのドライバ更新は同様にあり、2回ぐらい再起動が必要となった。

また、ディスプレイの拡大率が200%で設定されていた。(標準メディアだと150%)

標準でインストールされているアプリが大分違っていた。

Lifebook U938/S に 32GBメモリを載せてみた

富士通 Lifebook U938/Sに32GBのメモリを載せてみたところ、オンボード4GBと合わせて36GBメモリ認識として使用できるようになった。

今回買ったのはWINTENのSO-DIMM DDR4 3200 32GBです

まあ2枚セットで買ったので、ついでにN95搭載のTRIGKEY にも載せてみて、N95の仕様上は最大メモリーサイズ16GBと書かれているのが突破できていることも確認したりした。

TRIGKEY MINI PC Key N (N95搭載)を買った

AmazonでTRIGKEYのミニPCが1万円を切ってる、というので買ってみた

15899円になぜか6000円引きのクーポンがついてきて、1万円を切ってるというもの

速やかに到着・・・

なぜか箱をくるんでいるビニールに対して技適 210-173540 というシールが貼れているという・・・

箱の中身はこんな感じ

電源ユニット内蔵なので、謎のType-C形状電源とか不要でコンパクトに使える、というのがとても良いですね

ついでに中身確認

うーん・・・M.2 SATA SSD 256GBが黒いです。

フラッシュチップの記載が何も読めません

メモリにもかかれている「LKY」というのがメーカか何かなんですかね?

起動してみましょう

F2キーでUEFIに入れました。

プレインストールのWindows 11 Proのセットアップを進めていって「slmgr /dli」を実行してWindowsのライセンス認識を確認してみます・・・

ライセンスは以下のようにVOLUME_MAKでした

なので、Amazon経由で正式なライセンスをくれ、とメッセージを送ったところ4営業日でライセンスが発行され、適用したところ OEM_DM として認識されることを確認しました。

で・・・実は、なかなかライセンスが来なかったので、ライセンスが届く前にWindowsの再インストールを行ってみたところ予想外の事態が・・・

インストール時にライセンスは自動認識されないので、Windows 11 Proを手動で選択してインストールを終わらせてみたところ、すでにRETAILで認識されていたという・・・

うーん・・・どういう状態なんですかねぇ・・・これ

とりあえずはWindows 11 Pro ライセンスがついてきて1万円を切っていた、というのは変わらないですね。

謎の真っ黒M.2 SATA SSDを確認

メーカー名なしで「NGFF 2280 256GB SSD」と認識のもの、というのは驚きです。

(NGFF 2280 は 物理的な形状のことを指している単語です)

タスクマネージャー上の認識を確認。ちゃんとIntel N95で認識されている、と

メモリはSO-DIMM DDR4 3200の8GBでした。なお、後述しますが32GBメモリが動作することも確認しました。

ディスクはメーカ、モデル名不詳のNGFF 2280 256GB SSD…まあ、256GBなので捨てちゃいましょう

プレインストールのWindows 11 Proのドライバ認識を確認・・・もちろん未認識はなし。

プレインストールソフトについて

標準でインストールされているプログラムをスタートメニューで確認すると、Intel関連がいくつか登録されていた。

次にインストールされているアプリ一覧を確認

このうち「Intel Driver and Support Assistant」がドライバの更新があると教えてくれたので、実行してみるとブラウザが開いた

開いたURLはこれ : インテル® ドライバー & サポート・アシスタント

アップデートの詳細説明は下記のURL3つ

Windows® 10 および Windows* 11 用インテル® ワイヤレス Wi-Fi ドライバー

Windows® 10 および Windows* 11 用インテル® ワイヤレス・Bluetooth®・ドライバー

Intel® Arc™ & Iris® Xe Graphics – Windows*

Window 11 再インストール実施

SSDを別のものに交換してWindows 11 Pro を再インストールしてみたところ、標準では一部デバイスが認識していない。

まずは認識していないものを確認しつつドライバを適用

PCI シンプル通信コントローラーPCI\VEN_8086&DEV_54A8&SUBSYS_72708086&REV_00\3&11583659&0&F0

Microsoft Update カタログからドライバ適用

PCI デバイス
PCI\VEN_8086&DEV_54E8&SUBSYS_72708086&REV_00\3&11583659&0&A8

Microsoft Update カタログ からドライバ適用

PCI デバイス
PCI\VEN_8086&DEV_54E9&SUBSYS_72708086&REV_00\3&11583659&0&A9

Microsoft Update カタログのドライバ適用

PCI デバイス
PCI\VEN_8086&DEV_54AB&SUBSYS_72708086&REV_00\3&11583659&0&F3

Microsoft Update カタログ

ここからのACPIの不明なデバイス3つを解消するにはMicrosoft Update Catalogで探す前にIntelページからドライバを入手する必要があった。

不明なデバイス
ACPI\INTC1023\2&DABA3FF&0

不明なデバイス
ACPI\INTC1057\2&DABA3FF&0

不明なデバイス
ACPI\INTC1024\2&DABA3FF&0

まずは、下記からINFをインストールすると、不明なデバイスが2つ消える。

ユーザーサポート インテル® Chipset Software Installation Utility

残ったものについてはMicrosoft Update Catalogで捜索する

Microsoft Update カタログ

これでデバイスがすべて認識した。

再インストール後にアプリ一覧を比較すると、プレインストールに存在していたが、再インストール後にないもので、システムの動作に影響がありそうなものをあげると以下のものになる。

Intel(R) Arc Software & Drivers

Intel(R) Computing Improvement Program

Intel Arc Control

Intel Driver & Support Assistant

Intel Unison (なお、Unisonの提供は 2025/06で終了済)

Realtek High Definition Audio Driver

インテル グラフィクス・コマンド・センター

インテル シリアル IO

インテル マネージメント・エンジン・コンポーネント

逆に再インストールで追加されているものは以下の2つ。まあ、copilotなので無視。

Copilot

Microsoft 365 Copilot

足らないアプリケーションについて、まずは「インテル® ドライバー & サポート・アシスタント」をインストールして、実行

実行するとWifi/Bluetooth/グラフィックスドライバの更新がインストールされた。

リストを確認すると、更新と同時に”Intel(R) Computing Improvement Program” と “oneAPI Level Zero”がインストールされていた。どちらもGPUコンピューティング関連のソフトウェアと思われる。

プレインストールにあった「Intel ARC Control」は古いバージョンで、現在は Intel Graphics Softwareに統合されたみたいなので不要の模様(単体ではダウンロードできない)

インテル® グラフィックス・コマンド・センターはMicrosoft Storeからインストール

Realtek High Definition Audio Driver, インテル シリアル IO, インテル マネージメント・エンジン・コンポーネントについてはドライバが適用されてるのでわざわざ追加する必要はない。

これで、プレインストール状態と同等になり問題はないと思われる。

カスタマイズ

とりあえず標準で載っていたWifi 802.11ac/Bluetooth 5.0のRTL8821CE は見た目が怪しすぎるしそもそも仕様が古いということでIntel AX210NGW に交換し、WiFi-6E / Bluetooth 5.3 に対応させました。

SSDについては余っていた512GBのM.2 NVMe SSDとM.2 SATA SSDを使ってUbuntu Linuxのソフトウェアミラーリング設定を行って試験運転中です。

さらに、32GB SO-DIMMを買って、増設してみました。

今回買ったのはWINTENのSO-DIMM DDR4 3200 32GBです

他のPCにもさしてみるか、ということで2枚セットで購入して増設しました・・・

結果無事32GBを認識しました。

とりあえず現状簡単にできる範囲でのカスタマイズはもうないなぁ、といったところです。

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/07/25時点での感想

v8.0.7までを使用しての使いたくないな、と思う点

・引き続きドキュメントがなさ過ぎる
  いろんな設定の最小値、最大値、どうやって値を決めたらいいのか基準がない
  サポートしてる機能がうっすらとしか書かれてない
  /var/morpheus の件も引き続き記載はない

・動いてるように見えるけど、設計通りの動作なのかよくわからないことがある
  ログの見方とか、どんなログがでるのかとか、そういうことを書いたドキュメントが存在しない
  自分たちで動かしてログを集めて傾向と対策を作らなければダメらしい

・バージョンアップについてちゃんと出来るのか不安
  4月下旬リリースのv8.0.5からベースOSがUbuntu 22.04から24.04に変わって
  クラスタもv1.1からv1.2に変わったけど
  3ヶ月経過してもバージョンアップ手法が未公開
  またHPE Manager仮想マシンのアップデートもドキュメントに記載されているアップデートファイルが公開されなくなって3ヶ月経つ

・iSCSI/FCの共有ストレージがうまく取り扱えない
  共有ストレージ上につくるファイルシステムがHPE VME側では用意してくれない
  GFS2などのファイルシステムを組む必要がある模様
  なお、自社ストレージ Alletra MP Storageについては専用プラグインを提供してファイルシステム不要としている

現時点で共有ディスクはNFSかHPE Alletra MP Storage になるのかなぁ・・・


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にその時点での最新版が表示されます。

2025/03/26注: [My HPE Software Center]からSinginしないで「Browse Free Software」をクリックする、というアクセス方法に代わっていた

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 になっていました。

現状ではアップデートされたかどうかのお知らせが出ていないようなので、自分で確認する必要があるようです。(2025/02/26 Release Noteが公開されるようになった)

2025/02/24付けで ver 8.0.3-1がリリースされました。
HPE_VM_Essentials_SW_image_8.0.3_1_S5Q83_11005.iso の中のdebファイルは変わらずhpe-vm_1.0.2-1_amd64.deb のまま。HPE Manager用仮想ディスクイメージが hpe-vme-8.0.3-1.qcow2.gz に更新。

また、追加でHPE Manager仮想マシン内のファイルをアップデートする用に hpe_vm_essentials_8.0.3_1_amd64.deb と hpe_vm_essentials_supplemental_8.0.3_1_all.deb が増えました

変更点ってなんなの?と聞いてみたら、ドキュメントサイト上に v8.0.3 Release Notesが追加されました。

2025/04/03になって ver 8.0.4-1がリリースされました。(ドキュメント上 v8.0.4 March 31, 2025 と書いてあるけど、サイトで公開されたのは4/3)
HPE_VM_Essentials_SW_image_8.0.4_1_S5Q83-11007.iso の中は hpe-vm_1.0.4-1_amd64.deb と hpe-vme-8.0.4-1.qcow2 になりました。
2025/04/04 10時時点では HPE Manager仮想マシンアップデート用のファイルは未公開です。

2025/04/25付けで ver 8.0.5がリリース されました。
HPE_VM_Essentials_SW_image_8.0.5_1_S5Q83-11009.iso のみ公開で、HPE Manager仮想マシンアップデート用ファイルは無し
Ubuntu 24.04 LTSを使えるようになりました!!

2025/06/11付けで ver 8.0.6がリリースされました
HPE_VM_Essentials_SW_image_8.0.6_S5Q83-11015.iso のみ公開
hpe-vme_1.0.8-1_amd64.deb と hpe-vm-essentials-8.0.6-3.qcow2 でした。

2025/07/11付けで ver 8.0.7がリリースされました
ドキュメントサイトの構成変更があり 「HPE Morpheus VM Essentials Software」になった模様です
HPE_VM_Essentials_SW_image_8.0.7_S5Q83-11017.iso のみ公開
hpe-vm_1.0.9_1-amd64.deb と hpe-vm-essentials-8.0.7-3.qcow2.gz でした。

8.0.4以降、HPE VME Manager仮想マシンのアップデート用ファイルが提供されないのはなんなんでしょうかね・・・

HPE VM Essentialsの構成について

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

2025年1月末時点では、Ubuntu 22.04ベースのサーバ上に、HPE VM Consoleパッケージ(hpe-vm_1.0.2-1_amd64.deb)を追加する。
2025年4月末リリースのv8.0.5.1から Ubuntu 24.04ベースになりました。

追加したサーバのうち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イメージを指定してインスタンスを作成した場合に有効になっている、という仕組みである模様