はじめに
vSphere 8 で vSphere vMotion Notifications と呼ばれる機能が追加されました。
- vSphere vMotion Notifications | VMware
- Virtual Machine Conditions and Limitations for vSphere vMotion
ざっくりとは、 vMotion に耐えられないアプリケーションが動作している VM 向け の機能で、ゲスト OS に vMotion の事前準備と事後処理を行う機会を与える ものです。ESXi は、vMotion がトリガされると対象のゲスト OS に通知し、その通知に対するゲスト OS からの応答(Acknowledgement)が返ってくるまで実際の移行処理を遅延させます。ゲスト OS 目線では、通知を受けたら必要な事前準備を行い、その後に応答を返すことで、vMotion に安全に備えられることになります。その後の移行処理の完了も別途通知を受け取れるため、事後処理も行えます。
この仕組みにより、厳しい動作要件があって vMotion に耐えられなかったアプリケーションも、vMotion を乗り越えられるようになる…… ということのようです。例えば、複数ノードでクラスタ化されているアプリケーションで、vMotion の前後でクラスタからの離脱と再参加を自動で行うようなイメージですね。
自宅に何かそういう厳しいアプリケーションがあるわけではないのですが、おもしろそうな機能なので実際に触ってみました。本エントリでは実際の設定や動作を紹介します。
目次
基本的な動き
vSphere vMotion Notifications のおおまかな動きは次の通りです。
- vCenter Server で vMotion がトリガされると、ESXi は 対象の VM で動作する VMware Tools(または Open VM Tools)に vMotion の開始を通知 する
- ESXi は その通知に対する応答(Acknowledgement)が返ってくるまで実際の移行処理を遅延 させる
- ESXi は応答が返ってきたら移行処理を行い、vMotion が終了したら 終了も通知 する
vSphere 側の責任範囲はこれだけなので、つまり、通知を受け取ってからのゲスト OS 内の処理 は 利用者の責任で実装が必要 ということになります。具体的には次のような処理です。
- 通知の有無を定期的に確認する処理
- vMotion の開始の通知を受けて、アプリケーション向けに必要な事前準備を行う処理
- 事前準備が完了してから応答(Acknowledgement)を返す処理
- vMotion の終了の通知を受けて、アプリケーション向けに必要な事後処理を行う処理
なお、vMotion がいちどトリガされると、ESXi は ゲスト OS からの応答がなくてもタイムアウトを迎えると移行処理を強制的に開始します(つまり、ゲスト OS 側から vMotion を中止する手段はありません)。このときのタイムアウト値は ESXi ホストと VM の二か所 で設定でき、両方で設定されている場合は 値が小さいほうが採用 されます。当然ながら、具体的な設定値は、ゲスト OS 内での事前準備に必要な時間を基に利用者側で検討が必要です。
動作要件
ドキュメントにも一部記載がありますが、動作要件は以下のようです。
- vSphere 8.0 以降
- 仮想ハードウェアバージョン 20 以降
- VMware Tools(または Open VM Tools)11.0 以降
条件を満たしていれば、ゲスト OS は Linux でも Windows でも動作 しました。
vSphere vMotion Notifications の有効化
vSphere vMotion Notifications を利用するには、VM ごとの設定 に加えて、その VM が動作しうる ESXi ホストごとにも構成が必要 なようです(ドキュメントの表現では ESXi ごとの設定が必須であるようには読めませんでしたが、実際に試した範囲では必須っぽかったです)。
必要な作業は次の通りです。
- 対象 VM が動作しうる 全ての ESXi ホスト にタイムアウト値(
VmOpNotificationToApp.Timeout
)を設定する(必須) - 対象 VM に通知を有効化する設定(
vmOpNotificationToAppEnabled
)を入れる(必須) - 対象 VM に VM ごとのタイムアウト値(
vmOpNotificationTimeout
)を設定する(任意)
設定変更の手段
本エントリ執筆時点では、PowerCLI や PyVmomi や Govc の vSphere 8 のサポートは充分ではなく、前述の設定は残念ながらなかなか素直には変更できません。vCenter Server の Managed Object Browser を使うのが確実ですが、気軽に触るにはツラいので、今回は PowerShell 用のコマンドレットを作成しました。GitHub のリポジトリ に配置しています。
事前準備として、スクリプトモジュールをダウンロードしてインポートし、環境変数で vCenter Server の情報を設定します。vSphere Web Service API(WS API)を SOAP で直接叩いているので、PowerCLI は不要です。
# スクリプトモジュールのダウンロード
$url = "https://raw.githubusercontent.com/kurokobo/vmotion-notifications-poc/main/helper/VmOpNotification.psm1"
$file = "$env:Temp\VmOpNotification.psm1"
(New-Object System.Net.WebClient).DownloadFile($url, $file)
# スクリプトモジュールのインポート
Import-Module $file
# 接続先と認証情報を示す環境変数の設定
$env:VMWARE_HOST = "vcsa.example.com"
$env:VMWARE_USER = "vmotion@vsphere.local"
$env:VMWARE_PASSWORD = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR([System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($(Read-Host "Password" -AsSecureString)))
# (任意) vCenter Server の SSL 証明書の検証を無効にする設定
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
近いうちに PowerCLI でも PyVmomi でも Govc でも vSphere 8 対応は進むと思うので、早々に要らないスクリプトモジュールになりそうですが、取り急ぎ。
ESXi ホストの設定
対象 VM が動作しうる全 ESXi ホストで、タイムアウト値(VmOpNotificationToApp.Timeout
)を設定します。単位は 秒 です。
なお、デフォルトで 1800
が設定されているように見えますが、このままだと実際には 0
として扱われるようなので、変更は必須です(仕様かバグかわかりませんが、少なくとも 8.0 の IA / GA リリースではそのような動きでした)。
# 現在のタイムアウト値の確認
Get-VMHostVmOpNotification -Name <HOST_NAME>
# タイムアウト値の設定 (VmOpNotificationToApp.Timeout = <VALUE>)
Set-VMHostVmOpNotification -Name <HOST_NAME> -Timeout <VALUE>
vMotion の移行元と移行先の ESXi ホストでタイムアウト値が違う場合は、動きを見る限りは 移行元 の値が採用されるようです。
VM の設定
vSphere vMotion Notifications は、VM 単位で明示的な有効化が必要です。また、ESXi ホストに設定したタイムアウトよりも特定 VM のタイムアウトを短くしたい場合は、VM 単位でもタイムアウトを設定できます。
# 現在の vSphere vMotion Notifications の有効状態を確認
Get-VMVmOpNotification -Name <VM_NAME>
# vSphere vMotion Notifications の有効化 (vmOpNotificationToAppEnabled = true)
Set-VMVmOpNotification -Name <VM_NAME> -Enabled "true"
# vSphere vMotion Notifications の無効化 (vmOpNotificationToAppEnabled = false)
Set-VMVmOpNotification -Name <VM_NAME> -Enabled "false"
# タイムアウト値の設定 (vmOpNotificationTimeout = <VALUE>)
Set-VMVmOpNotification -Name <VM_NAME> -Timeout <VALUE>
ゲスト OS での通知の操作
ESXi と VM に設定が入れば、ゲスト OS で通知を受け取る準備は完了です。ここからは、ゲスト OS 側での実施が必要な操作です。これには、VMware Tools(または Open VM Tools)に含まれる vmtoolsd
コマンドを利用します。
以下、 Linux の Bash での操作例です。VMware Tools(または Open VM Tools)が入っていれば vmtoolsd
にもデフォルトでパスが通っているようなので、愚直にコマンドを叩いていけば動作します。
Windows では、vmtoolsd
はデフォルトで C:\Program Files\VMware\VMware Tools\vmtoolsd.exe
として配置されています。操作方法は Linux のそれとまったく一緒ですが、コマンドプロンプトにしても PowerShell にしてもクォート周辺のエスケープがたいへんしんどいので、--cmd
ではなく --cmdfile
を利用した操作(後述)をおすすめします。
アプリケーションの新規登録と登録解除
ゲスト OS 側で通知を受け取るには、前提としてアプリケーションの登録が必要です。任意の名前を付けて register
コマンドを実行します。以下では例として demo
としています。notificationTypes
は正直よくわかりませんが、とにかく sla-miss
とすれば動作しました。
$ vmtoolsd --cmd 'vm-operation-notification.register {"appName": "demo", "notificationTypes": ["sla-miss"]}'
{"version":"1.0.0", "result": true, "guaranteed": true, "uniqueToken": "525b5364-6caf-24a0-562c-87955647baa4", "notificationTimeoutInSec": 120 }
登録できると、トークン(uniqueToken
)が発行されます。これは後続の操作で必要ですが、登録時しか表示されない ため、何らかの形で保持しておくと安心です。
登録されているアプリケーションの情報は、list
コマンドで確認できます。登録できるアプリケーションは VM ごとにひとつのみ です。
$ vmtoolsd --cmd 'vm-operation-notification.list'
{"version":"1.0.0", "result": true, "info": [ {"appName": "demo", "notificationTypes": ["sla-miss"]}] }
再登録したくなった場合などは、トークンを渡して既存のアプリケーションの登録を unregister
コマンドで解除します。
$ vmtoolsd --cmd 'vm-operation-notification.unregister {"uniqueToken": "525b5364-6caf-24a0-562c-87955647baa4"}'
{"version":"1.0.0", "result": true }
通知の有無の確認
アプリケーションを登録すると、発行されたトークンを使って、check-for-event
コマンドで通知の有無を確認できるようになります。
$ vmtoolsd --cmd 'vm-operation-notification.check-for-event {"uniqueToken": "525b5364-6caf-24a0-562c-87955647baa4"}'
この実行結果には、通知の有無によって以下のようなパタンがあります。なお、check-for-event
コマンドの実行間隔次第では複数の通知が滞留する状況も想定されますが、その場合でもコマンド一回ごとに 古い通知から一つずつ順に取得される ようです。
# 通知が何もないとき
{"version":"1.0.0", "result": true }
# vMotion の開始の通知
{"version":"1.0.0", "result": true, "eventType": "start", "opType": "host-migration", "eventGenTimeInSec": 1666730185, "notificationTimeoutInSec": 120, "destNotificationTimeoutInSec": 120, "notificationTypes": ["sla-miss"], "operationId": 6279072692702276663 }
# vMotion の完了の通知
{"version":"1.0.0", "result": true, "eventType": "end", "opType": "host-migration", "opStatus": "success", "eventGenTimeInSec": 1666730200, "notificationTypes": ["sla-miss"], "operationId": 6279072692702276663 }
# タイムアウト値の変更の通知
{"version":"1.0.0", "result": true, "eventType": "timeout-change", "eventGenTimeInSec": 1666736715, "notificationTimeoutInSec": 120, "newNotificationTimeoutInSec": 60, "notificationTypes": ["sla-miss"], "operationId": 1666736715415723 }
通知への応答
"eventType": "start"
の通知を受け取ってから vMotion の事前準備ができたら、準備の完了を ESXi 側に ack-event
コマンドで応答する必要があります。
このコマンドには、トークンだけでなく、"eventType": "start"
の通知に含まれていた operationId
も含める必要があります。
$ vmtoolsd --cmd 'vm-operation-notification.ack-event {"operationId": 6279072692702276663, "uniqueToken": "525b5364-6caf-24a0-562c-87955647baa4"}'
{"version":"1.0.0", "result": true, "operationId": 6279072692702276663, "ackStatus": "ack_received" }
補足: ゲスト OS 側で必要な実装
まとめると、ゲスト OS 側には以下のような仕組みが必要です。
check-for-event
コマンドを一定の間隔で定期的に実行する"eventType": "start"
の通知があれば vMotion の事前準備を行う- 事前準備が完了したら
ack-event
コマンドを実行する "eventType": "end"
の通知があれば vMotion の事後処理を行う
補足: Windows での通知の操作
Windows で PowerShell やコマンドプロンプトを使って vmtoolsd
を操作したい場合、前述のような --cmd
ではなく、--cmdfile
の利用がおすすめです。--cmd
に渡していた文字列をそのままテキストファイルに保存し、そのテキストファイルのパスを --cmdfile
で渡すだけです。
例えば、以下のコマンドを実行したいとき、
vmtoolsd --cmd 'vm-operation-notification.unregister {"uniqueToken": "525b5364-6caf-24a0-562c-87955647baa4"}'
以下の内容のテキストファイルを作成し、
vm-operation-notification.unregister {"uniqueToken": "525b5364-6caf-24a0-562c-87955647baa4"}
このファイルのパスを --cmdfile
で指定します。
> "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" --cmdfile "C:\Path\To\CommandFile.txt"
なお、Windows 上の Bash(Git Bash や WSL2 環境など)であれば、前述の Linux での操作例と同様に --cmd
でも素直に操作できます。
実際の操作と動き
ここから、実際の動きを確認します。
例として、VM vmotion-lnx01
で vSphere vMotion Notifications を有効化して、タイムアウトを 120 秒にしておきます。ESXi のタイムアウトは 300 秒にしています。
PS> Set-VMVmOpNotification -Name vmotion-lnx01 -Enabled "true" -Timeout 120
Name vmOpNotificationToAppEnabled vmOpNotificationTimeout
---- ---------------------------- -----------------------
vmotion-lnx01 True 120
PS> Set-VMHostVmOpNotification -Name kuro-esxi01.krkb.lab -Timeout 300
Name VmOpNotificationToApp.Timeout
---- -----------------------------
kuro-esxi01.krkb.lab 300
PS> Set-VMHostVmOpNotification -Name kuro-esxi02.krkb.lab -Timeout 300
Name VmOpNotificationToApp.Timeout
---- -----------------------------
kuro-esxi02.krkb.lab 300
手動での動作確認
まずは手動で動きを追いかけます。最初にゲスト OS からアプリケーションを登録します。
$ vmtoolsd --cmd 'vm-operation-notification.register {"appName": "demo", "notificationTypes": ["sla-miss"]}'
{"version":"1.0.0", "result": true, "guaranteed": true, "uniqueToken": "52377485-336c-62bb-9af8-11e1628bfe66", "notificationTimeoutInSec": 120 }
ゲスト OS で通知を毎秒モニタリングする while
ループを回しておきます。
$ while true; do vmtoolsd --cmd 'vm-operation-notification.check-for-event {"uniqueToken": "52377485-336c-62bb-9af8-11e1628bfe66"}'; sleep 1; done
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
...
この状態で vCenter Server から vMotion をトリガすると、ゲスト OS に通知が届くことが確認できます。
...
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true, "eventType": "start", "opType": "host-migration", "eventGenTimeInSec": 1668173173, "notificationTimeoutInSec": 120, "destNotificationTimeoutInSec": 120, "notificationTypes": ["sla-miss"], "operationId": 6279072931629801319 }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
...
vMotion のタスクは Migrating Virtual Machine active state
の状態で進行が一時停止しています。通知への応答を待っている状態です。
タイムアウトは、VM では 120 秒、ESXi では 300 秒に設定していました。両方に設定がある場合は小さい値が採用されるため、今回の実際のタイムアウトは 120 秒です(通知の notificationTimeoutInSec
でも確認できます)。ここで、120 秒以内にゲスト OS から ack-event
を実行します。
$ vmtoolsd --cmd 'vm-operation-notification.ack-event {"operationId": 6279072931629801319, "uniqueToken": "52377485-336c-62bb-9af8-11e1628bfe66"}'
{"version":"1.0.0", "result": true, "operationId": 6279072931629801319, "ackStatus": "ack_received" }
画面は割愛しますが、一時停止していた vMotion のタスクがこの段階で動作を再開することが確認できます。その後 vMotion が完了すると、ゲスト OS にも通知されます。
...
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true, "eventType": "end", "opType": "host-migration", "opStatus": "success", "eventGenTimeInSec": 1668173300, "notificationTypes": ["sla-miss"], "operationId": 6279072931629801319 }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
{"version":"1.0.0", "result": true }
...
基本的な動きが確認できました。
自動処理スクリプトでの動作確認
実運用では、uniqueToken
や operationId
の扱いを含め、通知の確認や事前準備、事後処理はすべて自動で行われるべきです。今回は、イメージアップしやすいように次のようなスクリプトを作りました。Linux 向けです(検証用であり本番利用は想定していません)。
- 指定した名前(
--name
)でアプリケーションを登録する - 指定した間隔(
--interval
)で通知を確認する start
の通知を受け取ったときに、指定したコマンド(--quiesce
)を実行し、完了後に応答を返すend
の通知を受け取ったときに、指定したコマンド(--unquiesce
)を実行する- スクリプトの終了時にアプリケーションを登録解除する
- 詳細な動作をログに保存する
実物は GitHub のリポジトリ に配置してあります。
必要な引数と共にスクリプトを実行すると、アプリケーションを登録し、通知の監視を開始します。
$ python3 handle_notifications.py --name demo --interval 10 \
> --quiesce "${PWD}/demo.sh -m quiesce" \
> --unquiesce "${PWD}/demo.sh -m unquiesce"
2022-10-29 07:04:03,025 [INFO] register application: demo
2022-10-29 07:04:03,035 [INFO] application has been registered with issued token: 52964f1a-6c7e-b373-b588-545b39581e1a
2022-10-29 07:04:03,035 [INFO] start monitoring at 10 second intervals (ctrl + c or kill to interrupt)
2022-10-29 07:04:03,035 [INFO] check if application is notified
...
この状態で vMotion をトリガすると、start
の通知を受けて、引数 --quiesce
で指定したコマンド ${PWD}/demo.sh -m quiesce
が実行されます。コマンドが完了すると通知に対する応答を返し、通知の監視を再開します。
...
2022-10-29 07:04:33,091 [INFO] check if application is notified
2022-10-29 07:04:33,111 [INFO] application is notified that vmotion has been requested and should be quiesced in 120 seconds. invoke command to quiesce
2022-10-29 07:04:33,116 [INFO] > Application HOGE is requested to be quiesced.
2022-10-29 07:04:33,116 [INFO] > Quiescing ... leaving target pool for load balancing ...
...
2022-10-29 07:04:39,140 [INFO] > Quiescing ... stopping service BAZ
2022-10-29 07:04:40,144 [INFO] > Application HOGE has been quiesced and ready for vMotion.
2022-10-29 07:04:40,144 [INFO] command to quiesce has been completed with return code: 0
2022-10-29 07:04:40,144 [INFO] acknowledge notification
2022-10-29 07:04:40,156 [INFO] got response: ack_received
2022-10-29 07:04:50,161 [INFO] check if application is notified
...
vMotion が完了して end
の通知を受け取ると、今度は引数 --unquiesce
で指定されたコマンド ${PWD}/demo.sh -m unquiesce
を実行します。
...
2022-10-29 07:04:50,172 [INFO] application is notified that vmotion has been completed and should be unquiesced. invoke command to unquiesce
2022-10-29 07:04:50,175 [INFO] > Application HOGE is requested to be unquiesced.
2022-10-29 07:04:50,175 [INFO] > UnQuiescing ... starting service BAZ
...
2022-10-29 07:04:56,190 [INFO] > UnQuiescing ... joining target pool for load balancing ...
2022-10-29 07:04:57,193 [INFO] > Application HOGE has been unquiesced and is in production.
2022-10-29 07:04:57,194 [INFO] command to unquiesce has been completed with return code: 0
2022-10-29 07:05:07,203 [INFO] check if application is notified
...
kill
や Ctrl + C
でスクリプトを終了すると、アプリケーションの登録を解除してから終了します。
...
2022-10-29 07:10:56,154 [INFO] interrupted
2022-10-29 07:10:56,154 [INFO] unregister application: demo
2022-10-29 07:10:56,164 [INFO] application has been unregistered
ログファイルには実際のトークンやコマンドなど詳細な情報が保持されます。
$ cat handle_notifications.log
2022-10-29 07:04:03,024 [DEBUG] monitor: application name: demo
2022-10-29 07:04:03,025 [DEBUG] monitor: command to quiesce: ['/.../examples/demo.sh -m quiesce']
2022-10-29 07:04:03,025 [DEBUG] monitor: command to unquiesce: ['/.../examples/demo.sh -m unquiesce']
2022-10-29 07:04:03,025 [DEBUG] monitor: monitoring interval: 10 second(s)
2022-10-29 07:04:03,025 [INFO] monitor: register application: demo
2022-10-29 07:04:03,025 [DEBUG] vmtoolsd: invoke command: ['vmtoolsd', '--cmd', 'vm-operation-notification.register {"appName": "demo", "notificationTypes": ["sla-miss"]}']
2022-10-29 07:04:03,034 [DEBUG] vmtoolsd: rc: 0
2022-10-29 07:04:03,034 [DEBUG] vmtoolsd: stdout: {"version":"1.0.0", "result": true, "guaranteed": true, "uniqueToken": "52964f1a-6c7e-b373-b588-545b39581e1a", "notificationTimeoutInSec": 120 }
2022-10-29 07:04:03,035 [INFO] monitor: application has been registered with issued token: 52964f1a-6c7e-b373-b588-545b39581e1a
2022-10-29 07:04:03,035 [INFO] monitor: start monitoring at 10 second intervals (ctrl + c or kill to interrupt)
2022-10-29 07:04:03,035 [INFO] monitor: check if application is notified
2022-10-29 07:04:03,035 [DEBUG] vmtoolsd: invoke command: ['vmtoolsd', '--cmd', 'vm-operation-notification.check-for-event {"uniqueToken": "52964f1a-6c7e-b373-b588-545b39581e1a"}']
2022-10-29 07:04:03,043 [DEBUG] vmtoolsd: rc: 0
2022-10-29 07:04:03,043 [DEBUG] vmtoolsd: stdout: {"version":"1.0.0", "result": true }
...
2022-10-29 07:04:33,091 [INFO] monitor: check if application is notified
2022-10-29 07:04:33,092 [DEBUG] vmtoolsd: invoke command: ['vmtoolsd', '--cmd', 'vm-operation-notification.check-for-event {"uniqueToken": "52964f1a-6c7e-b373-b588-545b39581e1a"}']
2022-10-29 07:04:33,111 [DEBUG] vmtoolsd: rc: 0
2022-10-29 07:04:33,111 [DEBUG] vmtoolsd: stdout: {"version":"1.0.0", "result": true, "eventType": "start", "opType": "host-migration", "eventGenTimeInSec": 1666994660, "notificationTimeoutInSec": 120, "destNotificationTimeoutInSec": 120, "notificationTypes": ["sla-miss"], "operationId": 6279072957175440971 }
2022-10-29 07:04:33,111 [INFO] monitor: application is notified that vmotion has been requested and should be quiesced in 120 seconds. invoke command to quiesce
2022-10-29 07:04:33,111 [DEBUG] invoke_command: command for quiesce/unquiesce: ['/.../examples/demo.sh -m quiesce']
2022-10-29 07:04:33,116 [INFO] invoke_command: > Application HOGE is requested to be quiesced.
2022-10-29 07:04:33,116 [INFO] invoke_command: > Quiescing ... leaving target pool for load balancing ...
...
2022-10-29 07:04:39,140 [INFO] invoke_command: > Quiescing ... stopping service BAZ
2022-10-29 07:04:40,144 [INFO] invoke_command: > Application HOGE has been quiesced and ready for vMotion.
2022-10-29 07:04:40,144 [DEBUG] invoke_command: return code: 0
2022-10-29 07:04:40,144 [INFO] monitor: command to quiesce has been completed with return code: 0
2022-10-29 07:04:40,144 [INFO] monitor: acknowledge notification
2022-10-29 07:04:40,144 [DEBUG] vmtoolsd: invoke command: ['vmtoolsd', '--cmd', 'vm-operation-notification.ack-event {"uniqueToken": "52964f1a-6c7e-b373-b588-545b39581e1a", "operationId": 6279072957175440971}']
2022-10-29 07:04:40,156 [DEBUG] vmtoolsd: rc: 0
2022-10-29 07:04:40,156 [DEBUG] vmtoolsd: stdout: {"version":"1.0.0", "result": true, "operationId": 6279072957175440971, "ackStatus": "ack_received" }
2022-10-29 07:04:40,156 [INFO] monitor: got response: ack_received
...
2022-10-29 07:10:56,154 [INFO] monitor: interrupted
2022-10-29 07:10:56,154 [INFO] monitor: unregister application: demo
2022-10-29 07:10:56,155 [DEBUG] vmtoolsd: invoke command: ['vmtoolsd', '--cmd', 'vm-operation-notification.unregister {"uniqueToken": "52964f1a-6c7e-b373-b588-545b39581e1a"}']
2022-10-29 07:10:56,164 [DEBUG] vmtoolsd: rc: 0
2022-10-29 07:10:56,164 [DEBUG] vmtoolsd: stdout: {"version":"1.0.0", "result": true }
2022-10-29 07:10:56,164 [INFO] monitor: application has been unregistered
人間の介入を必要としない実装も、どうにかできそうなことが確認できました。
まとめ
vSphere 8 の新機能のひとつ、vSphere vMotion Notifications の動きを確認しました。
とはいえ、個人的には vMotion に耐えられないアプリケーションを扱う機会が日常ではあまりないのでそもそも出番がなさそうではありますが、動きとしてはおもしろいですね。