vMotionできない、、、そんな時。 （その④）

**** 留意事項 *****

こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。

DECNが近い将来に廃止となるためこちらに移行させていただいております。

内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。

前回よりだいぶ時間が空いてしまいましたが、本記事は以下の記事の続きです。前提条件や用語の確認などがありますので、前回記事を読んでいない方はご一読ください。

vMotionできない、、、そんな時。      （その①）

vMotionできない、、、そんな時。      （その②）

vMotionできない、、、そんな時。      （その③）

本記事では前回記事で説明した対処法である以下について説明します。

③ 仮想マシンを強制的にPowerOff（Kill）し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）

④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）

予告では③のみでしたが、似たような話なのでまとめることにしました。

今回の手順は基本的には前回記事の最後の手順（対象ESXi上の安全にShutdownできないVMの移動方法）と同様です。

本手順は稼働中のVMを強制的に落とす手順のためデータの破損が発生する可能性があります。したがって以下の注意事項があります。

基本的な注意事項は以下です。

・安全にシャットダウンできないVMに対して実施する。シャットダウンできる場合は前回記事に沿った対応をする

・実施する前に必ずデータの冗長性低下が起こっていないことを確認する。

・大事なデータは必ずバックアップをする

実施方法

事前の確認

1. vSphere Web ClientからvSANヘルスチェックを実施して、冗長性の低下したデータがないことを確認する
   • 確認方法は下記の前回記事の補足項目を参照してください。
   • vMotionできない、、、そんな時。      （その②）
2. 対象VMのデータのバックアップおよびDiskにコミット済みであることを確認する
   • 可能であればアプリケーションレベル・仮想マシンレベルのバックアップを取得する
   • 簡易的にスナップショットの取得でも可
   • 可能であれば仮想マシン負荷の低い時間帯を狙って実施する
   • 未コミットのデータを可能な限りDiskにコミットする（Linuxのsyncコマンドなど）
3. 対象VMにVCSA/PSCが含まれる場合は事前にEphemeral Portを作成する
   • 手順については前回記事の 「対象ESXi上のVCSA/PSCがある場合の移動方法」を参照ください

ESXiごとShutdownする手順

事前の準備・確認が完了したらいよいよ仮想マシンを強制的に落とします。

一番簡単な方法はホストであるESXiごと落としてしまうことです。

手順については前回記事の「対象ESXi上の安全にShutdownできないVMの移動方法」を参考にしてください。

全仮想マシンがすべて停止し、vSphere HAが有効な場合は別のESXiホストでVMが再起動します。

vSphere HAが無効な場合は対象ESXiホストの再起動が完了したのちに、手動で起動してください。

vSphere HAが有効なのに仮想マシンが再起動されなかった場合は以下の理由が考えられます。

• アフィニティルールによる稼働可能なESXiホストの制限
• アドミッションコントロールによる制限
• 古いESXiがLockを保持したままになっている場合
  • 参考：ネットワールド　らぼ: VMware ESXiのロック機構とフリーズした仮想マシンの強制停止方法

各仮想マシンを個別に停止する方法

状況によっては各VMを一つずつ停止したい場合もあると思います。その場合は対象ESXiホストにSSHかESXi Shellでログインし、Killを実施する必要があります。

仮想マシンの個別のKillについては以下が参考になります。

• VMware KB https://kb.vmware.com/s/article/1014165?lang=ja
• ネットワールド　らぼ: VMware ESXiのロック機構とフリーズした仮想マシンの強制停止方法

killした後の挙動については状況に依存します。状況によっては障害によってすでにバックグラウンドでHAジョブが開始されており、仮想マシンファイルのロック取得待ちとなっている場合があります。この場合は仮想マシンが停止するとHAジョブにより別のホストで再起動されます。

状況によってはHAジョブが開始されていない場合もありますので、その場合は手動にて他のHostに再登録および起動とネットワークアダプタの再設定を実施する必要があります。

手順については前回記事の「対象ESXi上の安全にShutdownできるVMの移動方法」のステップ2以降をご参照ください。

いかがでしたでしょうか。一応今回でこのシリーズは終了となります。

仮想化技術の発展によってサーバの可用性と可搬性が向上し、多くのメリットを享受できるようになりましたが、一方で今回の一連の記事で想定している障害のように、ハイパーバイザーに起因する不具合によって、物理サーバにはなかったダウンタイムが発生してしまう場合もあります。

しかしながら物理サーバ時代の不便さと比べれば、仮想化のメリットは非常に大きく、管理負荷低減やサービスレベルの向上が実現されていることも事実とおもいます。

hostdの不具合によるvMotion不可という事象は、仮想化基盤の管理者であれば一度は経験し、かつお客様にとっては対処に困る障害対応と思います。

本不具合だけで仮想化技術を嫌いにならず、長く付き合っていただければと思います。

もしhostd不具合などでvMotion不可となる事象が発生した際は、本記事によってお客様のストレス軽減や業務影響の低減に寄与できれば幸いです。