いまさら聞けないHyper-V仮想マシンの構成詳細（3）：管理設定：今だからこそ学び直すHyper-V再入門（6）

　統合サービスは本連載第1回の「VMBus」の項で紹介した通り、現在サポート期間中のWindows OSであれば既に組み込まれているため、インストールなどを意識する必要はありません。Linux OSをはじめとする非Windows OSの場合は、本連載第1回で紹介したサポート状況を確認の上、組み込みの統合サービスを使用するか、Microsoftが提供する「Linux Integration Services」（LIS）のインストールすることで統合サービスを利用できます。

　統合サービスとして提供されるサービスには以下の6つがあり、サービス単位で有効／無効を設定できます（画面4）。

画面4　統合サービスとして提供されるサービス

　各サービスのチェックボックスをオフにすることで、当該サービスは使用不可となります。各サービスの詳細を理解の上、仮想マシン単位で設定してください。

　なお、有効化したサービスは、ゲストOSがWindowsであれば対応するサービス、Linuxであればカーネルモジュール（画面5）、もしくはデーモンが自動的に有効化されて、サービスが利用可能になります。

画面5　Linux（Ubuntu）での統合サービス用カーネルモジュール

　各項目の説明時に、ゲストOS側で利用されるサービス、もしくはカーネルモジュール／デーモンも紹介しますので、仮想マシンの設定項目とゲストOSのサービスとの対応も合わせて確認してください。

　なお、Hyper-Vマネージャーで表示されている統合サービス名と、PowerShellコマンドレットで操作可能な統合サービス名が一致していません。そのため、Hyper-Vマネージャーの表示名でPowerShellコマンドレットを利用すると、エラーが発生するので注意してください。

　以下の表1でHyper-VマネージャーとPowerShellコマンドレットでの名前のマッピングを示しますので、参考にしてください。

・オペレーティングシステムのシャットダウン

　Hyper-Vホストからの仮想マシン停止処理は、「停止」「シャットダウン」「保存」の3つがあります（画面6）。

画面6　仮想マシンに対する停止処理

　「停止」処理は、統合サービスの有無にかかわらず可能ですが、いわゆる「電源断」の処置と同等であり、物理マシンでいえば、コンセントから電源ケーブルを引き抜いた状態、もしくは停電が発生した状態になります。そのため、「停止」処理を実行した場合には、画面7のようなデータロストの可能性を示す警告ウィンドウが表示されます。

画面7　「停止」処理を実施した際に表示される警告ウィンドウ

　対して「シャットダウン」は、統合サービス経由で仮想OSと連携することで、Hyper-Vホストから安全に仮想マシンをシャットダウンできます。

　Hyper-Vホストからのシャットダウン指示は、ゲストOSがWindows OSの場合はゲストOSのサービス「Hyper-V Guest Shutdown Service（vmicshutdown）」に渡され、OSのシャットダウン処理が実行されます。なお、Linux OSの場合は「hv_utils」になります。

　以下の画面8は、「Windows Server 2022」の「Hyper-V Guest Shutdown Service（vmicshutdown）」のプロパティですが、「物理コンピューター上の管理インターフェイスからシャットダウンする手段を提供する」との説明通り、当該サービスでHyper-Vホストからのシャットダウン処理を受け付けることになります。

画面8　ゲストOS上の「Hyper-V Guest Shutdown Service」サービス

　なお、当該サービスをゲストOS上で停止した場合は、Hyper-Vホストから「シャットダウン」を実行しても画面9のようなエラーが発生してシャットダウンできません。当該サービスを停止する場合には、影響を理解した上で停止してください。

画面9　ゲストOS上でサービスを停止すると、Hyper-Vホストからシャットダウンできない

　「保存」処理は、仮想マシンの状態を保持したまま、仮想マシンの動作を一時停止するような動きで、メモリの状態も含めて仮想マシンの状態が凍結されるようなイメージになります。

　「停止」処理と同様、統合サービスを必要としない処理になるので、統合サービスに対応していないゲストOSでも利用できます。

・時刻の同期

　「時刻の同期」は、Hyper-Vホスト上の時刻情報をゲストOSに提供するサービスです。

