ESXi NICを新しくして本番環境を7.0にアップグレードする

いま、ESXiのアップグレードをしようとしているが、7.0ではRealtek RTL8111が使えない。
そこで、Intel 82574Lを搭載したネットワークカードを買ってきた。

---

アップグレードする意味はほとんどないのでは？と思うのだが、実はちょっと管理画面が気持ち悪い状態のまま何年が経過したか。

• 

• 

6.5にバージョンアップしてからずっとこれで、色々調べてみたけれども解決策は見つからなかった。

まぁでもvSphere Clientで接続すれば見られるからいいや…と我慢していたのだが、この度6.5U3にアップデートしたところ、vSphere Clientでの接続ができなくなった。

• 

サーバー 0.0.0.0 って、これは無効といわれているのと変わらない。

こうした状況を打開するには…7.0にアップグレードしてみよう！と思ったのだった。

• 環境
• 結果
  • 監視
  • 影響
    • ダウングレードができない
    • BIOSが遅い
    • VMにallowLegacyCPU=trueの指定が必要
• アップグレードシミュレーション
  • ネットワーク構成の確認
  • 6.5U3の準備
  • 7.0U2aへのアップグレード(ISO)
  • 7.0U2aへのアップグレード(オフラインバンドル)
• 本番環境のアップグレード
  • 82574Lの追加
  • アップリンクの変更
  • アップグレードの阻害となるVIBの削除
    • net55-r8168
    • sata-xahci
  • アップグレード
• アップグレード後の問題対処
  • このホストは、リアルモードの仮想化をサポートしていません
  • BIOS起動からUEFI起動に変更
    • GPartedの起動
    • LVMの場合に行うパーティション操作の下準備
    • パーティションの編集
    • Boot-Repairを使って起動パーティションにする
    • 仮想マシン起動時の表示をサーバーのそれに戻す
  • 他のVMの設定をすべて変更
• 起こったこと

環境

6.5.0 Update 3 (Build 18071574) ※ビルド番号からのバージョン確認はこちらでできる。英語版にしか載っていないバージョンがあるので注意。

型番	Gateway DX4840
CPU	Intel core i5 750 (Lynnfield)
Memory	20GB (2GBx2+8GBx2)
LAN	Realtek RTL8111 + Intel 82574L

色々と調べた結果、7.0でRTL8111が使えないことが分かり、アップデートするためにはIntel 82574Lなどの7.0で使えるNICが必要だった。

サポート対象外のCPUでもESXi 7.0をインストールすることはできた。
だが、制約もあったので、トラブルがないのであれば6.5のまま使うのが良いと思う。

結果

まずは結果から。

監視

監視データーはとてもいい感じ。あれだけ探してどうにも解決できなかったのに、サクッと改善したのは嬉しい。

• 

• 

影響

サーバー運営上、影響があった。うちでは、最初だけ頑張ればOKって感じなので、アップグレードに悔いはないが…

ダウングレードができない

まず、ダウングレードができない。Recoveryモードで起動しても、戻り先はないよ、と表示される。
もしもダウングレードしたいなら、データストアを残した形のインストールしか方法がなさそう。

BIOSが遅い

BIOSが猛烈に遅い。

OSのロードが始まるまでに5分？10分？待たされる。
そもそもBIOS画面が出てから、ゲージが右に届くまでが遅すぎる。
そして、画面が真っ暗になってからが途方もなく長い長い…

OSの読み込みが始まってからはいつも通りのスピード感。古いCPUだから？なのか、BIOSだけがちょっとあり得ない遅さだった。

こんなスペックのPCにESXiを導入しようなんて人がほとんどいないからなのか、事例は全然見つからない。
オレにはこの問題は解決できないな。

ただ…救いだったのが、UEFIの起動には全く問題がないこと。
すべてのサーバーをUEFIで起動するように設定して、この問題は回避した。

今後追加するすべてのVMは、UEFI起動にしないとまともに動かないので、結構な影響といえる。

VMにallowLegacyCPU=trueの指定が必要

すべてのVMの詳細オプションで
　項目: monitor.allowLegacyCPU
　値: TRUE
を指定しておく必要がある。そうしないとVMが起動してこない。

これは、サーバーを足したり引いたりする回数が多い人には大きな影響になるかもしれない。

アップグレードシミュレーション

Nested ESXiで、アップグレード時にどのような動作になるのか確認しておこう。

