IBM x3650 M3のVMware ESXi 6.5U1から6.7へのアップデート

公開
0件のコメント
図2.サポート対象外CPUによるエラー

IBM x3650 M3の VMware ESXi を 6.5U1 から他のホストと同じ 6.7 系へ アップデート させようとするも、搭載する Xeon E5506がサポート対象外CPUで弾かれたことから、その回避対策を試してみます。

ESXiホストのSSHを自動開始に

VMware ESXiホストのアップデート作業にはsshが必要なため、ESXiホストをWeb Clientで開き、 ホストの管理 → サービス タブにあるTSM-SSHを選んで起動するのですが、これだけではホストの再起動後は再び停止されていることに。

今回は作業終了するまで何度かホストを再起動するので、自動起動するようにポリシーを ホストと連動して起動および停止します へ変更しておくと便利です。

図1.TSM-SSHの起動と自動起動

図1.TSM-SSHの起動と自動起動

sshでホストに入ったら現在のバージョンを確認しておきます。

 

VMの一括シャットダウン

アップデート作業前にまず、稼働している仮想マシンを全てシャットダウンさせる必要があります。Web Clientから一つ一つ落としても構いませんが、せっかくなのでESXiホストへsshで入り、便利な一括シャットダウンコマンド powerOffVms を試してみるも、

と異常終了。このコマンドの実体はPython2系で記述されているのですが、ESXiは6.0で既にPython3系が導入されており、そのバージョン差異による文法の違いから、このエラーが発生するのだそうです（鳴謝！）。

Shimenrock's Blog
DIY & Install VMware ESXi 6.7.0 update02
https://www.shimenrock.com/k8s/install-esxi-6/
DIY & Install VMware ESXi 6.7.0 update02

/sbin/poweroffvms をデータストアの適当な場所に複製した上で、次の要領で修正します（ , e を as e に）。

  • except Exception, e: → except Exception as e:  （計3箇所）
  • except vim.fault.ToolsUnavailable, e:  → except vim.fault.ToolsUnavailable as e: （1箇所）

修正した powerOffVms を使うと、稼働中の全てのVMを一括シャットダウンすることが出来ました。

 

メンテナンスモードで作業開始

メンテナンスモードに入り、アップデートに必要なバイナリのダウンロードに必要なファイアウォールの設定を施します。

アップデート前のvibリストを控えておきます。

 

ESXiバージョン履歴を確認

複雑なVMware ESXiのバージョン履歴構成は、こちらに一覧KBが公開されています。

kb.vmware.com
 
Access Denied
https://kb.vmware.com/s/article/2143832

さらに個々のリリースに含まれるパッチの内容は、こちらのトラッカーサイトで確認することが可能です。

kb.vmware.com
 
Access Denied
https://kb.vmware.com/s/article/2143832

vCenterに属する他のESXiホストとの互換性を鑑みて、今回は6.7U1の以下のリリースへアップデートしたいと思います。

以下のコマンドを発行してアップデートを実行すると、10分程度で結果が返ってくるので、問題無いのを確認したらホストを再起動。

 

Unsupported CPU Xeon E5506

その後、いくら待ってもWeb Clientやsshにもアクセス出来ないので、ホスト機のモニタを確認すると次のエラーメッセージが表示されており、アップデート作業は異常終了していました。

図2.サポート対象外CPUによるエラー

図2.サポート対象外CPUによるエラー

確認してみると、確かにXeon E5506はESXi 6.7以降サポート外でした。そこで回避策を調べていると、ESXi 7.0でのこちらの例が6.7でも当てはまるのではと思えました。

WilliamLam.com
 
Quick Tip - Allow unsupported CPUs when upgrading to ESXi 7.0
https://williamlam.com/2020/04/quick-tip-allow-unsupported-cpus-when-upgrading-to-esxi-7-0.html
As outlined in the vSphere 7.0 release notes (which everyone should carefully read through before upgrading), the following CPU processors are no longer supported: Intel Family 6, Model = 2C (Westm…

ひとまずホストマシンをシャットダウンさせ、ESXiシステムの入ったUSBドライブを取り出します。

 

ESXiホストのLegacy CPU対応

USBドライブをUbuntu 18.04母艦へ繋ぐと、64GBのUSBドライブは次のようなパーティション構成になっていました。

図3.ESXiシステムUSBパーティション

図3.ESXiシステムUSBパーティション

新しいシステムが収められた方にある boot.cfg を開きます（ファイル内のビルド番号を確認して識別）。

kernelopt 項に allowLegacyCPU=true をスペース区切りで追記します。

そして bootstate 項の値が 2 になってしまっているのを 1 に上書きしたら、USBドライブをホストマシンへ戻して起動してみます。

起動の様子をモニタで眺めていると、一瞬赤い警告メッセージが表示されるものの、問題無くシステムが起動しました。

図4.ESXi 6.7U1アップデート成功

図4.ESXi 6.7U1アップデート成功

アップデート完了時点のvibリストは次のようになっていました。

 

VMのLegacy CPU対応

こうしてESXiホストのLegacy CPU対応は終わりましたが、その中で稼働するVM側にもその対応が必要です。

図5.リアルモードの仮想化エラー

図5.リアルモードの仮想化エラー

仮想マシンの 設定の編集 を開き、 仮想マシンのオプション タブの下方にある、 設定の編集 ボタンを押します。

図6.仮想マシンの設定の編集

図6.仮想マシンの設定の編集

設定パラメータを直接編集できるフォームで 設定パラメータの追加 ボタンを押し、次の項目名と値を入力します。

  • 名前 : monitor.allowLegacyCPU
  • 値  : true
図7.新規設定パラメータの追加

図7.新規設定パラメータの追加

vmxファイルを直接編集する場合は、次の1行を追加するのみです。

これでようやく仮想マシンを起動することができ、Windows ServerではVMware Toolsを問題無く更新することができました。

図8.VMware Tools更新完了

図8.VMware Tools更新完了

ESXi ログ保存場所をデータストアに

今回の作業中、アップデート適用中のログなど、ESXiホストログが永続的ではないUSBドライブの中にあり、難儀したことから最後にこれを永続的なデータストアへ移動させたいと思います。

Web Clientのデータストアブラウザで予めログを収めるフォルダを作成（ HostLogs フォルダ）したら、ESXiホストの 管理 → システム → 詳細設定 と進み、設定項目一覧の中から次のキーを見つけて、値を上書きします（データストア名を鉤括弧で囲み、作成したフォルダ名を半角スペース開けて入力）。

  • キー : Syslog.global.logDir
  • 値   : [Datastore名] HostLogs
図9.ホストログ出力先の設定

図9.ホストログ出力先の設定

これで既存のログが移動されてくるのでホスト再起動後、トラブルシューティングに必要なログが消えることもありません。

 

今回の作業、仮想マシンを全てシャットダウンした状態で進める必要性から、実際には自宅からリモートで行っていました。

そのためにアップデート再起動後の「Unsupported CPUエラー」画面を確認できず、またログにもそれらしいエントリも残っていなかったことから、適用するバージョンをあれこれ変えて十数回は試行したような泥沼ぶり。

VMware ESXiの黎明期（ver.3.5辺り〜）から親しんできましたが、サステナブルがちやほやされる世の中に逆行するような、古いハードウェアのサポート切りには少し納得しかねる思いから、今回の一件で近年よく耳にするProxmoxへ心移りつつあります。

 

 

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA