Hyper-Vでチェックポイント結合が遅いときは、まず「壊れた」のではなく「AVHDX を親 VHDX に戻す I/O が詰まっている」と考えるのが近道です。実際に詰まりやすい原因は、空き容量不足、バックアップが残した孤立 AVHDX、ウイルス対策やバックアップ処理によるファイルロック、アクセス権の不整合、クラスターや共有ストレージ側の問題にほぼ集約できます。.avhdx を直接削除すると悪化しやすいので、空き容量→バックアップ/AV→権限→ディスクチェーンの順で確認するのが安全です。(Microsoft Learn)
この記事では、Hyper-Vでチェックポイント結合が遅いときの切り分け方、最初に見る設定、更新や権限の影響、通常の削除で直らないときの復旧手順まで、すぐに実務へ落とし込める形で整理します。(Microsoft Learn)
Hyper-Vでチェックポイント結合が遅いときの切り分け
現場では、まず症状を次の4パターンに分けると判断が速くなります。(Microsoft Learn)
| 症状 | 可能性が高い原因 | 最初の一手 |
|---|---|---|
| 削除後に長時間「結合中」のまま | 空き容量不足、長い差分チェーン、I/O不足 | ボリューム空き容量とチェックポイント数を確認 |
Hyper-V Manager にチェックポイントが出ないのに *.avhdx *.mrt *.rct が残る | バックアップ由来の孤立チェックポイント | バックアップログ確認、停止できるなら VM を停止 |
0x80070005 や Access Denied が出る | VM SID や NTFS 権限の不整合 | エラー詳細の VM ID を控え、ACL を修正 |
| CSV / SMB / 共有ストレージの VM だけ遅い | クラスター/所有ノード/共有ストレージ側の問題 | CSV 正常性と owner ノードを確認 |
まず押さえたい仕組み
Hyper-V のチェックポイントは、削除すると裏側で .avhdx と .vhdx を統合します。.avhdx は親の .vhdx と同じ場所に置かれ、削除完了後にファイルシステムから消えます。つまり、結合が遅いときに見ているべき本命は「保存先ディスクの I/O」と「差分チェーンの状態」であり、.avhdx を手で消して解決する構造ではありません。(Microsoft Learn)
ここでよくある誤解が、Checkpoint File Location を変えれば今の結合も速くなるというものです。Microsoft のドキュメントでは、変更できるのはチェックポイントの構成ファイルや保存状態ファイルの場所で、しかも VM に既存のチェックポイントがないときだけです。いま結合中の .avhdx 自体は親 .vhdx と同じ場所にあるため、進行中の遅さをこの設定だけで改善できるケースは多くありません。(Microsoft Learn)
また、Hyper-V には Production Checkpoint と Standard Checkpoint の2種類があります。Production は VSS もしくは Linux の file system freeze を使う整合性重視の方式で、Standard はメモリ状態やデバイス状態まで含みます。運用サーバーでは Production を基本にし、意図しない Standard へのフォールバックを避けたいなら ProductionOnly も確認対象です。Standard はフルバックアップではなく、Active Directory のようなノード間で状態整合性が重要なワークロードでは注意が必要です。(Microsoft Learn)
遅くなる主な原因と見分け方
空き容量が足りない
一番多いのは、単純な空き容量不足です。Microsoft のトラブルシュートでは、.vhdx .avhdx .mrt .rct を置いているボリュームに十分な空きがあるか確認し、理想的にはディスクサイズと同等の空き領域を確保するよう案内しています。さらに、Hyper-V のサポート上のチェックポイント上限は 50 で、トラブルシュートでも 50 を超えるケースは「多すぎる」状態として個別対応を勧めています。長期間残したチェックポイントや、日次バックアップで差分が積み上がった VM ほど、結合は遅く見えやすくなります。(Microsoft Learn)
実務では、AVHDX の合計サイズ だけでなく、親 VHDX が書き戻しで伸びる余地があるかを見るのが重要です。たとえば 2TB 級の親 VHDX を持つ VM で、保存先の空きが数百 GB しかない状態なら、チェックポイント削除を始める前に容量拡張や退避を先に考えたほうが安全です。これは「結合開始はできるのに、終盤で失速する」典型パターンです。(Microsoft Learn)
バックアップがチェックポイントを片付けていない
Hyper-V Manager にチェックポイントが見えないのに、VM フォルダーには .avhdx がいくつも残っている。この状態は、サードパーティ製バックアップが一時的に作ったチェックポイントを後始末できていないときに起きやすい症状です。Microsoft のトラブルシュートでも、Hyper-V Manager に表示されないがフォルダーには差分ディスクが残るケースを明確に扱っています。.mrt や .rct が残っている場合も、バックアップ周りの確認優先度が高いと考えてください。(Microsoft Learn)
このときは、まずバックアップジョブが「checkpoint cleanup」「merge」「post-job cleanup」相当を正常終了しているか確認します。Hyper-V Manager 上で右クリックの Delete Checkpoint や Delete Checkpoint Subtree が出ない場合でも、Microsoft は 対象チェックポイントを選んで Del キーで削除する方法を案内しています。右クリックメニューがないだけで、削除不能と決めつけないことが大切です。(Microsoft Learn)
ウイルス対策やファイルロックが I/O を止めている
Hyper-V ホストでリアルタイムスキャンが強く効いていると、*.vhdx *.avhdx *.rct *.mrt や Vmms.exe Vmwp.exe へのアクセスが重なり、結合が異常に遅くなったり、実際には止まっているのに見た目だけ進んでいるように見えたりします。Microsoft は、少なくともこれらのファイル、%ProgramData%\Microsoft\Windows\Hyper-V、%Public%\Documents\Hyper-V\Virtual Hard Disks、%SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots、CSV を使うなら C:\ClusterStorage、さらに SMB 3.0 共有上に VM ファイルを置く場合はファイルサーバー側の共有パスまで除外対象として挙げています。(Microsoft Learn)
Microsoft Defender Antivirus では、Windows Server で Hyper-V ロールを入れると Hyper-V 関連の自動除外が構成されます。一方で、サードパーティ製 AV は別途設定が必要です。バックアップ後の不完全マージや 0x80070020 系の共有違反が出るなら、リソースモニターや ProcMon でロック元プロセスを特定し、必要に応じてバックアップ、Hyper-V、VSS サービスを再起動するのが Microsoft の案内です。(Microsoft Learn)
権限が壊れていて「遅い」のではなく止まっている
0x80070005 や「Account does not have sufficient privilege」の系統は、速度問題というより権限異常で結合や起動が進めないケースです。Microsoft は、各 VM が一意の Virtual Machine SID を持ち、その SID が .vhd や .avhd の ACL にないと起動できないと説明しています。現行環境では .vhdx .avhdx の運用が一般的ですが、考え方は同じで、ディスクや VM フォルダーの ACL が崩れていないかを確認します。(Microsoft Learn)
フォルダー単位で ACL を戻す例として、Microsoft のトラブルシュートには次の形式が載っています。
icacls "D:\VMs\VM名" /grant "NT VIRTUAL MACHINE\<VM-GUID>:F" /Tこの修正は、エラー詳細に出る VM GUID を確認してから実行します。あわせて NT VIRTUAL MACHINE\Virtual Machines グループに「サービスとしてログオン」の権限があるかも確認対象です。(Microsoft Learn)
クラスターや共有ストレージでは「どのノードで見るか」も重要
クラスター環境では、CSV やクラスターリソースが不安定だと結合が遅い、止まる、見えない、といった症状が出ます。Microsoft はクラスターシナリオで CSV とクラスターリソースの状態確認を勧めています。さらに、共有ストレージ上で使用中の VHD に対する Get-VHD は、その VHD を現在使っているホストからしか正しく見えません。別ノードから叩くと「in use」と見えるため、誤診しやすいポイントです。(Microsoft Learn)
そもそもチェックポイントが想定されていない構成もある
Microsoft のトラブルシュートでは、パススルー ディスク、共有 VHDX、合成ファイバーチャネルなどを非対応シナリオとして挙げています。こうした構成では、一般的なチェックポイント削除やマージ前提の対処が噛み合わないことがあります。該当する VM なら、「なぜ遅いか」より前に「この方式で checkpoint を扱ってよいか」を見直すほうが先です。(Microsoft Learn)
最初に確認する設定とログ
- VM の状態
まず、VM が保存済み、チェックポイントの作成中、停止中に張り付いていないかを確認します。この状態のままでは、結合が遅いというより、別の処理待ちで進まないことがあります。(Microsoft Learn) - Settings > Checkpoints の種類とフォールバック
Production / Standard のどちらになっているか、また PowerShell や運用ポリシーでProductionOnlyを使うべき VM ではないかを見ます。特に業務サーバーで Standard が混じると、原因切り分けがややこしくなります。(Microsoft Learn) - Hyper-V Manager 上で visible checkpoint が消せるか
右クリックのDelete CheckpointやDelete Checkpoint Subtreeが出るか、出ないなら Del キーで削除できるかを確認します。ここが第一段階です。(Microsoft Learn) - 見るべきログ
Microsoft は、イベントビューアーのApplication、System、Microsoft-Windows-Hyper-V-VMMS/Adminを収集対象に挙げています。クラスターなら cluster log、VSS が怪しければvssadmin list writersも候補です。(Microsoft Learn)
PowerShell での確認は、次の3つから始めると十分です。
Get-VMSnapshot -VMName "VM名"
Get-VMHardDiskDrive -VMName "VM名" | ForEach-Object {
Get-VHD -Path $_.Path | Select-Object Path, ParentPath, VHDType
}
vssadmin list writersこれらは Microsoft のトラブルシュートで案内されている代表例です。なお、共有ストレージ上で使用中の VHD は、そのディスクを使っているホストから Get-VHD を実行しないと正しく参照できません。(Microsoft Learn)
安全な対処手順
まずは、新しいチェックポイントを増やさないことが先です。原因切り分け中は、対象 VM に対する自動バックアップや、自動チェックポイント作成を一時的に避けます。そのうえで保存先ボリュームの空き容量を確保し、Hyper-V Manager で見えるチェックポイントから通常削除を試します。見えるものを普通に消すのが最も安全で、Microsoft も最初の手順としてこれを案内しています。(Microsoft Learn)
PowerShell で削除するなら、まずは次の形です。
Get-VMSnapshot -VMName "VM名" | Remove-VMSnapshotHyper-V Manager で失敗したときの代替として、Microsoft がそのまま案内している方法です。(Microsoft Learn)
それでも進まない場合は、VM を停止できるかどうかで分けます。停止できるなら、いったん正常停止して削除を再試行します。Microsoft は、VM のシャットダウンで自動マージがトリガーされることがあると案内しています。逆に、停止できないまま無理に手作業を増やすと、復旧難易度が一気に上がります。(Microsoft Learn)
Manager で消えないときの復旧手順
停止できる場合
停止できるなら、まず VHD/AVHDX 一式をバックアップしてから作業します。その後、VM を停止し、Hyper-V Manager の Edit Disk で対象の .avhdx を選び、Merge → To parent virtual disk を実行します。差分が長い場合は、Microsoft のトラブルシュートどおり若い差分から古い差分へ順に処理するのが基本です。必要なら、マージ後の .vhdx を指すよう VM の構成を更新してから起動します。(Microsoft Learn)
PowerShell で行う場合は、次の形式になります。
Merge-VHD -Path <path-to-avhdx> -DestinationPath <parent-vhdx>ただし Merge-VHD は オフライン操作です。Microsoft のコマンドリファレンスでも、対象の仮想ハードディスクチェーンがアタッチされていないことを条件にしています。稼働中ディスクへ直接実行するのは避けてください。(Microsoft Learn)
もしベースディスクや差分ディスクが欠けている、あるいはチェーンが壊れているなら、Microsoft は可能ならバックアップから復元、難しければ新しい VM を作成して残っている正常な VHDX を接続する方法を案内しています。ここまで来たら「遅い」ではなく「整合性復旧」のフェーズです。(Microsoft Learn)
停止できない場合
Microsoft は、停止せずに差分ディスクをオンライン VM へマージする方法も案内していますが、PowerShell スクリプトを使う多段手順です。運用影響が大きい本番 VM ほど、無停止にこだわるより短時間停止を確保して安全側で処理したほうが、結果として早く戻せることが多いです。初心者が最初に選ぶ方法ではありません。(Microsoft Learn)
結合後に容量が戻りにくい場合
結合が終わっても、動的 VHDX のファイルサイズが期待ほど小さくならないことがあります。その場合は、必要に応じて Optimize-VHD で compact を検討します。Microsoft によれば、これは固定 VHD には使えず、対象 VHD は未アタッチか read-only でアタッチ済みである必要があります。(Microsoft Learn)
Optimize-VHD -Path "D:\VMs\Disk0.vhdx" -Mode Full結合と compact は別の処理です。結合完了後の整理として考えると混乱しにくくなります。(Microsoft Learn)
やってはいけないこと
.avhdxをエクスプローラーから直接削除する。Hyper-V は削除時に自動マージする前提で動くため、手で消すとチェーン破損を招きやすいです。(Microsoft Learn)AVHDXやVHDXのチェーンファイルを手で改名・移動する。Microsoft も手動の移動やリネームを避けるよう案内しています。(Microsoft Learn)- 稼働中のディスクチェーンに
Merge-VHDをそのまま実行する。Merge-VHDはオフライン前提です。(Microsoft Learn) - 進行中の merge を速くしたくて
Checkpoint File Locationだけを変える。現在の.avhdxの実体場所はそこではないことが多いからです。(Microsoft Learn) - チェックポイントを長期保管してバックアップ代わりにする。Hyper-V のドキュメントでも、チェックポイントはフルバックアップではありません。(Microsoft Learn)
更新直後に遅くなったときの見方
Microsoft のトラブルシュートでは、最近の構成変更、OS 変更、ストレージ変更を記録して照合することを勧めています。Hyper-V ホストの更新、バックアップ製品の更新、ホスト再起動、ディスク移行の直後から症状が出たなら、その時刻と Hyper-V-VMMS/Admin、バックアップログ、VSS の状態を突き合わせてください。バックアップ後の不完全マージなら、バックアップ側の cleanup 設定確認が先で、それでもだめなら VM もしくはホストの再起動、あるいはバックアップ / Hyper-V / VSS サービスの再起動が候補になります。(Microsoft Learn)
まとめ
Hyper-Vでチェックポイント結合が遅いときは、空き容量不足、バックアップ残骸、AV/Defender の除外漏れ、権限不整合、クラスター/共有ストレージの順で見ると、余計な遠回りを減らせます。次にやることはシンプルで、まず VM フォルダーの空き容量と *.avhdx *.mrt *.rct の有無を確認し、Get-VMSnapshot と Get-VHD でチェーンを見て、見えるチェックポイントは通常削除、見えない差分は停止できるなら停止後にマージ、0x80070005 があれば ACL 修正です。この順番を崩さなければ、Hyper-V のチェックポイント結合が遅い問題はかなりの確率で安全に収束できます。(Microsoft Learn)
コメント