　時刻の同期を有効にすると、ゲストOS上からは「VM IC Time Synchronization Provider」と時刻同期しているように見えます。Windows OSでWindows Timeサービス（W32Time）の設定を参照できる「w32tm」コマンドで確認すると、画面10のように「VM IC Time Synchronization Provider」を同期元として時刻を同期していることが分かります。

画面10　ゲストOS上からは、「VM IC Time Synchronization Provider」を同期元として時刻同期しているように見える

　時刻の同期は、ゲストOSがWindows OSの場合は「Hyper-V Time Synchronization Service（vmictimesync）」サービス（Linux OSの場合は「hv_utils」）と連携して実装されており、当該サービスを停止しない限りはHyper-Vホストと時刻を同期し続けます。

　また、画面10のように「VM IC Time Synchronization Provider」は、NTP（Network Time Protocol） Serverとして扱われます。そのため、「w32tm」コマンドで外部NTP Serverを参照するように設定しても、NTP Serverの階層（stratum）によっては「VM IC Time Synchronization Provider」が優先されてHyper-Vホストと時刻同期してしまう可能性がある点に注意してください。

　このような「設定されたNTP ServerよりHyper-Vホストとの時刻同期が優先される」状態が好ましくない場合は、時刻の同期を無効にすることをお勧めします。

　なお、Hyper-V上の仮想マシンでドメインコントローラーを構築する場合には、以下のMicrosoft公式ドキュメントの通り、時刻の同期を無効にすることが推奨されています。

• Hyper-Vによるドメインコントローラーの仮想化→タイムサービスと同期（Microsoft Learn）

・データ交換

　「データ交換」は、仮想マシンとHyper-Vホストの間で基本的なメタデータの交換を可能にするサービスです。

　データ交換を使用することで、例えば仮想マシンの設定されているIPアドレスをHyper-Vホストから確認するといったことが可能です。画面11は「Get-VMNetworkAdapter」コマンドレットを使用して、仮想マシンのネットワークアダプターの情報を取得した結果です。「Disable-VMIntegrationService」コマンドレットで「データ交換（キー値ペア交換）」を無効化した前後で、仮想マシンのIPアドレス取得結果が変わっていることが確認できます。

画面11　「データ交換」を無効化すると「Get-VMNetworkAdapter」コマンドレットでIPアドレスが取得できない

　このように、データ交換を有効化することで、ゲストOSの内部の情報をHyper-Vホストから参照できるようになります。

　ゲストOSがWindows OSの場合は「HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\Virtual Machine」配下のレジストリキーの情報が共有されるので、Hyper-Vホストで当該情報をWMI（Windows Management Instrumentation）経由で取得できます。Linux OSの場合は「/var/lib/hyperv/」配下に「.kvp_pool_0」〜「.kvp_pool_4」というファイルが作成され、類似の情報が格納されます。同様にその内容はHyper-Vホスト（WMI経由）で取得可能です。

　なお、データ交換はHyper-V VMbus間で転送されるため、仮想マシンとHyper-Vホスト間のネットワーク接続は必要ありません。

　このデータ交換には、Windows OSの場合は「Hyper-V Data Exchange Service（vmickvpexchange）」サービス、Linux OSの場合は「hv_kvp_daemon（hypervkvpd）」デーモンが使用されます。

　なお、データ交換については、以下Microsoftの公式ドキュメントに詳細が記述されているので、興味がある方は参照してください。

• Data Exchange: Using key-value pairs to share information between the host and guest on Hyper-V［英語］（Microsoft Learn）

・ハートビート

　「ハートビート」は、仮想マシン上のゲストOSが正しく起動し、Hyper-Vホストとの間で統合サービスによる通信が開始されたことを確認するサービスです。

　Hyper-VマネージャーやPowerShellコマンドレットで確認できる「実行中」のステータスは、あくまでもHyper-Vホストとしてリソースを確保し、仮想マシンの「電源投入」を実施したところまでの状態を示しており、仮想マシン上のゲストOSの状態を表したものではありません。

　そこで、ゲストOSの正常性を確認するためにハートビートが利用されます。

