**** 留意事項 *****
こちらのブログの内容はDECN（Dell EMC Community Network）に投稿されたブログの再掲です。
DECNが近い将来に廃止となるためこちらに移行させていただいております。
内容についてはオリジナルの執筆当時のものとなりますので最新ではない場合がありますがご容赦ください。
仮想化のメリット
VMwareの仮想基盤を導入する最も大きなメリットは何でしょうか？
私はvMotionだと思います。
ハードウェアを抽象化することでソフトウェアとハードウェアを切り離し、仮想マシンの可搬性が実現されました。
物理サーバのメンテナンス時やリソース不足の際に仮想マシンをオンラインで移行することで、ダウンタイムなしでリソース増設や物理交換が可能になります。
vMotionができない？！
しかしながら、日々の運用の中でvMotionができないシチュエーションが存在します。
それはESXiがvCenterから管理不可状態になってしまった場合です。
vMotionはESXi単体の操作ではなく、複数のESXiにまたがる操作となるため、仲介者としてvCenterが必要なります。
したがって、vCenterから管理できなくなったESXi上の仮想マシンはvMotionができなくなってしまいます。
このような管理不可状態は、多くの場合ESXiの管理サービス（hostd）の動作不良によって引き起こされます。vSphere Web Clientから確認すると管理不可状態のESXiは”応答なし”もしくは”Not Responding”と表示されます。
応答なしのESXiで稼働する仮想マシンは切断状態（もしくはdisconnected）となりますが、あくまでvCenter目線でのステータスであり、仮想マシンの稼働状態とは関係ないのでご安心ください。
※hostdの不具合によるNot Respoding事象自体は、あくまでESXiの管理機能の縮退に相当するだけの事象ですので、対象ESXi上で稼働する仮想マシンの稼働には影響がなく、仮想マシンは問題なく稼働を続けられます。
また、vSANクラスタであった場合でもvSANデータオブジェクトへの可用性には影響がありません。
hostdサービスの再起動などで事象が改善すれば問題ないのですが、事象によってはどうしてもESXiの再起動が必要となる場合があります。
ESXiを再起動するためには稼働する仮想マシンを退避する必要がありますが、vMotionができないのでそれもできません。
このような場合はどうしたらよいのでしょうか？
とりあえず対応保留！？
結論から言って、vMotionできない状況でESXiの再起動が必要となってしまった場合は、仮想マシンのダウンタイムが避けられません。
とはいえ、すでに述べたように（筆者の想定してる）この事象の場合では、仮想マシンの稼働やvSANデータオブジェクトの可用性への影響はなく、ただちの対処が必要必要な状況ではありません。
即座に対処する必要がないだけでなく、また即座に対処（仮想マシンの停止）できない場合がほとんどですので、とりあえず対応を保留し、仮想マシンのダウンタイムを調整する、というのはほぼすべてのパターンで採用される暫定対応です。
では、実際にダウンタイムの調整が完了し、いざESXiの再起動を実施する場合はどのようにしたらよいでしょうか？
以下のパターンが考えられます。
① 仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる（ダウンタイム30分～数時間）
② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動（ダウンタイム数分～数十分）
③ 仮想マシンを強制的にPowerOff（Kill）し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）
④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）
GuestOS側からShutdownする理由
誤解を避けるためにまず用語を確認しておきます。私の記事の中では以下の意味で使用します。
Node：ESXiがインストールされた物理サーバ。VxRailの場合はPowerEdgeを使っています。（Quantaもあるけど）
ESXi： VMwareが提供するHypervisor。仮想マシンを作成し、管理し、実行する。ホストとも呼ばれることがある
仮想マシン：VMと略して呼ばれることもある。Hypervisorが提供する仮想ハードウェア。GuestOSを実行できる。
GuestOS：仮想マシン上で実行されるOS。WindowsやLinuxなど。
なぜこのタイミングで用語を確認したのかというと、仮想マシンとGuestOSの違いが明確に使い分けられていない場合や、そもそも用語が異なる場合があるからです（仮想OS、仮想ホスト、アプリなど。。。）
さて、本題にもどってvMotionができない場合はGuestOS側からShutdownする必要があると説明していますがなぜでしょうか。
本記事では主にhostdの不具合によるvMotion不可のケースを想定していますが、hostdが正しく動作していない場合、ESXiのCLIやWebClient GUIといったツールから対象の仮想マシンをShutdownすることができません。（hostdに依存しているため）
したがって、そのような場合に安全にGuestOSをShutdownするにはGuestOS側の機能を使うしかありません。
たとえばWindowsOSを稼働させている場合は、WindowsOSにRDPなどでログインしてShutdown操作をすることになります。
Linuxの場合はSSHでログインしてShutdownコマンドにて落とすのが一般的と思います。
ではもしRDPやSSHが無効でGuestOS側からShutdownができない状況だったら？
→その場合は強制的に落とすしか手段がありません。（仮想マシンのkill or ESXiごと強制再起動）
それなら初めから全部強制的に落とせばいいんじゃないの？と思われる方もいらっしゃるかもしれませんが、たとえばご自身のPCを落とすときに時間短縮になるといって、電源ケーブルを抜いたり、バッテリーを抜いたりして落とす人がいるでしょうか？
そのような無茶をした場合、作業中のファイルが破損してしまう場合がありますので、特殊な場合をのぞき、基本的にはきちんとシャットダウンしてから落とす必要があります。
本記事ではhostd不具合を前提とした、vMotion不可ケースの対応として、とりあえず静観or対応保留が可能であることと、ESXi再起動をともなう作業のためにはGuestOS側からのShutdownが推奨であることを説明しました。
次回からは①～④までの手順を説明していきます。
※下記URLから直接それぞれのページへ飛べます。
①仮想マシンをGuestOS側からShutdownし、ESXiの再起動完了後に再度起動させる（ダウンタイム30分～数時間）
② 仮想マシンをGuestOS側からShutdownし、即座に別のESXiで起動（ダウンタイム数分～数十分）
③ 仮想マシンを強制的にPowerOff（Kill）し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）
④ 仮想マシンごとESXiを強制的に再起動し、vSphere HAの機能で別のNodeにて即座に再起動させる。もしくは手動で起動する（ダウンタイム数分～数十分）