Hyper-V仮想マシンの状態をPowerShellで確認する基本は、Hyper-Vホスト上の管理者向けPowerShellでGet-VMを実行し、Name、State、Status、Uptime、CPUUsage、MemoryAssignedを読み取る方法です。状態確認と操作は分離し、監視スクリプトからStart-VM、Stop-VM、Restart-VMを自動実行しません。Off、Paused、Savedが異常かどうかは、保守計画や待機系の設計によって違います。まず事実を収集し、期待状態と照合します。
全VMの基本状態を一覧にする
Get-VM | Select-Object Name, State, Status, Uptime, CPUUsage, MemoryAssignedStateはRunning、Off、Paused、Savedなど仮想マシンの実行状態です。Statusは通常「Operating normally」のような運用状態を示します。Uptimeは現在の稼働期間で、ゲストOSが業務サービスを正常提供していることまで保証しません。CPUUsageとMemoryAssignedも瞬間値またはHyper-V側の割り当てであり、ゲスト内アプリの応答を別途確認します。
Hyper-Vモジュールが見つからない場合、その端末がHyper-Vホストではない、管理ツールが入っていない、PowerShellのエディションや権限が合わない可能性があります。モジュールを非公式サイトからダウンロードせず、Windowsの機能またはRemote Server Administration Toolsを組織の手順で確認します。一般ユーザー端末で権限を回避しません。
一台を名前で確認する
Get-VM -Name "Test-VM-01" | Format-List Name, State, Status, Uptime, ProcessorCount, MemoryAssigned, AutomaticStartAction対象名を明示すると調査しやすくなりますが、名前の打ち間違いと同名ルールに注意します。本番スクリプトでは固定の表示名だけでなく、管理台帳のVM IDやホストとの組み合わせを持つと誤対象を減らせます。VM名に顧客名やシステム名が含まれる場合、出力を公開チケットや外部チャットへ貼らないでください。
期待状態と実状態を分ける
監視では「StateがRunningなら正常」と一行で決めず、VMごとに期待状態を定義します。夜間停止する検証VM、待機系でOffのVM、保守中にSavedのVM、常時Runningの基幹VMは判定が違います。期待状態ファイルを用意する場合は変更管理し、誰がいつ例外を設定したかを記録します。存在しないVM、ホストへ接続できない、権限がない状態も別エラーにします。
状態変更の直後はStarting、Stopping、Savingなど移行状態になることがあります。監視間隔が短いと一時状態を障害として誤報します。数回連続で同じ異常状態になったとき通知する、保守時間を除外する、移行開始時刻を記録するなど、運用に合わせます。ただし長時間同じ移行状態なら、イベントログ、ストレージ、ホスト負荷を調べます。
複数ホストを確認する
Get-VM -ComputerNameでリモートホストを指定できる環境もありますが、認証、ファイアウォール、委任、Hyper-V管理権限が必要です。パスワードをスクリプトへ埋め込んだり、接続のために管理ポートを無制限公開したりしません。フェールオーバークラスターのVMは、クラスター管理の所有ノードと移動を考慮し、単一ホストの固定一覧だけで監視しません。
複数ホストの結果にはComputerName列を必ず持たせます。同名VMが別ホストにあっても区別できるためです。ホストが応答しない場合、VMをOffと記録せず「ホスト取得失敗」とします。古いキャッシュを最新状態のように表示せず、CollectedAtを各行へ付けます。
統合サービスを確認する
Get-VMIntegrationService -VMName "Test-VM-01" | Select-Object Name, Enabled, PrimaryStatusDescription, SecondaryStatusDescriptionGet-VMIntegrationServiceは、時刻同期、ハートビート、データ交換、シャットダウンなど統合サービスの状態を確認します。EnabledがFalseでも、セキュリティや役割上意図的に無効にしている場合があります。すべてを自動で有効化せず、VMの設計とゲストOSの対応を確認します。ハートビートが問題を示す場合も、ゲストOS、統合コンポーネント、負荷、停止中かを合わせて見ます。
Hyper-VのハートビートがOKでも、Webアプリ、データベース、認証サービスが利用できるとは限りません。仮想化基盤の生存確認と、アプリケーション監視を別レイヤーで実装します。逆にアプリ監視だけでは、チェックポイント統合、統合サービス、割り当て資源の問題を見逃します。
ネットワークアダプター情報を確認する
Get-VMNetworkAdapter -VMName "Test-VM-01" | Select-Object Name, SwitchName, Status, MacAddress, IPAddressesGet-VMNetworkAdapterでは接続先仮想スイッチ、状態、MACアドレス、Hyper-Vが把握したIPアドレスなどを確認できます。IP情報は統合サービスやゲストの状態に依存し、空でも即座にネットワーク断とは限りません。VLAN、チーミング、SR-IOV、複数NICなど高度な構成では、設計書と照合します。IPやMACは内部構成情報なので、ログの閲覧者を制限します。
メモリとCPUを見るときの注意
MemoryAssignedはバイト単位なので、見やすい列を作るならGBへ変換します。動的メモリでは起動メモリ、最小、最大、現在割り当てが異なります。CPUUsageはHyper-Vが示す使用率で、短い一回の取得だけでは負荷傾向を判断できません。高負荷調査では時系列を取り、ホスト全体のCPU、NUMA、ストレージ遅延、他VMの競合、ゲスト内プロセスを合わせます。
Get-VM | Select-Object Name, State, CPUUsage, @{Name="MemoryGB";Expression={[math]::Round($_.MemoryAssigned / 1GB, 2)}}チェックポイントは別に確認する
長期間残ったチェックポイントは差分ディスクを増やし、ストレージ容量やバックアップへ影響することがあります。Get-VMSnapshotで読み取れますが、削除や統合は大きなI/Oを発生させるため監視から自動実行しません。チェックポイント名、作成時刻、種別、所有者、削除予定を記録し、バックアップ製品が作る回復用チェックポイントとの違いを確認します。
CSVレポートを作る
レポートにはCollectedAt、Host、VMName、State、Status、Uptime、CPUUsage、MemoryAssigned、期待状態、判定理由を含めます。毎回同じパスへ上書きせず日付または実行IDを付け、保持期間を決めます。VM名とIPを含むためアクセス権を限定し、外部へ渡すときは匿名化します。CSV生成が失敗してもVM状態には触れないよう、収集と保存のエラーを分けます。
異常時の確認順序
- Get-VMでState、Status、Uptimeと取得時刻を確認します。
- 期待状態、保守時間、自動開始・停止方針と照合します。
- 統合サービスのハートビートとゲスト内アプリ監視を確認します。
- 仮想NIC、仮想スイッチ、IP情報、ホストネットワークを確認します。
- ホストのCPU、メモリ、ストレージ空き容量とイベントログを確認します。
- 変更が必要なら影響、バックアップ、復旧、担当を決めて別手順で実行します。
監視で避ける自動修復
VMがOffなら即Start、応答がなければRestart、チェックポイントが古ければRemoveという自動処理は、停止の意図、データ整合性、依存サービス、フェールオーバーを無視します。監視スクリプトは読み取りと通知に限定し、操作は承認されたランブックへ引き渡します。操作する場合も、対象VMとホストを再確認し、利用者連絡、バックアップ、復旧条件を整えます。
正常性を一つの値へ潰さない
- Hyper-V状態：Running、Off、Paused、Saved、移行中など。
- 統合状態：ハートビート、時刻同期、データ交換など。
- 接続状態：仮想NIC、スイッチ、VLAN、IP、外部到達性。
- 資源状態：CPU、メモリ、ストレージ、ホスト競合。
- サービス状態：ゲストOSと業務アプリの応答、依存先。
これらを分けて表示すると、「VMはRunningだがアプリ停止」「VMはOffだが計画停止」「ホスト取得失敗で状態不明」を正しく区別できます。問い合わせには、収集時刻、ホスト、VMの機密部分を伏せた識別子、State、Status、統合サービス、ネットワーク、イベントID、直前の変更を添えます。
コメント