【Update 2021/09/21】
何気なく見たら2021/08/24にESXi7.0 Update 2cパッチがリリースされ、解消されたようです。
docs.vmware.com
R 2777003：ESXi 7.0 Update 2a の起動デバイスとして USB を使用すると、ESXi ホストが応答しなくなり、ホストが応答しておらず起動バンクが見つからないというアラートが表示されることがある
【Update 2021/09/21 End】
ある種の自宅ラボと称する自宅サーバーとしてDeskMini 310を衝動的に導入して、ESXiを動かしています。
sylve.hatenablog.jp
しかし導入したESXiが凄く不調です。具体的な症状としては、1日～2日程度でUSBメモリを見失うようで、以下のメッセージを吐き出します。
ha-datacenter の hogehoge で問題が検出されました: Bootbank cannot be found at path '/bootbank' (2021-08-14T00:07:40.180Z cpu5:534770)
このメッセージが出ると以下の事象が発生して、実質的にWebコンソール経由の操作を受け付けなくなります。
ちなみに、何回かリロードを繰り返していると稀にログを参照することが出来る「場合」があり、その時にvmkwarning.logを見ると以下のようなメッセージを吐いています。
2021-08-14T00:36:34.245Z cpu5:524475)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "mpx.vmhba32:C0:T0:L0" state in doubt; requested fast path state update...
さて困りました。事象が発生したとしても既に起動済みの仮想マシン群についてはネットワーク経由でアクセスできますが、Webコンソール経由の操作が行えないため新規仮想マシンの作成が行えません。それ以前にWebコンソール経由で仮想マシンを制御出来ないのは不便すぎますし、何らかの要因でESXiの再起動を行いたい場合はネットワーク経由(SSHやRDP経由)で全仮想マシンを停止させ、DeskMini 310の電源ボタンを長押しする一番駄目な電源OFFのやり方を強行する必要があります。
数日間仕事の片手間でアレコレと調べてみましたが、結論としては不具合で未だ修正されず・追加修正パッチも出されず・VMwareから放置されている状態なので、必要が無ければESXi7.0 U2/U2aを適用しない方が良さそうです。
事象発生環境
DeskMini 310導入に合わせて構築した環境ですが、ハードウェア・ソフトウェア周りは以下のような環境となっています。
- ハードウェア
- ソフトウェア
- VMware vSphere Hypervisor 7
- ESXi 7.0 Update 2a(ビルド番号: 17867351)
- VMware vSphere Hypervisor 7
新たにESXi環境を作成するということから、環境作成時点で最新版・最新ビルドのESXiを導入しました。
NICに関しては少し前までは非対応とされていたオンボードNICですが、現在では特に追加ドライバ無しで認識されるようになっています。
やたらディスクを積みまくっていますが、深い意味はありません。もともと旧ESXiサーバーとして利用していたOptiPlex 7040 Microに搭載していたストレージを継続して搭載していますが、DeskMini 310に乗り換えた際に追加で1台2.5型のディスクが搭載できたので変換下駄を噛ませたM.2 SATAディスク*1を追加した次第です。
最初はUSB3.0が悪者と推察した
出所は分かりませんが、USB3.0が悪いような気がしました。多分ですがSkylake以降の世代でWindows7をインストールしようとするとデバイスドライバの問題で四苦八苦を強いられることがあったように、VMwareでも何か好ましくないことが発生しているのではないかと漠然ながらUSB3.0を悪者に仕立て上げて万事解決としたいと思い込んで間違えた推察に至った次第です。*2
まずはUSBメモリを差し込む位置を本体背面のUSB3.0を示す青いUSBポートから、USB2.0を示す黒いUSBポートに差し替えて様子を見てみました。
・・・まぁ、Skylake世代でWindows7インストールの事例をベースにした非常に古い考え方なので、正直なところ何も変わらないんですよね。1日程度でESXiが操作不能に陥る挙動を示します。
続けてUSB2.0止まりのUSBメモリを買ってきました。SanDiskのCruserFit USB Flash Memory(32GB)、あきばおーで500円チョットで買える安物です。*3
USB2.0ポートにUSB2.0規格のUSBメモリ、これで万事問題解決！1日経過して事象が発生せず、ヤッター！・・・と思えば2日目で事象再発と玉砕です。
そもそもUSBメモリが壊れた？
USB3.0悪者説と合わせてUSBメモリ自体が壊れた可能性を考えました。
・・・とは言うものの、SanDisk UltraFitはDeskMini 310購入に合わせて調達した新品・・・。いやひょんなことから中身が壊れた可能性が・・・。
まぁ、結局上記のUSB2.0規格止まりのUSB2.0メモリに差し替えても事象が再発したので、USBメモリは問題無かった訳でして・・・。
ガチのハード故障かと頭を抱えたがバグでした
USBメモリが原因では無いので、愚直に「Bootbank cannot be found at path '/bootbank'」で調べていくとハード故障と挙げられているVMwareのナレッジが出てくるので、(DeskMini 310自体の)初期不良品の可能性も脳裏を過ります。
https://kb.vmware.com/s/article/70788?lang=jakb.vmware.com
しかし、調べに調べてみると単にESXi7.0 Update2で発生したバグであることが判明しました。
ESXi 7.0 U2 – Bootbank cannot be found at path ‘/bootbank’kallesplayground.wordpress.com
発生事象は同じくESXiがおかしくなる、記事との違いは(該当の記事では)SDカードにESXiを入れたとのことですが掲載されているVMwareのコミュニティフォーラムを見る限りUSBメモリでも駄目っぽいとのことなので、完全一致です。
しかもご丁寧にこんなことまで書かれています。
06.05.2021 update – the VMware ESXi 7.0.2 build 17867351 seems to be also affected with same problem.
ビルド番号17867351は7.0 Update 2aで私が導入しているバージョンです。
つまり、マイナーバージョンアップしても事象は解消されてないよ・・・と・・・。
・・・考えてみれば、OptiPlex 7040 Micro使ってた頃はパッチ適用をサボって、ESXi7.0 Update 1d(ビルド番号17551050)で止めてた気がします・・・。*5
・・・なるほど、暴言を吐くのであれば「クソパッチ」を自らの判断で積極的に当ててしまったと。ついでにOptiPlex 7040 Micro運用時はサボり癖から意図せずクソパッチを回避してたと。
それ以前に毎年8月は毒パッチとかクソパッチとか引く確率たけぇなぁ(白目)*6
sylve.hatenablog.jp
回避策はUSB以外のストレージにESXiインストール
回避策をどうにか考えなければなりませんが、一番手っ取り早い方法はこれです。
Hosts, where ESXi was installed to SSD, do not seem to have this issue.
ESXiがSSDにインストールされている環境では発生しないとのこと。もう少し補足すると、USB接続以外のSATAなどで接続されたストレージにESXiを入れれば回避可能とされています。つまり、内蔵ディスクのうち1台を(ESXi専用に)潰せば問題なし！・・・とのこと。
幸いなことに追加搭載した2.5型SATAの変換下駄噛ませたM.2 SATAディスクのディスク使用率が少なく、他のディスクへデータを移すことでESXi起動SSDとして転用できたので、該当のSSDをESXi起動用SSDにすることで対応としました。
ESXi起動用にしたとしても、SSDの全領域がESXiシステム領域と使われる訳では無く、余った領域をデータストア(仮想マシンのデータを入れる領域)として利用可能なので、自宅ラボ環境で容量がカツカツの場合でも安心してESXi起動用SSDに利用することができます。*7
・・・まぁ、仮想マシンでI/Oガッツリ食うような用途だとESXiコンソールの動作に影響を及ぼすと思うので、利用頻度の少ない、例えばISO保存用ストレージなどに使うことをお勧めしますが・・・。
ESXi起動用SSDとして環境を整えて数日間様子を見ていますが、少なくともマウントポイントを見失ってESXiが変な挙動を示すことは無くなりました。
・・・しかし、数か月前に発生した事象を修正せずに放置している(ように見える)と言うのは印象が随分と悪く、思考停止でESXiを利用してきましたが別のソリューションに移行する必要*8があるのでは・・・と言うことが脳裏を過ります。
また、ボチボチと調べていくとどうやら7.0 Update 1以降からストレージ周りの要件が著しく高くなり、起動ストレージに対して高頻度で書き換えが発生するようになったとのことで、一部ベンダーではESXiをSDカードに導入することは非推奨と言われる始末だそうで・・・。
blog.osakana.net
そのことも考慮すると、現状の最新版であるESXi7.0 Update 2aを新規導入する場合は内蔵ストレージにESXiをインストールすることが無用なトラブルを避ける最善策と言えそうです。
本来新しいパッチはセキュリティ的な対応も含まれると思うので、可能な限り最新版を適用することが好ましいと思われますが、USBメモリやSDカードにESXiをインストールして運用している場合は今回のESXi7.0Update2/2aの適用は見送った方が良さそうです。
個人的にESXi7.0 Update 1dまではUSBメモリで問題なく運用していた実績があるので、(USBメモリやSDカードを起動メディアとしている場合は)Update 1dまでは充てても大丈夫だと思います。但し、上記の記事を見る限りストレージの書き換え頻度を抑えるI/O抑制制御がESXi 7.0 Update 1で外されたと書かれていることを考慮すると、USBメモリ/SDカードを起動メディアとして運用している場合はメディア寿命を鑑みるとESXi7.0bのパッチに留めておいた方が良いのかも知れません。
【Update 2021/09/21】
パッチ出ました
冒頭で追記した通り、Update 2cが登場して、該当の事象を含む数多くの不具合が修正されたようです。
docs.vmware.com
PR 2777003：ESXi 7.0 Update 2a の起動デバイスとして USB を使用すると、ESXi ホストが応答しなくなり、ホストが応答しておらず起動バンクが見つからないというアラートが表示されることがある
USB デバイスのキュー深度が小さく、ESXi ストレージ スタックでの競合状態が原因で一部の I/O 操作がデバイスに到達しないことがあります。このような I/O は ESXi ストレージ スタック内のキューに入れられ、最終的にタイムアウトになります。その結果、ESXi ホストが応答しなくなります。
vSphere Client で、次のようなアラートが表示されます。Alert: /bootbank not to be found at path '/bootbank' and Host not-responding.
vmkernel ログに次のようなエラーが記録されます。2021-04-12T04:47:44.940Z cpu0:2097441)ScsiPath: 8058: Cancelled Cmd(0x45b92ea3fd40) 0xa0, cmdId.initiator=0x4538c859b8f8 CmdSN 0x0 from world 0 to path "vmhba32:C0:T0:L0".Cmd count Active:0 Queued:1.
2021-04-12T04:48:50.527Z cpu2:2097440)ScsiDeviceIO: 4315: Cmd(0x45b92ea76d40) 0x28, cmdId.initiator=0x4305f74cc780 CmdSN 0x1279 from world 2099370 to dev "mpx.vmhba32:C0:T0:L0" failed H:0x5 D:0x0 P:0x0 Cancelled from path layer.Cmd count Active:1
2021-04-12T04:48:50.527Z cpu2:2097440)Queued:4本リリースで、この問題は修正されました。
パッチリリースが泣きながら内蔵ストレージ(SSD)にESXiをインストールした僅か数日後と言うのが、私の運の無さと言うか残念感が拭えませんし、現実を直視せずパッチリリース情報をチェックしていなかったことが露呈した瞬間ですね(白目)
ただ、これで万事OKヤッター！・・・と思ったら、実はESXi7.0 Update 2dと言う新たなパッチが1週間程度前にリリースされているんですよね。・・・えぇ、日本語のリリースノートではまだ見つかりませんが、英語のリリースノートでは「あるぞ！」と書かれてまして・・・。
docs.vmware.com
Update 2dでの修正内容は1つのみで、逸般の誤家庭でもあまり利用する機会が無いハードでの不具合修正とのことです。
PR 2824750: ESXi hosts in a cluster on Dell EMC PowerFlex might intermittently fail with a purple diagnostic screen due to a PCPU preemption error
The management of persistent memory in a cluster on Dell EMC PowerFlex with NVMe drives added as RDM devices might inconsistently update a PCPU preemption counter in ESXi hosts in the cluster. As a result, ESXi hosts might intermittently fail with a purple diagnostic screen.This issue is resolved in this release.
個人的な感覚としては、既にESXi7.0 Update 2aを適用してしまった方は、様々な不具合の修正が入っているのでUpdate 2cを適用したほうが良いかと思います。直近リリースされたUpdate 2dは別の不具合を内包していそうで少々怖いので、修正内容に合致しない環境ならUpdate 2cで様子を見るのが(USB起動で酷い目にあった身からすると)無難と思います。
もし・・・
もうどうにでもな～れ *ﾟﾟ･*+。 ｜ ﾟ*｡ ｡∩∧∧ * + (･ω･`) *+ﾟ *｡ヽ つ*ﾟ* ﾞ･+｡*･ﾟ⊃ +ﾟ ☆ ∪ ｡*ﾟ ﾞ･+｡*･ﾟ
と悪い意味で吹っ切れた私みたいな方は、良い機会なのでUpdate 2dを入れても良いのかもしれません。えぇ、もう内蔵SSDにインストールしちゃいましたし、後戻りするには手間なので・・・。
Update 2aで不具合を踏み抜いたことですし、この際みんな一緒に駄目な方向の沼に溺れませう(白目)
【Update 2021/09/21 End】
*1:なんか一時期所有していたThinkPad X1 Carbox用に使ってたような、他のマシンで使ってたような。よく覚えてないが容量の割には妙に使われる機会が少ないM.2 SATAディスクです・・・。
*2:なおOptiPlex 7040 Micro利用時は全ポートUSB3.0だったと思うので、最初からガバガバ推理だったと・・・。
*3:ついでに本体側面のUSB2.0ポートを利用可能にするアタッチメントも買いました。なぜ買った？単に欲しかったから。
*4:おっさんが使用済みなのでタダでも要らねえと罵声が飛んでくるパターン。
*5:なんでもう手放したOptiPlex 7040 Microの細かいバージョンを覚えているか？単に自己ナレッジとして残した記録に7.0 Update 1dの記録が残ってた+ダウンロードしたパッチの中で7.0 Update 1dがあったから・・・。
*6:ちょうど1年くらい前にNUC8i7HVKにイケてないBIOSアップデートで枯れんばかりの涙を流した記録が・・・。
*7:私の場合500GBのSSDをESXi起動用としましたが、100GBくらいがESXiシステム領域として利用されて、残り400GBくらいがデータストアとして割り当てられました。
*8:現在の業務都合でどちらかと言うとESXiの方が助かりますし、Hyper-V Serverだと地味に本来はAD環境が必要だったり、macOSからの接続性に難があったりするので、私の環境ではESXiがベストなんですけど・・・。
