Skip to content

MS_VHD

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

VHD

概要

VHD について。

詳細

形式

容量固定

あらかじめ決めたボリュームサイズと同等のファイルサイズで作成。

  • メリット
    作成時と使用時の VHD ファイルサイズは変化が無いため、
    • フラグメント化を防止できる。
    • 下位レイヤのアライメントと揃えることが容易。
  • デメリット
    サイズが大きいために取り扱いが難しくなることもある。

容量可変

  • VHD ファイル中に管理情報を持っていて、論理ブロックが、
    ファイル中のどの位置 (FilePosition) にあるか、自前で管理する。
  • メリット
    容量固定に書かれている、デメリットがない。
  • デメリット
    容量固定に書かれている、メリットがない。

移行メモ（正誤）: 原典は容量可変のメリット・デメリットが
「メリット：容量固定に書かれている、メリットがない。」
「デメリット：容量固定に書かれている、デメリットがない。」
と逆に記載されていた。

容量可変は
**「ファイルが小さくて扱いやすい（＝固定のデメリットが無い）」**が
「断片化しやすくアライメントが揃わない（＝固定のメリットが無い）」
であるため、記述を入れ替えた。

補足（実務での選択）: 2 形式の違いは性能に直結する。

容量固定 容量可変
作成時間 長い（全領域を確保） 短い
初期サイズ 最大サイズと同じ 小さい
書き込み性能 速い 拡張時にオーバヘッド（メタデータ更新＋ゼロ埋め）
断片化 しにくい しやすい
容量超過のリスク 無い（先に確保済み） ホストのディスクが先に枯渇し得る

最後の行が運用上いちばん怖い。
容量可変を複数並べると合計の最大サイズが
ホストの物理容量を超える（オーバー コミット）状態になりやすく、
ホストのディスクが満杯になると全 VM が停止する。

したがって、

用途 選択
本番、DB、性能が要る 容量固定
検証、テンプレート、台数が多い 容量可変（空き容量の監視が必須）

というのが定石である。

なお、VHDX（Windows Server 2012 以降）では
容量可変の性能が大きく改善しており、差は縮まっている。
ただし「物理容量が先に尽きる」というリスクは変わらない。

Sparse Files

  • NTFS のファイルシステムの管理情報として、

    HDD のセクタを

    • 割り当ててあるセクタ
    • 割り当てていないセクタ
      • 割り当てていないセクタを read すると、00 が返る。

    がある。

  • Sparse Files を作る場合、専用の API で、
    特定の FilePosition を切り捨てる。

  • Azure の VHD は、Sparse Files 形式で、
    実使用容量（ActualGB）の分だけ Page BLOB を使う。

補足（Azure でこれが効いてくる場面）: 最後の一行は
Azure の課金に直結する重要な事実である。

【マネージド ディスク 128GB を作成】
  確保サイズ  : 128GB   ← マネージド ディスクはこの分だけ課金
  実使用容量  :  20GB

【非管理ディスク（Page BLOB）の場合】
  Page BLOB   :  20GB 分だけ課金（Sparse なので）

つまり、課金の考え方が異なる。

課金
マネージド ディスク プロビジョニングしたサイズ（使っていなくても）
非管理ディスク（Page BLOB） 実使用量

ただし、Azureの仮想マシンで述べたとおり
非管理ディスクは廃止されているため、
現在は「プロビジョニング分だけ課金される」と考えてよい
（Azureの課金）。

Sparse の知識が今も要るのは、

  • VHD を Azure にアップロードするとき
    （Azure上に素早く環境を構築する）、
  • ダウンロード時に「空き領域を転送しない」最適化
    （参考の Kyrt Blog の記事がこの話）

といった場面である。
128GB の VHD でも、実使用が 20GB なら
20GB 分だけ転送すればよい、という最適化が可能になる。

差分

元の VHD イメージと使用した場合の差分を扱う。

補足（差分ディスクの用途と注意）: 「親 VHD ＋ 差分」という構成で、
1 つの親から多数の VM を派生させられる。

【親 VHD】Windows Server（読み取り専用）
   ├─ 差分1 → VM-A の変更分だけ
   ├─ 差分2 → VM-B の変更分だけ
   └─ 差分3 → VM-C の変更分だけ
利点 注意
ディスク容量を大幅に節約 親を変更・移動・削除すると全部壊れる
展開が速い チェーンが長いと性能が落ちる
検証環境の使い捨てに向く バックアップが複雑になる

親 VHD は絶対に触らない（読み取り専用にする）というのが鉄則である。
パスが変わっただけでも差分が親を見失う。

なお、Hyper-V のチェックポイント（スナップショット）も
内部的には差分ディスク（.avhdx）である。
チェックポイントを消し忘れると差分が積み上がり、
容量と性能の両方を圧迫する
（Hyper-V バックアップ）。

ハードディスクへのリンク

物理ハードディスクのリンクまたはパーティションとして使用する形式。

補足: これがHyper-V バックアップで言及されている
パススルー ディスクである。
VHD ファイルを介さず物理ディスクを VM に直結するため高速だが、

  • ホスト ベースのバックアップの対象外になる、
  • スナップショット（チェックポイント）が使えない、
  • VM の可搬性が失われる

という制約がある。
現在は VHDX の性能が向上したため、
パススルーを選ぶ理由はほぼ無くなっている。

