ESXi 6系で、起動時間が一番早いバージョンは?

CJです。

約半年前にリリース(2018.4.7)された vSphere 6.7 には、”Quick Boot” という新たな機能が追加されたこと、知っていますか?

今日は “Quick Boot” 機能をみて、ふっと純粋に以下の疑問が沸いたので検証してみた結果を共有したいと思います。

その疑問は、”ESXiの各バージョンごとに、起動時間の違いはあるだろうか?”

その前に、まずは Quick Boot について簡単に紹介させてください。

vSphere 6.7 新機能: Quck Boot

vSphere 6.7 improves efficiency at scale when updating ESXi hosts, significantly reducing maintenance time by eliminating one of two reboots normally required for major version upgrades (Single Reboot). In addition to that, vSphere Quick Boot is a new innovation that restarts the ESXi hypervisor without rebooting the physical host, skipping time-consuming hardware initialization.

上記、VMware vSphere Blog からの引用となりますが、

要は物理ホストの再起動をせず、ESXi を再起動させる機能となります。

ハードウェアの初期化が省略されるため、ESXiのバージョンアップなどのメンテナンス時間が短縮される効果があります。 ちなみに、本機能はサポートされるハードウェアのみに活用できるようです。 ESXi 側で以下のコマンドにて、サポートされているかどうかの確認ができます。

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

特にインフラ管理者には嬉しい機能かと思うので、ぜひお試しください。

検証構成

・比較対象の 各ESXi は vSAN上の Nested 環境で用意してあります。

・各ESXi は同一物理ホスト上で動いてあります。

・各ESXiのスペックは、2Core、4GB ram で同一。

・各 ESXi のバージョンは、以下の通りです。

バージョン Build ESXi名
6.0U3 5572656 esxi09
6.5U1 5969303 esxi08
6.5U2 8294253 esxi07
6.7U1 10302608 esxi06

測定内容

・測定1 : ESXi が停止状態から起動完了までの “起動時間 (秒)”

・測定2 : ESXi が起動状態から再起動完了までの “再起動時間 (秒)”

測定方法

・測定1 : ESXi コンソール画面上で、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

・測定2 : ESXi コンソールの再起動直前の画面から、F11により再起動を開始して、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

測定結果

測定1 : なんと 6.0U3 のほうが、一番早かったです。

測定2 : 再起動は 6.7U1 のほうが、一番早かったです。

6.0U3 と 6.7U1 間には、微妙な誤差がありそうですが、6.5系と6.7U1間には差ほど大きいな違いはないようですね。数秒の差とはいえ、メンテナンスの際には規模によってこれも短縮したくなるのではないでしょうか。

[参考情報]

ESXi Hardware Requirements
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html

Quick Boot Compatibility
https://kb.vmware.com/s/article/52477

Introducing VMware vSphere 6.7!
https://blogs.vmware.com/vsphere/2018/04/introducing-vmware-vsphere-6-7.html

ESXi に残っている vSAN情報を削除するには?

CJです。

vSANクラスター配下で動いている ESXi ホストを、クラスター外に持ち出すケース(クラスター内のホストを別環境に転用したい場合など)があると思います。

今日はその際に使える簡単な Tipを紹介したいと思います。

vSANクラスターから ESXi ホストを外す流れ

1.対象ESXi ホストをメンテナンスモードに切り替え

2.対象ESXi の DiskGroup を削除

3. Drag&Drop にて、対象 ESXi ホストを vSANクラスター外に移動

基本はこれだけでよいはずですが、問題は次の事象です。

 

対象 ESXi 上での操作 (SSH接続)

以下のコマンドにて、vSAN情報が残っていないかを確認。

esxcli vsan storage list
この結果で、vSAN Disk情報が表示された場合は、以下のコマンドにて Disk情報を削除。
esxcli vsan storage remove -u [DISKGROUPのUUID]
もし、vSAN Disk情報など何も表示されてはいないが、vSAN情報が残っていることで別のクラスター環境へ移動ができない場合は、”vdq -q” と “esxcli vsan cluster get” コマンドにて状況を確認。
vdq -q
[
{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Eligible for use by VSAN”,
“Reason” : “None”,
“IsSSD” : “1”,
“IsCapacityFlash”: “1”,
“IsPDL” : “0”,
},{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Ineligible for use by VSAN”,
“Reason” : “Has partitions”,
“IsSSD” : “0”,
“IsCapacityFlash”: “0”,
“IsPDL” : “0”,
},esxcli vsan cluster getCluster Information
Enabled: true
Current Local Time: 2018-11-05T09:33:53Z
Local Node UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Backup UUID:
Sub-Cluster UUID: 52dc722d-a2c0-XXXX-XXXX-XXXXXXXXXX85
Sub-Cluster Membership Entry Revision: 5
Sub-Cluster Member Count: 1
Sub-Cluster Member UUIDs: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Membership UUID: 1a9c835b-dd2f-XXXX-XXXX-XXXXXXXXXX20
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: a2a65e3c-33ed-XXXX-XXXX-XXXXXXXXXXf2 8 2018-11-05T09:15:51.659

 これで vSAN情報が残っていることがわかりました。
では、早速次のコマンドにて、vSAN情報を削除しましょう。
esxcli vsan cluster leave
これで削除が完了しました。
もう一度、vSANクラスター情報を確認してみると、以下の通りに削除されていることがわかります。
esxcli vsan cluster get
vSAN Clustering is not enabled on this host
上記コマンドは、vSphere 6.5U1 環境での動作確認済みのものとなります。
vSphere バージョンによっては、コマンドが変更されている可能性があります。
その際は、”-?” にて Help 情報を参照してください。