ESXi	6.5U3	現在運用中。
NIC 0	E1000	Realtek RTL8111の代わりに使ってみる。 ESXi 7.0U2aでは認識できない。 ESXi 6.5U3導入後、vmnic1が追加された後、アップリンクを外す。 NIC 1だけで動作することが確認できたらNICを削除する。
NIC 1	VMXNET 3	Intel 82574Lの代わりに使ってみる。 ESXi 6.5U3でも、7.0U2aでも認識できる。 ESXi 6.5U3導入後、vmnic1として追加して、アップリンクさせる。

これで、アップグレードをしてみれば、どんな動きをするのか確認できるのではないかと考えた。

ネットワーク構成の確認

本番環境を見てみると、ESXiのネットワークはこのような構成になっているようだ。

┌──────┐　┌──────┐　┌──────────┐
│物理アダプタ├─┤vSwitch　　 ├┬┤Management Network　│
│vmnic0　　　│　│vSwitch0　　│││vmk0(192.168.xx.xx) │
└──────┘　└──────┘│└──────────┘
　　　　　　　　　　　　　　　　　│┌──────────┐
　　　　　　　　　　　　　　　　　└┤VM Network  　　　　│
　　　　　　　　　　　　　　　　　　│仮想マシン01　　　　│
　　　　　　　　　　　　　　　　　　│仮想マシン02　　　　│
　　　　　　　　　　　　　　　　　　│…　　　　　　　　　│
　　　　　　　　　　　　　　　　　　└──────────┘

また、vmk0にIPアドレスが振られていること、vSwitch0の状態を確認する際に表示されるメッセージ

この仮想スイッチには、アップリンクの冗長性がありません。別のアップリンク アダプタを追加する必要があります。

から、物理的なNICにIPアドレスが振られているわけではなく、Management NetworkでIPアドレスを管理していると理解した。

6.5U3の準備

既に6.5U3は作ってあって、これをテストに利用する。

仮想マシンの一般オプションにあるゲストOSをLinuxとし、ゲストOSのバージョンには2.6.x Linux (64ビット)を選択する。
これで、NICにE1000が選択できるようになるので、選択して起動してみる。

• 

問題なかったのでシャットダウンし、NICを追加する。

• 

起動したところ2つのNICを認識している。vSwitch0の設定で、

• vmnic1をアップリンクとして追加。
• vmnic0をアップリンクから削除。

して、vmnic1だけがアップリンクされた状態にする。
あわせてvmk0に固定のIPアドレスを振って再起動してみる。

• 

• 

問題なく動作することが確認できた。

さて、本番環境ではRTL8111が見えなくなるので、1つめのNICを削除してみよう。
これは、仮想ハードウェアの設定でNICを削除することで対応した。
ドライバがなくなって見つからなくなるのとは厳密には違うけれども、NICがなくなること自体は再現できる。

改めて起動…vmnic0がなくなり、vmnic1だけの構成になった。多分、本番環境もこんな感じになるだろう。

7.0U2aへのアップグレード(ISO)

アップグレードにはISOを利用する。CPUが古いので、ブートローダーのパラメーターにallowLegacyCPU=trueを追加しなければならない。
ISOを作り、インストーラーが起動したらアップグレードで進めていく。

アップグレード後の再起動で、ブートローダーを起動する前にオプションで必ずallowLegacyCPU=trueを追加する。
これをうっかり先に進めてVMB: 634エラーを表示させてしまうと、その後はNo hypervisor found.となって再インストールしかできなくなるので注意。

上手く起動させることができたら、SSHで接続して起動パラメーターを追加する。
/bootbank/boot.cfg

…
kernelopt=autoPartition=FALSE allowLegacyCPU=true
…

※赤文字を追加。

再起動して問題なく起動することを確認する。
物理アダプタはvmnic1だけが有効になっており、問題なく動作している。

特に気遣わなくてもNICはvmnic1として管理されることが分かった。

7.0U2aへのアップグレード(オフラインバンドル)

オフラインバンドルで安全にアップグレードできないか…と考えた。
インストール後の再起動であれほど気を遣うのは嫌だし、十分にテストした上でやるなら、こちらの方がオススメだと分かった。

データストアにオフラインバンドル(zipファイル)をアップロードし、SSH接続してアップグレードバンドルを適用する。