可搬性

基本的に VHD は持ち運びができるが、以下の点に注意が必要。

ホストOSとゲストOS

ホスト OS（VM 構成バージョン）とゲスト OS の互換性

VHDの互換性

補足（「VHD だけ持って行っても足りない」）: この節の要点は、
VM ＝ VHD ではないという点にある。

【1 つの仮想マシンを構成するもの】
  ├─ VHD / VHDX          … ディスクの中身          ← これだけコピーしても
  ├─ 構成ファイル(.vmcx)  … CPU 数、メモリ、NIC、世代  ← これが無いと再現できない
  ├─ チェックポイント     … .avhdx ＋ 構成
  └─ 状態ファイル(.vmrs)  … 保存状態、TPM の鍵

VHD だけを新しいホストにコピーして VM を新規作成すると、

  • 世代（Gen1/Gen2）の指定を間違えると起動しない
    （Azure上に素早く環境を構築するでも同じ問題が起きている）、
  • NIC の MAC アドレスが変わり、ゲスト OS 側の設定がずれる、
  • TPM の鍵が失われ、BitLocker が解除できなくなる（後述）

といった問題が起きる。
原則としてエクスポート／インポートを使うのが正しい。

エクスポート / インポート

  • VHD 単体ではなく、構成情報やスナップショットも移行する。
  • Windows 8 や Server 2012 では
    エクスポートしていない仮想マシンでも直接インポートできる。
  • エクスポート / インポートにおける互換性は、以下のように言えるらしい。
    • 新しい OS にて作成した仮想マシンを古い OS のホストにインポートする事は不可
    • ただし、上記以外のケースでも、失敗することがある（2008 → 2012R2 はダメらしい）。
  • 参考

補足（「VM 構成バージョン」が互換性の実体）: 「新しい OS で作った VM を
古い OS にインポートできない」という制約は、
VM 構成バージョンという番号で管理されている。

Hyper-V ホスト 既定の構成バージョン
Windows Server 2012 R2 5.0
Windows Server 2016 8.0
Windows Server 2019 9.0
Windows Server 2022 10.0

ルールは単純で、

  • ホストは、自分と同じかそれ以下の構成バージョンの VM を動かせる、
  • 上のバージョンは動かせない（後方互換のみ）、
  • バージョンは上げられるが、下げられない
    （Update-VMVersion は一方通行）

という関係になる。

2019 で作成（v9.0）── ✕ ──→ 2016 のホスト（v8.0 まで）
2016 で作成（v8.0）── ○ ──→ 2019 のホスト
                      ↑ ただしバージョンは 8.0 のまま（新機能は使えない）

実務上の要点は、

場面 対処
混在環境で VM を行き来させる 一番古いホストに合わせた構成バージョンで作成する
移行後に新機能を使いたい 移行完了後に Update-VMVersion
移行前に確認 Get-VM | Select Name, Version

となる。
本文の「2008 → 2012R2 はダメらしい」は、
世代が離れすぎている（構成の形式自体が違う）ためで、
段階的に移行するか、VM を新規に作り直す必要がある。

TPM の移行

VM の TPM を有効にしている場合は、TPM も移行する必要がある模様。

補足（vTPM の移行が難しい理由）: 仮想 TPM（vTPM）は
ホストの「ガーディアン」（HGS または ローカル ガーディアン）が
持つ鍵で保護されている。

ゲスト VM の BitLocker
   ↓ 鍵を預けている
vTPM（仮想 TPM）
   ↓ 保護されている
ホストのガーディアン（鍵ペア）
   ↓ ホストごとに異なる
【別ホストに移すと、鍵が無いので vTPM を開けない】

つまり、VM だけを移してもゲスト OS が起動しない
（BitLocker が解除できず、回復キーを求められる）。

対処は次のいずれかになる。

手段 内容
ガーディアンをエクスポート／インポート 移行元ホストの鍵を移行先に持ち込む
HGS（ホスト ガーディアン サービス）を使う 鍵を中央管理し、複数ホストで共有
移行前に BitLocker を無効化 最も確実。移行後に再度有効化
回復キーを控えておく 最低限の保険

**「回復キーを控えずに移行して起動しなくなる」**というのが
最悪のパターンなので、
移行前に必ず回復キーを退避すること。

なお、Azure上に素早く環境を構築するで触れた
Gen2 VM の Trusted Launch も同じ vTPM の仕組みを使っており、
クラウドへの移行でも同種の考慮が必要になる。

参考

補足（最新化：VHD と VHDX）: 本ページは VHD（旧形式）を扱っているが、
Windows Server 2012 以降は VHDX が既定である。

VHD VHDX
最大サイズ 2TB 64TB
論理セクタ サイズ 512 バイト固定 4KB に対応（性能向上）
電源断への耐性 弱い（メタデータが壊れ得る） ログ構造で保護
容量可変の性能 低い 改善
使える場面 Azure（現在も VHD 形式が必要）、古い Hyper-V オンプレの現行

注意すべきは、Azure へのアップロードは今も VHD 形式である点で、
VHDX から VHD への変換（Convert-VHD）が必要になる
（Azure上に素早く環境を構築するの
「1MB * N のサイズの VHD として作成しておく」という注意もここに関係する）。

Tags: 移行, Windows, Hyper-V, 仮想化

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally