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

vSphere 6.5以降の環境から仮想マシンを OVAでエクスポートするには?

CJです。

いまさら感がありますが、vSphere 6.5 からは 仮想マシンをエクスポートする際に “OVF”のみがサポートされるようになっているようです。

vSphere6.0 までは、vSphere Client が使えて、仮想マシンをエクスポートする際に OVF or OVA どちらかのファイル形式が選択可能でした。これが、vSphere 6.5 からは vSphere Web Client のみをサポートすることになり、統合プラグイン関係で OVFのみをサポートする形に変わったようです。

とはいえ、やはりファイル1個で使いやすかった OVA は継続的に使いたいですし、移行先のクラウドが OVA のみ対応しているのあれば、なおさらです。

このような状況を踏まえ、vSphere6.5 以降の環境で動いている仮想マシンを OVA にエクスポートしたい方向けにその方法を共有したいと思います。

vSphere 6.5環境で動いている仮想マシンを oVA にするには?

早速ですが、その方法は以下のように、一度 OVFでエクスポートし、それを ovftool を使って OVA に変換することです。

 

 

事前準備

ovftool インストールを踏み台サーバーにインストールが必要です。

ここでは、踏み台サーバーとして Windows を例とします。 Linux または Mac OS X も各自の環境に合わせて適切なパッケージを使えば、使用可能です。

1.OVF Tool Documentation ページへ移動して、最新バージョンをダウンロード

2.ダウンロードしたインストーラーを実行して、インストール完了。

3.環境変数に PATH を登録する (手順は割愛します)と便利。

OVFエクスポート

vSphere Web Client から “仮想マシン > テンプレート > OVF 。。。” メニューからエクスポートを実施。ここでひとつTipとして、OVFエクスポートは HTML5版の vSphere Web Client を使用するのをお勧めします。フラッシュ版の場合、エクスポートのステータスや表示が正常に表示されないケースがあります。

OVAへの変換

OVFファイルの場所例: D:\CJ\powercli\ovftool\ovf\vcsa01_cj-lab.com.[ovf, mf, vmdk]

OVAファイルの変換先例: D:\CJ\powercli\ovftool\ova\vcsa01_cj-lab.com.ova

以下のコマンドを実行する。

>ovftool ./vcsa01_cj-lab.com.ovf ../ova/vcsa01_cj-lab.com.ova

すると、以下のようにコンバートが行われます。

最後に、”Completed successfully” メッセージが表示されれば、完了です。

いかがですか、とても簡単ではありませんか。

個人的にも OVAサポートは継続してほしいところですが、そこは vmwareさんに改善を期待しながら、今現時点ではこのような対策を活用いただければ嬉しいです。

 

[参考情報]

OVF Tool Documentation

https://www.vmware.com/support/developer/ovf/

VCS to VCSA : Windows版 vCenter から 仮想アプライアンス版 vCenterへの移行手順

CJです。

多く使われている Windows版 vCenter Server (以下、VCS)も次期 vSphereバージョンからはサポート外になるようです。現在、仮想アプライアンス版 vCenter Server (以下、VCSA)ではほとんどが VCSと変わらず使える状態ですが、マルチNICが正式サポートされていなかったり一部もの足りないところもあるのが現状です。しかし、いつか VCSAになること、ライセンス節約の観点からのメリットもあるので、各自の状況に合わせて移行をご検討いただければと思います。

今回は、この移行方法についてスクリーンショットとともに流れを共有したいと思います。

移行環境

VCS:Windows Server 2012 R2 / PSC組み込み / 別途 DBサーバー(SQL server)が存在 / vCenter 6.0 U2

VCSA: vCenter 6.5 U1

Client: Windows Server 2012 R2

移行イメージ図

移行手順

VCSAデプロイ手順

1.VCS上に、VCSA isoファイルより、”migration-assistant” フォルダをコピーし、VMware-Migration-Assistant アプリを実行する。

Tip: 移行前に、以下の内容を確認してください。

・DRS 無効化 / NTP 同期 / Default Gateway 設定 / もし、iptables 制御している方はそちらも要確認

2.Client PC (以下、Client) に、VCSAの isoファイルをマウントしてインストールファイルを実行。”CDROM : vcsa-ui-installer\win32\installer.exe”

3.移行を選択

4.VCSAのデプロイ / 次へ

5.エンドユーザー使用許諾契約書 / 同意にチェックを入れて 次へ

6.VCSの情報を入力して、次へ

サムプリントの検証画面が表示されたら、”はい” をクリック

7.デプロイ先の ESXi or vCenter 情報を入力 (ここでは ESXi 情報を入力しています。)

証明書に関する警告画面が表示されたら、”はい” をクリック

8.VCSA名と root パスワード情報を入力して、次へ

9.各自の環境に適した VCSAのサイズを選択して、次へ

10.データストアを選択して、次へ

11.ネットワーク構成情報を入力して、次へ

12.設定内容の確認ページが表示されるので、確認後問題なければ “終了” ボタンをクリック。そうすると、初期化された後デプロイが開始されます。

13.デプロイが完了されたら、次は VCSAへ接続します。

https://[VCSAのIPアドレス]:5480

ちなみに、デプロイされた VCSAのディスク構成はどうなっているでしょう。

小 (4 vCPU、16GB RAM)サイズでは、以下の構成となっていることがわかりました。

VCSA への移行手順

1.”Windows 上の vCenter Server インスタンスからの移行” を選択

2.上記手順 8 で設定した VCSAの root パスワードにてログイン

3.ステージ1が終わっている状態で、ステージ2になることを確認の上、次へ

4.VCSの情報を入力して、次へ

証明書に関する警告画面が表示されたら、”OK” をクリック

5.VCS上では、以下のように事前チェックが走っていることがわかります。

暫くすると、移行前チェックの結果が表示されます。

今回、VCS上では VMware Update Manager (以下、VUM)が使用中だったための警告が表示されていますが、スキップします。”閉じる”をクリック。

6.今回の移行では、設定のみ移行すればOKということで、次へ

7.CEIP 参加可否の画面が表示されますが、ここではチェックをOFFにして、次へ

8.設定の確認画面が表示されます。”ソースの vCenter Server をバックアップしました” のチェックボックスにチェックを入れて、終了。

シャットダウンの警告が表示されるので、”OK” をクリック。

VCSAは基本 VCSの情報を引き継ぐため、同一セグメントに置かれている VCSを起動前に止める動きとなっています。

9.VCSから VCSAへデーターコピーが行われます。(vSphere Web Client データのエクスポートなど)

10.VCSA の設定が行われます。

11.すべてのデーターが VCSAへインポートされてから、完了となります。

12.もし、以下のようなエラーが表示されたら、ブラウザのキャッシュをクリアしてみてください。

13.移行完了。

正常に vCenter 6.5 になっていることがわかります。

 

思ったより簡単に移行できそうではないでしょうか。

ぜひ、お試しください。

VCS (シャットダウン中)はそのまま残っている状態のため、もし移行が何らかの理由で途中失敗した場合でも簡単に切り戻しができるのもチャレンジしやすいところかと思います。

 

Tip:VCSでローカルアカウント設定を行っている場合は、移行前にユーザー権限を外してください。そうしないと、移行手順 9 のところ (vPostgres SQLあたり)で失敗する可能性があります。

 

[参考情報]

既知の制限事項

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-5E19B79A-AE4F-497A-9047-3E9AAC1D7767.html