[root@localhost:~] esxcli software profile update -d /vmfs/volumes/datastore1/ESXi-7.0U2a-17867351-standard.zip -p ESXi-7.0U2a-17867351-standard
Update Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_atlantic_1.0.3.0-8vmw.702.0.0.17867351, VMW_bootbank_bnxtnet_216.0.50.0-34vmw.702.0.0.17867351, …長く続く
   VIBs Removed: VMW_bootbank_ata-libata-92_3.00.9.2-16vmw.650.0.0.4564106, VMW_bootbank_ata-pata-amd_0.3.10-3vmw.650.0.0.4564106, …長く続く
   VIBs Skipped:

アップグレードできた。

ここで、起動パラメータを設定するため、boot.cfgを探す。

[root@localhost:~] find / -name "boot.cfg"
/vmfs/volumes/6936f370-87f39b0c-caf3-2e5a4b69a34e/boot.cfg
/vmfs/volumes/40ffd076-87ee7b23-2cc1-13fda32fc7b6/boot.cfg

開けて調べてみて、build=7.0.2-0.0.17867351となっている方のオプションを追加する。
/vmfs/volumes/nnnnnnnn-nnnnnnnn-nnnn-nnnnnnnnnnnn/boot.cfg

…
kernelopt=no-auto-partition allowLegacyCPU=true
…
build=7.0.2-0.0.17867351
…

これで再起動したところ、問題なくESXi 7.0U2aが起動してきた。

本番環境のアップグレード

7.0へのアップグレードでは、RTL8111のドライバがあるだけでエラーが発生して先に進めなくなるため、使えるNICを追加してRTL8111を削除する。
サーバー証明書を差し替えるのも面倒だし、他の様々な設定に影響するので、IPアドレスなどは従来のものを踏襲する。

これでいけるものと思っていたが、甘かった。実際にNested ESXiの中でホストを動かしてテストしてみるべきだったと思う。

82574Lの追加

届いたNICを取り付けて起動し、とりあえずLANケーブルを繋いだところ、このような状態になった。

• 

vmnic0としてRTL8111が使われていて、これは従来通り。
追加したNICはvmnic1として認識され、ne1000として扱われている。

アップリンクの変更

vSwitch0にアップリンクとしてvmnic1(82574L)を追加する。

続いて、vmnic0(RTL8111)をvSwitch0のアップリンクから削除する。
そして、vmnic0からLANケーブルを抜く。

追加したNICだけで、ネットワークは問題なく動いている。

vSwitch0で物理アダプタをくるむことで、こんなに管理が楽になるのか…なるほど。

アップグレードの阻害となるVIBの削除

net55-r8168

いよいよ、RTL8111のドライバ削除にチャレンジ。
ドライバがインストールされているだけでアップグレードに失敗するので、削除せざるを得ない。

ESXiに接続してNICドライバの名前を念のため確認する。

[root@ESXi:~] esxcli software vib list
Name                           Version                               Vendor    Acceptance Level    Install Date
-----------------------------  ------------------------------------  --------  ------------------  ------------
net55-r8168                    8.045a-napi                           Realtek   CommunitySupported  2021-08-09
sata-xahci                     1.39-1                                VFrontDe  CommunitySupported  2021-08-09
ata-libata-92                  3.00.9.2-16vmw.650.0.0.4564106        VMW       VMwareCertified     2021-08-09
…

名前が確認できたので、ドライバを削除。

[root@ESXi:~] esxcli software vib remove -n net55-r8168
Removal Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed:
   VIBs Removed: Realtek_bootbank_net55-r8168_8.045a-napi
   VIBs Skipped:

これで再起動してみると、vmnic0が削除され、vmnic1だけが残った状態になっていた。

sata-xahci

おっと…よく見るとnet55-r8168だけでなく、sata-xahciがインストールされている。

sata-xahciは6.5から不要になっている、と書かれている。
VMware Front Experience / ESXi 6.5 Release Notes for free license and white box users

ESXi 6.5には、SATA AHCIコントローラーをサポートする新しいネイティブAHCIドライバー(vmw_ahci)が含まれています。

ネイティブドライバを試したい場合は
　esxcli software vib remove -n sata-xahci
を実行してアンインストールします。

もし、ネイティブドライバで問題が発生した場合には
　esxcli system module set --enabled=false --module=vmw_ahci
で無効化し、必要ならsata-xahciを再インストールします。

PCIデバイスを確認してみると、SATA AHCIは読み込まれているが、うちの環境は
　ベンダーID: 0x8086
　デバイスID: 0x3b22
となっており、このコミュニティ版のドライバは使われていない模様。
VMwareの互換性ガイドでも7.0U2がサポート対象とされていた。

以上の状況証拠からsata-xahciは不要と判断し、削除して再起動してみたが、動作に問題はなかった。

もしも再度ドライバをインストールしたくなったら、zipをダウンロードしてきて、データストアにアップロードし、それをインストールすれば良さそう。
あるいは、Webからvibをインストールか。
vmware customer connect / ESXi 5.x/6.x/7.x ホストをパッチする為の「esxcli software vib」コマンド (2008939)
V-Front Online Depot for VMware ESXi / Sata-xahci

esxcli software vib update -d "/vmfs/volumes/Datastore/DirectoryName/sata-xahci-1.42-1-offline_bundle.zip"
esxcli software vib update -v http://vibsdepot.v-front.de/depot/vft/sata-xahci-1.42/sata-xahci-1.42-1.x86_64.vib

アップグレード

いよいよESXi 6.5U3から7.0U2aへのアップグレードを実行。

このPCはUSBフラッシュメモリからOSを起動できないので、ISOからアップグレードしようと考えていたのだが、オフラインバンドルの方がリスクが少なそうだったので、そちらにした。

結果は成功、起動してきた。だが…

アップグレード後の問題対処

アップグレードできた！まずは監視データーはどうなっているか…おっ、ちゃんと表示しているような気がするぞ。いい感じだ！

と思ったのもつかの間、VMが起動できない。対処にはちょっと手間が掛かる。

このホストは、リアルモードの仮想化をサポートしていません

運用するサーバー(Ubuntu x 4)を起動しようとしたら、こんなメッセージが表示された。

Failed to power on virtual machine ESXiTest. This host does not support virtualizing real mode. The Intel "VMX Unrestricted Guest" feature is necessary to run this virtual machine on an Intel processor. Click here for more details.

仮想マシン ESXiTest のパワーオンに失敗しました。このホストは、リアル モードの仮想化をサポートしていません。この仮想マシンを Intel 製プロセッサ上で実行するには、Intel の「VMX Unrestricted Guest」機能が必要です。 詳細についてはここをクリックしてください。

これはヤバい、今日は久しぶりに涼しい日なのに、汗が出てきた。

これって回避する方法あるの？と慌てて探していると、ただアップグレードするだけでなく、VMを起動するところまでをフォローしている記事に出会えた。
Flemming's Blog / How to run VMware ESXI 7.0 on hardware with unsupported CPUs

これによれば、VMにもallowLegacyCPU=trueの設定ができて、動作させることができるらしい。
設定の編集 → 仮想マシンオプション → 詳細 → 設定パラメータ を開き、monitor.allowLegacyCPUとTRUEを設定。

• 

これで確かにVMは上がってくる。上がってくるけれども、全然OSが起動しない。

起動しっぱなしで情報を探していたら、ん？起動したな。あぁ、どうにか起動はするけれども、めちゃくちゃ遅いのか。

BIOS起動からUEFI起動に変更

他のサーバーも起動すると、だいぶ待たされた後でOSがロードされる。
でも、すべての処理が遅いわけじゃなくて、OSのロードが始まるまでに途方もない時間が掛かっていることが分かってきた。

これ…もしかしてBIOSで問題が起きてるのか？と思って調べたけれども、情報を見つけることができなかった。
汗が止まらねぇ…

試行錯誤してみたら、どうやら仮想マシンをBIOSからEFIに変更すれば、VMはすぐに起動するらしいことが分かった。

• 

だからといって、運用中のサーバーをBIOSからEFIに変更しても起動できない。
どうにかして起動方法を切り替えなければ…と探していたところ、ほぼダイレクトに答えを教えてくれる情報が見つかった。
ubuntu documentation / UEFI

ざっくりといえば、EFIから起動するために専用のパーティションを作り、そこに起動プログラムをインストールする、ということらしい。

GPartedの起動

GPartedでパーティションが作れるらしいので、LiveCDをダウンロードしてくる(amd64)。
GNOME Partition Editor

仮想マシンの設定をBIOSからEFIに変更し、GPartedのLiveCDをセットしてPCを起動。

起動中の問い合わせについては、

• Configuring console-data
  → Select keymap from arch list → qwerty → Japanese → Standard
• Which language do you prefer ?
  → 15 (Japanese)
• Which mode do you prefer ?
  → 0 (Continue to start x to use GParted automatically)

で起動した。このLiveCDはdebianで作られているようだ。

LVMの場合に行うパーティション操作の下準備

LVMじゃない人は次のセクションに飛ばしてOK。