　ハートビートで使用される「Hyper-V Heartbeat Service（vmicheartbeat）」（Windows OSの場合。Linux OSの場合は「hv_utils」）と正常にHyper-Vホストが通信できている場合、Hyper-Vマネージャーでは画面12のように「ハートビート：」の項目が「OK」と表示されます。

画面12　ハートビートによる疎通確認が正常の場合は「OK」と表示される

　ハートビートが途絶えた場合、例えばゲストOS上のサービス停止やWindows OSがクラッシュした場合などは、画面13のように「通信の切断」と表示され、ゲストOS上で何かが発生したことがHyper-Vホスト側でも検知できます。

画面13　ハートビートによる疎通確認が途絶した場合は「通信の切断」と表示される

　なお、統合サービスが有効化されていない状態の仮想マシンは「利用不可」、統合サービスに対応していない仮想マシンの場合は「コンタクトなし」と表示されます（画面14）。

画面14　統合サービスに対応していない仮想マシンの場合は「コンタクトなし」と表示される

・バックアップ（ボリュームシャドウコピー）

　「バックアップ（ボリュームシャドウコピー）」は、仮想マシン上のゲストOSと連携して、ボリュームのスナップショットを取得する「ボリュームシャドウコピーサービス（VSS）」の利用を可能にする機能です。

　VSSを利用することで、仮想マシンに大きな負荷をかけることなく、仮想マシンのバックアップを取得可能になります。

　仮想マシンのバックアップとリストアについては別の回で詳しく解説しますが、本サービスはバックアップ取得に大きく関連することを覚えておいてください。

　バックアップ（ボリュームシャドウコピー）では、仮想マシンがWindows OSの場合は「Hyper-Vボリュームシャドウコピーリクエスター（vmicvss）」サービスが、Linux OSの場合は「hv_vss_daemon（またはhypervvssd）」デーモンが利用されます。

・ゲストサービス

　「ゲストサービス」は、仮想ネットワークを介さずにHyper-Vホストと仮想マシンとの間でファイルコピーを実現するサービスです。本サービスは仮想マシン作成の際、既定（デフォルト）で無効になっています。

　Hyper-Vホストから仮想マシンへのファイルコピーはGUIではできないため、「Copy-VMFile」コマンドレットを使用します（画面15）。

画面15　Copy-VMFileコマンドレットで仮想マシンへファイルをコピーした

　ファイルをコピーする際、仮想マシンとHyper-Vホスト間のネットワーク接続は必要ありません。

　画面15は仮想マシンのゲストOSがWindows Serverの場合ですが、Linux OSでもゲストサービスが有効であればファイルコピーが可能です。その場合、宛先フォルダの指定はLinuxのフォルダ構造指定（例えば「/tmp」）に従います。

　ゲストサービスでは、仮想マシンがWindows OSの場合は「Hyper-V Guest Service Interface（vmicguestinterface）」サービスが、Linux OSの場合は「hv_fcopy_daemon（またはhypervfcopyd）」デーモンが利用されます。

仮想マシンの管理：チェックポイント

　「チェックポイント」は、以前は「スナップショット」と呼ばれていた、仮想マシンの状態と仮想ハードディスクを任意のタイミングで保存する機能です。チェックポイントを作成することで、その瞬間の仮想マシンの状態を保存でき、問題が発生した際にはチェックポイント作成時点まで仮想マシンを巻き戻せます。

　本項目は、チェックポイントの使用の有無、作成するチェックポイントの種類、チェックポイントの保管場所を指定できます（画面16）。

画面16　仮想マシンのチェックポイント設定

　「チェックポイントを有効にする」のチェックボックスは既定でオンになっていますが、チェックポイントを有効にすることで、仮想マシンでチェックポイントを作成できます。チェックポイントは、Hyper-Vマネージャーから簡単に作成できる他、「Checkpoint-VM」コマンドレットでも作成できます（画面17）。

画面17　Hyper-Vマネージャーから仮想マシンを選択して「チェックポイント」を実行することで、チェックポイントを作成できる

　取得するチェックポイントについては「運用チェックポイント」と「標準チェックポイント」の2種類から選択可能で、既定は運用チェックポイントになります。

