ITよろづや

ITの参考になる情報を備忘録代わりに残していきます

ESXi 7.0 Update 2 メモリへの一時停止機能の使用で再起動後も仮想マシンのメモリ状態が保持される

ESXi 7.0 Update 2 メモリへの一時停止機能の使用で再起動後も仮想マシンのメモリ状態が保持されるという新しい機能が使えるようになっています。これにより、メンテナンス時に仮想マシンをvMotionする必要がないということになります。

 

情報元はこちら。

 

ESXi 7.0 Update 2(81555)の「メモリへの一時停止」機能の使用

https://kb.vmware.com/s/article/81555?lang=en_US

 

メモリへの一時停止は、ESXiホストを更新するときに使用することを選択できる機能です。これにより、vMotionを使用してVMを別のESXiホストに移行する代わりに、更新中のESXiホスト上のメモリで仮想マシンを一時停止できます。メモリへの一時停止機能では、再起動後も仮想マシンのメモリ状態が保持されるように、クイックブートが必要です。

 

この機能は以下のようなケースで使えます。

 

・更新をエンドツーエンドではるかに高速に完了するため。
・vMotionに十分なリソースがない場合は、VMのダウンタイムを短縮します。

 

 

Suspend to Memoryの使用を選択できないか、修復の事前チェックでユーザーがSuspend toMemoryを続行できない

 

原因:サーバーのハードウェアやサーバーで実行されているワークロードなど、この機能の使用には特定の制約があります。

 

回避策:
①サーバーハードウェアがサポートされているリストにあることを確認してください。詳細については、「VMware vSphere 7.0 Update 2(82558)でサポートされているシステム」を参照してください 。

https://kb.vmware.com/s/article/82558

 

②修復の事前チェックを実行して、この機能が機能しない問題を特定します。vSphere製品ドキュメントの「メモリへのサスペンドを使用するための要件」セクションでは、メモリへのサスペンドの要件と制約について概説しています。ハードウェアがサポートされていない場合、または別の要件を満たせない場合は、Suspend to Memoryを無効にして、この機能を使用せずに修復を完了してください。可能であれば、要件に対処してから、Suspend toMemoryを使用して修復を再試行してください。

 

ホストとワークロードがメンテナンスモードから抜け出すまでの時間が予想よりも長い

原因:メモリサイズ、VMの数、ホストで実行されているソフトウェアサービスなど、完了までの時間に影響を与える複数のパラメータがあります。

回避策:vSphere High Availability(HA)機能は、定義されたタイムアウト内に再起動が完了しない場合、別のホスト上のVMを再起動します。vSphere製品ドキュメントの「メモリへのサスペンド」および「vSphereHighAvailability(HA)」セクションでは、この動作とこのタイムアウトの構成について詳しく説明しています。

 

まれに、ホストが完全な再起動を実行し、vSphere HighAvailabilityによってVMが再起動されます

原因:システムがクイックブートを完了できず、完全な再起動に頼らなければならないというまれなケースがあります。フルリブート後、メモリの内容は保持されず、メモリに一時停止されているVMは一時停止状態から再開できません。これらのVMは、新たに電源がオンになります。

回避策:
メモリへのサスペンドを使用して修復を実行する前に、VMのメモリスナップショットを作成します。ホストが完全な再起動に頼る場合は、スナップショット時のVMのメモリ状態を復元できます。HAが有効になっている場合、これは自動的に行われます。そうでない場合は、スナップショットを元に戻す方法について、vSphere製品ドキュメントの「スナップショットの管理」セクションを参照してください。
修復前にメモリスナップショットが作成されなかった場合、VMの電源が新たにオンになり、サスペンド時のメモリ状態は保持されません。この状況でVMが期待どおりに動作していることを確認します。