仮想マシンをハードストップすると HA Failover が発生して対象の仮想マシンが自動で再起動する

 

Hard Stopについて

 

下記のブログにある通り、vSphere 7 から GUI に Hard Stop （強制終了）のアクションが追加されている。

https://virtualhive2.wordpress.com/2021/01/25/vmware-%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3%E3%81%AE%E5%BC%B7%E5%88%B6%E7%B5%82%E4%BA%86%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/

 

vSphere HAとの関連と動作検証

vSphere HA が有効な状態で Hard Stop をすると自動で対象の仮想マシンが再起動される挙動になる

 

検証した環境

# vmware -vl

VMware ESXi 7.0.2 build-17867351

VMware ESXi 7.0 Update 2

 

検証内容

GUI上から仮想マシン（VM名: test vm for ha）を Hard Stop すると、実施直後に該当VMの電源状態の変化を検知している様子を確認できる（HA Master（GUIの表示だとPrimary）の fdm.log）

※余談だが、vSphere 6.7のGUIでは Master/Slave だったが、vSphere 7.0以降では Primary/Secondary 表記になっている模様。

 

2022-01-06T05:15:28.706Z verbose fdm[7783908] [Originator@6876 sub=Invt opID=SWI-4d13fd14] Marking protected Vm /vmfs/volumes/vsan:5238a57de3afea77-94b3102835c92c88/0d4cd661-263a-b225-1f2d-0c42a162cc10/test vm for ha.vmx as in unknown power state

 

その後、該当仮想マシンの起動リクエストが生成されている

2022-01-06T05:15:58.727Z info fdm[7783894] [Originator@6876 sub=Policy] Sending a list of 1 VMs to the placement manager for placement

2022-01-06T05:15:58.727Z info fdm[7783894] [Originator@6876 sub=Placement] 1 Vms added, 1 VmRecord created

2022-01-06T05:15:58.727Z verbose fdm[7783894] [Originator@6876 sub=Placement] Invoking the RPE + SPE Placement Engine

2022-01-06T05:15:58.727Z verbose fdm[7783894] [Originator@6876 sub=Placement] Reevaluate all to-be-placed Vms.

2022-01-06T05:15:58.727Z verbose fdm[7783894] [Originator@6876 sub=Placement] Issue failover start event for 1 Vms

2022-01-06T05:15:58.727Z verbose fdm[7783894] [Originator@6876 sub=Placement] Created a new placement request. Request ID 6

2022-01-06T05:15:58.727Z verbose fdm[7783894] [Originator@6876 sub=Placement] Added Request 6 to record repository

2022-01-06T05:15:58.727Z info fdm[7783894] [Originator@6876 sub=Placement] Request 6 was accepted by Placement Service.

 

 

仮想マシン起動の優先順位設定と、起動可能なESXiのコンパチがチェックされる

2022-01-06T05:15:58.733Z verbose fdm[7784389] [Originator@6876 sub=Placement opID=SWI-12004d77] 1 Vms have priority 3

2022-01-06T05:15:58.733Z verbose fdm[7784389] [Originator@6876 sub=Placement opID=SWI-12004d77] 1 Vms are to be powered on

2022-01-06T05:15:58.733Z verbose fdm[7784389] [Originator@6876 sub=Invt opID=SWI-12004d77] Compat list for /vmfs/volumes/vsan:5238a57de3afea77-94b3102835c92c88/0d4cd661-263a-b225-1f2d-0c42a162cc10/test vm for ha.vmx: host-20, host-10, __localhost__

 

 

起動が開始される

2022-01-06T05:15:58.739Z verbose fdm[7783892] [Originator@6876 sub=Execution opID=51ddc8dc-SWI-37ae0d81] Place /vmfs/volumes/vsan:5238a57de3afea77-94b3102835c92c88/0d4cd661-263a-b225-1f2d-0c42a162cc10/test vm for ha.vmx on host-10 (cmd ID host-18:6:3f8acb6)

 

 

冒頭に紹介したブログでは、Hard Stop は esxcli vm process kill --type=force --world-id=xxxxxxxx と等価だと説明しているとおり、 esxcli vm process kill --type=force --world-id=xxxxxxxx のコマンドで停止した場合でも、おなじように HA Failover が実施される。

 

 

この機能自体は、vSphere HA のHost Monitoring の Failure Reponse の設定と関連していて、Failure Response を無効にした場合は Failover で再起動されることはない。

またこの設定は VM Override で個別に設定も可能である。

 

 

 

 

vSphere 7.0以前の環境での挙動を確認

 

6.5 でも同じ挙動になるのかどうかを確認してみた。

6.5ではGUIからの Hard Stop はできないため、コマンド（esxcli vm process kill --type=force --world-id=xxxxxxxx）で実行した。

検証環境

# vmware -vl

VMware ESXi 6.5.0 build-15256549

VMware ESXi 6.5.0 Update 3

 

結果

vSphere 7と同じように 6.5でも強制停止したVMがFailover した。

6.7では試していないがおそらく同様の動作になると思われる。

コメント

コメントを投稿

このブログの人気の投稿

vSwitchにSTPが不要な理由