　運用チェックポイントは、チェックポイントを作成した時点のイメージを取得可能で、チェックポイントを適用することで、完全な保存状態に戻すことができます。これはVSSなど、仮想マシンのゲストOSの機能でチェックポイントを作成することで実現されており、アプリケーション整合性を保証した形でのチェックポイントになります。

　なお、運用チェックポイントではメモリ状態は保存されないので、チェックポイントを適用後は仮想マシンの起動（電源投入）が必要です。

　標準チェックポイントは、「Windows Server 2012 R2」のHyper-Vまでのチェックポイントと同じ動きとなり、仮想マシンの状態をメモリも含めて取得します。従って、取得したチェックポイントを適用すると、チェックポイント取得時点の仮想マシンがメモリ状態も含めた形で復元されます。そのため、仮想マシンは「保存状態からの復帰」というイメージとなり、稼働状態で復元されます。

　例えば、「メモ帳」を起動した状態で標準チェックポイントを作成後、メモ帳を閉じたとします。この状態でチェックポイントを適用すると、メモ帳が起動した状態で復元されます。これは、メモリ状態も含めた状態を保存する標準チェックポイントの特徴です。

　一見、メモリ状態を保存できない運用チェックポイントよりも、標準チェックポイントの方が高機能と思われるかもしれません。しかし、標準チェックポイントの最大の問題点は「メモリ状態まで巻き戻ってしまう」ため、例えば「Active Directory」のような異なる仮想マシン／物理マシン間で複製しながら動くアプリケーションでは、データの不整合が発生する場合があります。

　また、アプリケーションの整合性については、運用チェックポイントであればゲストOSのVSSと連携して静止点を確保できるため、整合性を保証できます。

　運用チェックポイントと標準チェックポイントは、どちらが優れているということではなく、チェックポイントの目的と用途に応じて使い分けることをお勧めします。

　「自動チェックポイントを使用する」のチェックボックスをオンにすると、仮想マシンが起動する際に自動的にチェックポイントが作成されます。その後、仮想マシンをシャットダウンして起動すると、自動取得したチェックポイントに戻すか、それともそのまま実行するかの確認が行われます（画面18）。

画面18　自動チェックポイントを有効にすると、起動時にチェックポイント適用の確認が行われる

　仮想マシン起動時に毎回クリーンイメージに戻すような運用や、さまざまな構成変更をテストする検証環境などでは便利な機能になるでしょう。

　最後の「チェックポイントファイルの場所」は、チェックポイントで取得した構成ファイルや差分ファイルなどを保存する場所を選択します。

　なお、チェックポイントの仕組みや運用については、仮想マシンのバックアップとリストアに関する回で詳細を解説する予定です。

仮想マシンの管理：スマートページングファイルの場所

　「スマートページングファイルの場所」では、「スマートページング」と呼ばれる仮想メモリ用のファイルを置く場所を指定します（画面19）。

画面19　スマートページングファイルを置くフォルダを指定する

　本連載第4回の「メモリ」の項で少し触れましたが、動的メモリを設定した仮想マシンが多数稼働するHyper-Vホストでは、実メモリを複数の仮想マシン間で融通しながらHyper-Vホストのメモリを最大限活用します。

　そのため、多数の動的メモリが有効化された仮想マシンが一斉に起動すると、初期メモリを仮想マシンに割り当てることができずに起動できない、という事態が発生する場合があります。そうした状況を緩和するために用意された仕組みが、スマートページングです。

　スマートページングは、一時的にディスクリソースをメモリ領域として仮想マシンに割り当てることで、動的メモリ利用時の突発的なメモリ不足を解消します。

　スマートページングは、仮想マシンの再起動時に初期メモリが確保できずに起動失敗するという状況を緩和するための仕組みであり、恒常的に用いられるものではないという点に注意してください。

　そうした仕組みを利用するためのファイル保存場所の指定となるため、本項目で指定するフォルダパスは、システムドライブなど、利用頻度の高いドライブのフォルダは避けて、比較的ディスクI/Oの速いドライブを指定するとよいでしょう。

仮想マシンの管理：自動開始アクション