インストール時に選択肢を間違えたらしく、このVMはLVMでインストールされていた。
LVMを縮めるためにはlvreduceコマンドを使う模様。
@IT / 【 lvreduce 】コマンド――論理ボリュームを縮小する

LVMのインフォメーションを見ると、
　Volume Group = ubuntu-vg
　Logical Volume = ubuntu-lv
で、サイズが15GiBとなっている。
この情報は lvs というコマンド(パラメータなし)でも表示される。

これらの情報を使って、UEFIで推奨されている200MiBを確保するため、LVMを縮める。
画面右クリックでメニューを開き、Terminals → lxterminal with root privileges でターミナルを開き、以下のコマンドを入力した。

root@debian:~# lvreduce -L -200mb -r /dev/ubuntu-vg/ubuntu-lv

※-rオプションの効果があるのかどうかは…よく分からなかった。

GPartedでパーティションの情報を読み込み直すと、LVMの使用済みサイズが14.8GBになっていた。

パーティションの編集

パーティションを縮める準備ができたので、推奨されている200MiB程縮めて、新しくFAT32のパーティションを作る。
パーティションを作成したら、bootとespのフラグを立てる。

• 

パーティションができたので、シャットダウンする。
システムをシャットダウンすると、メディアを取り出してENTERを押すように言われるが、VMからは外れているので、そのまま[Enter]キーを押す。

Boot-Repairを使って起動パーティションにする

続いて、UEFIの為に作ったパーティションに、起動用のプログラムをインストールしていく。

Boot-Repairは起動の問題を修復するためのツールで、Ubuntuのコミュニティヘルプで紹介されていた。
ubuntu documentation / Boot-Repair

紹介先の記事から張られているリンクでこちらに云って、ISOをダウンロードしてきた。
SOURCE FORGE / boot-repair-disk

ISOをセットして起動したところ、自動起動にはならない模様。
上(Boot-Repair-Disk session)を選択した状態で[Enter]を押す。

起動直後に質問された。今、ISOを落としてきたばかりだが、Yesでも問題はないのでそうしてみた。

Boot Repair

It is strongly recommended to always use the latest version of this software.
Do you want the software be automatically updated now?
→ Yes

本ソフトウェアは常に最新版を使用することを強くお勧めします。
今すぐソフトウェアを自動的に更新しますか？

DeepL先生の翻訳

RAID積んでる？と聞かれたので、Noを選択。

Is there RAID on this computer?
→ No

/bootを見つけた、と宣言されたので、そうですかとOKをクリック(ここは選択肢なし)。

/boot detected. Please check the options.

ツールが起動したところで、Advanced optionsのあたりをクリックする。

• 

GRUB locationタブをクリックし、起動するOSと、UEFI用に作ったパーティションが正しく選択されていることを確認して、Applyボタンをクリックする。
他のシステムでは /boot partition が表示されたりされなかったり、表示されても選択されていなかったりしたが、仮にその領域に何かが入っていたとしても使われないだけだでしょ？と気にせずに進める。

• 

この選択で良いの？と聞かれるが、なぜ聞いてきているのかが分からなかった。
一度戻って色々見てみたが、どこが関係するのか分からなかったので、進めるためにYesと回答。

BIOS-Boot detected. You may want to retry after deactivating the [Separate /boot/efi partition:] option.
Are you sure you want to continue anyway?

BIOS-Bootが検出されました。Separate /boot/efi partition:」オプションを無効にしてから再試行してください。
本当にこのままでいいのですか？

しばらく待つと、このウィンドウが表示された。

• 

Please open a terminal then type (or copy-paste) the following commands:
ターミナルを開き、以下のコマンドを入力(またはコピーペースト)してください。

If a window similar to the one below appears, use Tab and Enter keys in order to confirm GRUB removal.
以下のような画面が表示されたら、TabキーとEnterキーを使ってGRUBの削除を確認してください。

この画面が表示されたら、LXTerminalを起動して、コマンドをコピー＆ペーストする。
実際にペーストしてみると、最後の改行がないので、コマンドが入力されているその行で[Enter]キーを押す。

画面で説明されている通り、LXterminal画面の中でGRUBを削除するかどうか聞かれるので、YESを選択して進める。
処理が終了したら、Forwardボタンをクリックする。

追加のコマンド入力を要求された。

• 

Now please type (or copy-paste) the following command in a terminal:

ターミナルで以下のコマンドを入力(またはコピーペースト)してください。

ターミナルにコマンドをコピー&ペースとして実行する。
処理が終了したら、Forwardボタンをクリックする。