イメージ
  ** 知っている人にとっては当たり前の内容です**     ESXiは多くの場合、冗長構成をとるために二つ以上のNICを利用し、それぞれ単一、もしくは別個の物理スイッチに接続されていると思います。 ESXiの物理NICはuplinkまたはvmnicとよばれ、ESXi内部にある仮想スイッチ（vSwitch）につながっています。 vSwitchはL2SWとしての役割をするため、物理スイッチをESXiの接続はスイッチ間接続となります。   図１：ネットワークトポロジ     vSwitchが物理スイッチと同等の動作をすると仮定した場合、この構成はループに相当します。 L2レベルでループがある場合は、ブロードキャストストームなどの問題が発生するためにSpanning Tree Protocol（STP）を設定する必要（最近では必ずしもそうとは言い切れないようですが。。。）があります。   ではvSwitchの場合でもSpanning Treeに参加する（ネットワークは専門外なので表現が間違っていたらすみません。。。）必要があるのでしょうか？ 表題からもわかるように答えはNoです。 L2ネットワークでBPDUと呼ばれるパケットをやり取りすることで Spanning Treeが構成されますが、実際に、vSwitchではこのBPDUをDropしますので、vSwitchのUplinkがBlockされることはありません。   ではなぜ、vSwitchではトポロジ的にLoopであるにもかかわらずSpanning Treeが不要なのでしょうか？Loopによる問題は発生しないのでしょうか？   実はvSwitchはFloodingが必要な通信に対して特殊な動作をします。 その特殊動作のため、トポロジ的にLoopであっても問題は発生せず、Spanning Treeに参加する必要がないのです。   たとえば、ARPなどの外部からのブロードキャストフレームをuplink経由でvSwitchが受け取った場合、vSwitchに接続されるVMに対してはフレームを転送しますが、ほかのUplinkに対してはフレームを転送しません。   下図ではUplink1からBroadcast Packetを...
続きを読む

ESXi に DNS サーバを何個まで登録できるか

イメージ
ESXi の DNS サーバの最大登録可能数を調べる vSphere 構築経験のある多くの方は2つまでとお答えになるかもしれない。 なぜならば、DCUI や vSphere Client から設定した場合、Primary DNS と Alternative DNS の2つまでしか設定できないからだ。 GUI から設定する場合、苦し紛れにカンマ区切りなどで3つ以上登録しようと試みても無駄である。GUI でエラーになってはじかれるだけだ。 ならば、CLI はどうか。 /etc/resolv.conf に手動で追記していくだけであればストレージの許す限り記載することはできるだろうが、 この方法は当然ながら標準的な手順ではない。 esxcli を利用して DNS を登録することも可能である。具体的には以下のコマンドを利用する esxcli network ip dns server add -s <ip_address> 上記のコマンドを利用してどこまで登録可能かを試してみた。 具体的には以下のコマンドを用いて255個のDNSサーバを追加してみた for i in `seq 1 255`; do esxcli network ip dns server add -s 192.0.2.$i ;done なお、本ブログで記載される IP Address は例示用に予約されたものであり、RFC5737 から拝借している。 結果として、少々時間はかかるが登録自体は問題なく成功した。 実環境においてこれほど多くの DNS の登録をすることはあり得ないので、事実上制限なしと考えられる。 なお、参考のために他ベンダーも含める形で DNS 登録数の最大数を調べたところ、2 か 3 にしているところが多いようだ。 DNS を大量に登録した際の動作を調べる DNS クエリのタイムアウト時間：5 秒則 ESXi の DNS Client は最近の systemd-resolved などではなく、レガシーなソフトウェアであるため、 resolv.conf の上から順番に問い合わせていき、問合せ先の DNS に到達できなかった場合に次の DNS サーバに問い合わせる動作になる。 次の DNS サーバに問い合わせる条件はあくまでも到達できなかった場合であり、到達できた...
続きを読む

vSAN OSA更改時の考慮事項

  この投稿は、 vExperts Advent Calendar 2025 の 8 日目です。 文字ばかりですがご容赦ください     この記事の概要 VCF9 のリリースによって vSAN OSA の一部の Hybrid 構成が Deprecate になった。 そのため、 OSA 環境の更改においては ESA へのトランジションの検討が盛んになっている。 一方で、 ESA へのトランジションにおいては、 HCI のメリットの一つであるシームレスな更改手法（玉突き方式）がつかえない、といった 考慮事項も存在する。 本記事では、 vSAN クラスタの更改時によくある考慮事項を紹介する。   想定既存環境 以下のようなサンプル環境の更改を想定する   vSAN OSA クラスタ（ vSAN Ready Node 、クラスタ内の全ノードが更改対象） ライセンスはリテール版を利用し、 HW と更改時期がずれているため、更改対象ではない。 外部ストレージは無し TOR スイッチの HW 更改の対象に含める   ※ OEM ライセンス利用時や、 vSAN Ready Node より上位となる専用アプライアンスを利用している場合、 ライセンスや保守サービスにかかわる考慮事項が追加され、より複雑となることがあるが、本記事では考慮しない。   更改パターン   移行方法とストレージアーキテクチャをベースに大別すると以下の 4 パターンが考えられる。   OSA 玉突き更改 OSA 新規クラスタ ESA 新規クラスタ 分離型新規クラスタ（ vSAN MAX or 外部ストレージ）   更改パターンを選択する際の考慮事項を次項に列挙する     考慮ポイント 実績と安定性 OSA と外部ストレージ構成は実績や安定性の観点で申し分ない ESA も 2022 年にリリースされて以来、大きな不具合もなく現在に至る印象があるが実績の面では OSA や外部ストレージが勝る トラブルシューティングに関しても OSA/ ...
続きを読む