　Hyper-Vホストが起動した際、仮想マシンを自動起動する運用を可能にするのが「自動開始アクション」です（画面20）。

画面20　自動開始アクション

　例えば、何らかの理由でHyper-Vホストが再起動してしまった、というシナリオで考えてみましょう。

　Hyper-Vホスト上の仮想マシンの全てが本設定の「何もしない」に設定されていた場合は、仮想マシンは一切起動せずに停止状態のまま維持されます。そのため、業務で必要な仮想マシンが停止したままなので、業務遂行に影響が出る可能性もあります。

　そこで、「サービスが停止したときに実行されていた場合は自動的に起動する」に設定すると、前述のシナリオでは「実行中だったにもかかわらず、Hyper-Vホストの停止によって仮想マシンが電源断になった」状態となるため、自動的に起動されることになります。これにより、管理者の介入を待つことなく仮想マシンが起動するため、業務への影響を最小限に抑えることが可能になります。

　また、電源断のシナリオでは、無停電電源装置（UPS）の自動ホストシャットダウン処理に伴う仮想マシンの自動停止処理ということも考えられます。このシナリオの場合、仮想マシンが正常停止してしまうと、前述の「サービスが停止したときに実行されていた場合は自動的に起動する」の設定では仮想マシンは自動起動しません。

　その場合は「常にこの仮想マシンを自動的に起動する」に設定することで、仮想マシンの状態にかかわらず、Hyper-Vホストが起動したタイミングで仮想マシンも自動起動できます。

　しかし、ワークロードによっては仮想マシンの起動順番を守る必要がある場合や、一斉に仮想マシンが起動することでいわゆる「ブートストーム」が発生し、最優先で起動すべき仮想マシンの起動に時間がかかる場合など、自動起動の弊害もあります。そのような場合には、「自動起動待ち時間」を活用します（画面21）。

画面21　自動起動待ち時間を「120秒」に設定した例

　自動起動待ち時間は、「サービスが停止したときに実行されていた場合は自動的に起動する」「常にこの仮想マシンを自動的に起動する」のどちらでも利用可能で、Hyper-Vホストが起動してから設定された待ち時間が経過した時点で自動起動されます。

　この設定を利用して、最優先で起動すべき仮想マシンは「0秒」設定、そこから10秒刻みで順番に仮想マシンを起動していくなどに設定することで、一斉起動を避け、またある程度の起動順序を設定しながら仮想マシンの自動起動を実現できます。

仮想マシンの管理：自動停止アクション

　Hyper-Vホストを再起動、もしくはシャットダウンする際、仮想マシンが稼働中の場合は「自動停止アクション」の設定に基づいて停止処理が行われます（画面22）。

画面22　仮想マシンの自動停止アクション

　仮想マシンごとに「仮想マシンの状態を保存する」（保存処理）、「仮想マシンを停止する」（停止処理）、「ゲストオペレーティングシステムをシャットダウンする」（シャットダウン処理）の3つから選択できますが、「仮想マシンを停止する」についてはいわゆる「電源断」処理となるため、お勧めできません。

　また、「仮想マシンの状態を保存する」については、メモリ状態も含めて保存されるため、アプリケーション整合性を考慮する必要があります。

　お勧めの設定は「ゲストオペレーティングシステムをシャットダウンする」ですが、説明書きにもある通り、統合サービスによるゲストOSのシャットダウンに対応していない場合は、停止処理（電源断処理）となります。

　Hyper-Vホストを計画停止する場合は、仮想マシン管理者が仮想マシンの停止処理を行うことが当たり前だと思いますが、停電などの突発的な停止もあるでしょう。また、UPSによる供給電力限界による自動停止処理が行われる場合もあります。

　いずれにしても、仮想マシンの停止処理を伴うため、UPSによる自動停止の場合は「仮想マシンを安全に停止する」ためのシャットダウン時間を考慮の上、UPSの稼働可能時間とのバランスを見ながら、停電発生から停止処理開始までのタイムラインを決定する必要があります。

　これまで3回に分けてHyper-V仮想マシンの設定画面を見てきました。次回は仮想マシンの“設定画面に現れない設定”について解説します。