レポートをアップロードするかどうか聞かれた。感謝の気持ちを込めてアップロードするのもありだと思う。

Upload the report to a pastebin?

レポートをpastebinにアップロードする？

修復成功のメッセージが表示される。OKをクリックする。

Boot successfully repaired.
A new file (/var/log/boot-repair/20210815_093256/Boot-info_20210815_0932.txt) will open in your text viewer.
In case you still experience boot problem, indicate its content to: boot.repair@gmail.com or to your favorite support forum.
You can now reboot your computer.
Please do not forget to make your UEFI firmware boot on the Ubuntu 20.04.2 LTS entry (sda4/EFI/ubuntu/shimx64.efi file) !

ブート修復に成功しました。
新しいファイル(/var/log/boot-repair/20210815_093256/Boot-info_20210815_0932.txt)がテキストビューアで開きます。
それでもまだ起動に問題がある場合は、このファイルの内容を boot.repair@gmail.com またはお気に入りのサポートフォーラムにご連絡ください。
これでコンピュータを再起動することができます。
UEFIファームウェアをUbuntu 20.04.2 LTSのエントリ（sda4/EFI/ubuntu/shimx64.efiファイル）で起動することを忘れないでください。

ツールが終了すると、ログファイルが表示される仕組みになっているらしい。
処理が成功したので気にせずに閉じてしまったが、問題発生時にはこれを読み込むことになるだろう。

システムをシャットダウンすると、メディアを取り出してENTERを押すように言われるが、VMからは外れているので、そのまま[Enter]キーを押す。

仮想マシン起動時の表示をサーバーのそれに戻す

起動時にディスク接続しないように設定した上で、仮想マシンを起動。

んんん？

[   34.753090] cloud-init[1151]: Cloud-init v. 21.2-3-g899bfaa9-0ubuntu2~20.04.1 running 'modules:config' at Sun, 15 Aug 2021 10:12:17 +0000. Up 34.45 seconds.
[   35.698569] cloud-init[1156]: Cloud-init v. 21.2-3-g899bfaa9-0ubuntu2~20.04.1 running 'modules:final' at Sun, 15 Aug 2021 10:12:18 +0000. Up 35.51 seconds.
[   35.698988] cloud-init[1156]: Cloud-init v. 21.2-3-g899bfaa9-0ubuntu2~20.04.1 finished at Sun, 15 Aug 2021 10:12:18 +0000. Datasource DataSourceNone. Up 35.69 seconds.
[   35.699224] cloud-init[1156]: 2021-08-15 10:12:18,323 - cc_final_message.py[WARNING]: Used fallback datasource

Ubuntuは起動しているみたいだけど…どういうことだろ？と思って、[ALT]+[F1]を押してみたところ、loginプロンプトが表示されている。
どうもこれは最初にtty7が表示されてびっくりした、というだけのことの模様。

ログインして、grubの設定を変更。
/etc/default/grub

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"

※一般(Desktopをインストールしている人達)にはこれが喜ばれるし、サーバー管理者なら気付いて直せるだろ、という設定になっていただけと思われる。

設定を反映させて再起動する。

$ sudo update-grub
$ sudo reboot

これで、いつもの動作で起動するようになった。UEFIだと画面が広くなり、表示される情報がとても増えた。

他のVMの設定をすべて変更

UEFIでの起動方法が分かったので、動作しているサーバー群をこれまでに書いた方法ですべて設定変更した。
すべてのサーバーがUbuntuなので、すべて同じ手順で回復することができた。

これで問題解消。すべてのサーバーが稼働し始めた。良かった良かった。

起こったこと

Nested ESXiのUIにアクセスしようとすると、こんな応答が。

503 Service Unavailable (Failed to connect to endpoint: [N7Vmacore4Http16LocalServiceSpecE:0x00847250] _serverNamespace = / action = Allow _port = 8309)

なかなかサービスが始まらないな、と思ったら、コンソールからSystem Customizationに入り、Restart Management Networkを実行すると復旧する。

サービスが起動するその瞬間にDHCPがIPアドレスを渡せていないのかな…
ということで、固定IPアドレスを与えてみたら問題は発生しなくなった。

なお、本番環境(固定IPアドレス)でも発生したのだが、これは待っていたら解決した。

さいごに

実に手間が掛かったけれども、なんだかとても安定した環境になったと思える。

一見動いているようだけれども結果は ALL ZERO みたいなものはなく、できる・できないがはっきりしていて、それぞれに対処しながら動かすというのは、面倒だけれども安心。