Hyper-V 記憶域の I/O のパフォーマンス
この記事では、仮想マシン (VM) の記憶域の 入出力 (I/O) パフォーマンスをチューニングする際のさまざまなオプションと考慮事項について説明します。 記憶域の I/O パスは、次の 4 つの連続するステージにまたがって拡張されます。
- ゲスト記憶域スタック
- ホスト仮想化レイヤー
- ホスト記憶域スタック
- 物理ディスク
以降のセクションでは、各ステージで実行できる最適化について説明します。
仮想コントローラー
Hyper-V には、次の 3 種類の仮想コントローラーが用意されています。
Integrated Drive Electronics (IDE)
Small Computer System Interface (SCSI)
仮想ファイバー チャネル ホスト バス アダプター (HBA)
IDE
OS ディスクには IDE ディスクのみを使用することをお勧めします。 OS ディスクには、デバイスの最大 I/O サイズに基づくパフォーマンス制限があります。
IDE コントローラーは、IDE ディスクを VM に公開するエミュレートされたコントローラーです。 このタイプのコントローラーは、Hyper-V と VM の統合サービスのない以前のバージョンの Windows を実行しているゲスト VM で使用できる唯一のオプションです。 統合サービスが提供する IDE フィルター ドライバーは、エミュレートされた IDE コントローラーよりも優れたディスク I/O を実行できます。
SCSI (SAS コントローラー)
仮想 SCSI コントローラーは、SCSI ディスクを VM に公開します。 SCSI コントローラーごとに、最大 64 台のデバイスをサポートします。 SCSI パスはエミュレートされないため、OS ディスク以外のディスクの優先コントローラーになります。 Windows Server 2012 R2 以降では SCSI コントローラーがサポートされますが、共有バーチャル ハード ディスク (VHDX) をサポートするための Serial Attached SCSI (SAS) としてコントローラーを報告するシナリオでのみサポートされます。
最適なパフォーマンスを得るために、複数のディスクを 1 つの仮想 SCSI コントローラーに接続することをお勧めします。 VM に接続されているディスクの数をスケーリングするための他のオプションがない場合にのみ、コントローラーをさらに作成してください。
仮想ファイバー チャネル HBA
VM がファイバー チャネルおよび Fibre Channel over Ethernet (FCoE) 論理ユニット番号 (LUN) に直接アクセスできるように仮想ファイバー チャネル HBA を構成します。 仮想ファイバー チャネル ディスクは、ルート パーティションの NTFS ファイルシステムをバイパスするため、ストレージ I/O の 中央処理装置 (CPU) 使用率が低下します。 仮想ファイバー チャネル ディスクは、タイ容量のデータ ドライブや、ゲスト クラスタリングのシナリオで複数の VM 間で共有されるドライブに最適です。
仮想ファイバー チャネル ディスクを使用するには、1 つ以上のファイバー チャネル HBA をホスト コンピューターにインストールする必要があります。 各ホスト HBA では、Windows Server 2016 仮想ファイバー チャネルあるいは N_Port ID 仮想化 (NPIV) 機能をサポートする HBA ドライバを使用する必要があります。 記憶域ネットワーク (SAN) ファブリックも NPIV ポートをサポートする必要があり、NPIV をサポートするファイバー チャネル トポロジーのファイバー チャネル用のHBAポートを構成する必要があります。
複数の HBA のあるホストで処理能力を最大化するには、Hyper-V VM 内で複数の仮想 HBA を構成することをお勧めします。 VM ごとに最大 4 つの HBA を構成できます。 Hyper-V では、同じ仮想 SAN にアクセスするホスト HBA に対する仮想 HBA のバランスを自動的に調整します。
仮想ディスク
仮想ディスクは仮想コントローラーによって VM に公開され、ホスト上のバーチャル ハード ディスクまたはパススルー ディスクにすることができます。
仮想ディスクは、VHD または VHDX 形式で提供されます。 それぞれの形式で、3 種類の仮想ハード ディスク ファイルがサポートされています。
展開を Windows Server 2016 以降にアップグレードする場合は、すべての VHD ファイルを VHDX 形式に変換することをお勧めします。 詳細については、「VHDX 形式」を参照してください。
VHD 形式
以降のバージョンの Hyper-V では、より適切なアラインメントを可能にするために VHD 形式が強化されています。 Windows Server 2012 以降の Hyper-V では、VHD 形式のみをサポートする以前のバージョンとは対照的に、VHDX 形式と VHD 形式の両方がサポートされています。 その結果、新しいバージョンの Hyper-V は、大規模なセクター ディスクでパフォーマンスが向上します。
Windows Server 2012 以降で作成された VHD にはすべて、最適な 4 KB のアラインメントがあります。 アライメントされたこの形式は、以前のバージョンの Windows Server と完全互換性があります。 ただし、4 KB のアライメントに対応していないパーサー (以前のバージョンの Windows Server のパーサーや Microsoft 以外のパーサーなど) からの新しい割り当ての場合、アライメントプロパティはサポートされていません。
ディスクを VHD 形式に変換する
以前のバージョンの Hyper-V または Windows Server から新しいバージョンに VHD を移行しても、VHD 形式にディスクが自動的に変換されることはありません。
既存の仮想ディスクを VHD に変換するには、PowerShell ウィンドウを開き、次のコマンドを実行します。
Convert-VHD –Path <SourceDiskFilePath> –DestinationPath <ConvertedDiskFilePath>
たとえば、ドライブ E に test.vhd という名前のソース ディスクを、同じフォルダー内の test-converted.vhd に名前が変更された変換済みディスクに変換することを計画している場合は、次のコマンドを実行します。
Convert-VHD –Path E:\vms\testvhd\test.vhd –DestinationPath E:\vms\testvhd\test-converted.vhd
Note
VHD を変換する場合、PowerShell は [ソース からコピーする] というディスク オプションに基づいてソース VHD のデータを使用します。 詳細については、「Convert-VHD」を参照してください。
ディスクのアラインメントを確認する
ディスクを変換した後は、そのアラインメント変数をチェックして、PowerShell で Get-VHD コマンドを実行して、最適な 4 KB アライメントを使用していることを確認できます。 ソース ディスクと変換されたディスクのコマンドを実行し、値を比較して、変換されたディスクが 4KB アライメント対応であることを確認します。
ディスクのアラインメントを表示するには
PowerShell ウィンドウを開きます。
Get-VHDコマンドを実行して、ソース ディスクのアラインメント設定を表示します。Get-VHD –Path <SourceVHDFilePath>出力で、
Alignmentプロパティの値に注目します。 この例では、値は0です。これは、ディスクが 4 KB アラインメント対応ではないことを意味します。Path : <SourceVHDFilePath> VhdFormat : VHD VhdType : Dynamic FileSize : 69245440 Size : 10737418240 MinimumSize : 10735321088 LogicalSectorSize : 512 PhysicalSectorSize : 512 BlockSize : 2097152 ParentPath : FragmentationPercentage : 10 Alignment : 0 Attached : False DiskNumber : IsDeleted : False Number :Get-VHDコマンドをもう一度実行しますが、今度は変換されたディスクのファイル パスを使用します。Get-VHD –Path <ConvertedDiskFilePath>出力で、
Alignmentプロパティの値を確認します。 値は1になっています。これは、ディスクが新しい VHD 形式に正常に変換され、4 KB のアラインメント対応であることを意味します。Path : <ConvertedDiskFilePath> VhdFormat : VHD VhdType : Dynamic FileSize : 69369856 Size : 10737418240 MinimumSize : 10735321088 LogicalSectorSize : 512 PhysicalSectorSize : 512 BlockSize : 2097152 ParentPath : FragmentationPercentage : 0 Alignment : 1 Attached : False DiskNumber : IsDeleted : False Number :
VHDX 形式
VHDX は、更新されたハード ディスクの形式で、Windows Server 2012 で導入されました。 この形式では、最大 64 TB の容量の回復力のある高パフォーマンス仮想ディスクを作成できます。
Windows Server 2016 以降にアップグレードする場合は、すべての VHD ファイルを VHDX 形式に変換することをお勧めします。 VHDX 形式をサポートしていない以前のリリースの Hyper-V に VM を移行する必要がある場合にのみ、VHD 形式でファイルを維持します。
VHDX 形式の利点は次のとおりです。
最大 64 TB の仮想ハード ディスク記憶域容量をサポート
VHDX メタデータ構造体に更新情報を記録することで、電源障害時のデータ破損から保護
OS のバージョンや適用されたパッチなど、それを設定するユーザーが記録する内容に基づいて、ファイルのカスタム メタデータを格納します
VHDX 形式は、次のパフォーマンス機能も提供します。
大容量のセクター ディスクでのパフォーマンス向上のため、バーチャル ハード ディスク 形式のアラインメントを改善しました。
ダイナミック ディスクと差分ディスクのブロック サイズが大きくすることで、ディスクをワークロードの要件に合わせて調整可能に
4 KB 論理セクター仮想ディスクにより、4 KB セクター用に設計されたアプリケーションまたはワークロードでの使用時にパフォーマンスが向上
データを効率的に表現できるため、ファイル サイズが小さくなり、基盤となる物理記憶領域デバイスの未使用領域を再利用可能
注意
トリミングには、パススルー ディスクまたは SCSI ディスクとトリム互換ハードウェアが必要です。
仮想ファイル
VHD ファイルには 3 種類あります。
固定ファイルは回復性とパフォーマンスを向上させるものであり、ホスティング値のストレージがアクティブに監視されていない場合に使用する必要があります。 実行時に VHD ファイルを展開するときに十分なディスク領域があることを確認します。 任意のディスク形式で使用できます。
動的ファイルは、回復性を保証し、展開に必要なディスク領域を割り当てることを目的としています。 VHDX でのみ使用できます。
差分ファイルは、VM スナップショット チェーンを短く保ち、良好なディスク I/O パフォーマンスを維持します。 任意のディスク形式で使用できます。
固定ファイルの種類
固定 VHD ファイルを作成すると、システムはそれに対して領域を割り当てます。 固定ファイルは断片化する可能性が低く、1 つの I/O が複数の I/O に分割された場合の I/O の処理能力が低下します。 また、読み取りと書き込み操作でブロックのマッピングを検索する必要がないため、3 種類の VHD ファイル オプションの中で CPU オーバーヘッドが最も低くなります。
最適な回復性とパフォーマンスが必要な場合は、固定ファイルを使用することをお勧めします。
動的ファイルの種類
動的 VHD ファイルを作成すると、システムはオンデマンドで領域を割り当てます。 ファイル内のブロックは割り当てられたブロックとして開始され、未割り当てブロックをバックするスペースはありません。 ブロックに最初の書き込みが行われると、仮想化スタックはブロックに VHD ファイル内の領域を割り当て、メタデータを更新する必要があります。 この割り当てにより、書き込みに必要なディスク I/O の数が増え、CPU 使用率が増加します。 既存のブロックに対する読取りおよび書込みでは、メタデータでブロックのマッピングを検索する際に、ディスク アクセスおよび CPU オーバーヘッドが発生します。
VHDX ファイルを使用している場合は、ホスティング ボリューム上のストレージをアクティブに監視していない場合は、動的ファイルを使用することをお勧めします。 実行時に VHD ファイルを展開するときに十分なディスク領域があることを確認します。
差分ファイルの種類
差分ファイルは、ディスクへの書き込みを格納する VM のスナップショットです。 既存の書き込みのないブロックに書き込む場合、システムは動的に拡張する VHD と同様に VHD ファイルに領域を割り当てます。 ブロックに既に書き込みが含まれている場合、システム サービスは VHD ファイルから操作を読み取ります。 それ以外の場合、親 VHD ファイルからブロックにサービスが提供されます。 どちらの場合も、システムがメタデータを読み取り、ブロックのマッピングを決定します。 この VHD に対する読み取りと書き込みでは、固定 VHD ファイルよりも多くの CPU が消費され、I/O が多く発生する可能性があります。
スナップショットの数が少ないと、記憶域の I/O の CPU 使用率が通常よりも上昇する可能性がありますが、I/O 集約度の高いサーバー ワークロードを除けば、パフォーマンスに顕著な影響を与えることはありません。 VM スナップショットの大規模なチェーンを作成して使用すると、パフォーマンスの問題が発生します。 差分ファイルでは、VHD から読み取るためだけに、さまざまな差分 VHD の要求されたブロックに対してシステムがチェックする必要があります。 差分ファイルを使用する場合は、適切なディスク I/O パフォーマンスを維持するために、スナップショット チェーンを短く保つことをお勧めします。
サイズの考慮事項
ディスクの最適化を計画するときは、ブロック サイズとセクター サイズの両方を考慮する必要があります。 このセクションでは、ブロックとセクターのサイズ設定に関する推奨事項について説明します。
ブロック サイズ
ブロック サイズはパフォーマンスに大きな影響を与える可能性があるため、ディスクを使用して、ブロック サイズをワークロードの割り当てパターンと一致させることをお勧めします。 アプリケーションが 16 MB (メガバイト) のチャンクでブロックを割り当てる場合は、理想的には 16 MB (メガバイト) の VHD ブロック サイズを使用する必要があります。 2 MB (メガバイト)を超えるブロック サイズは、VHDX ファイル形式を使用する VHD でのみ可能です。 ランダム I/O ワークロードで、割り当てパターンよりも大きなブロック サイズを使用すると、ホスト上の VHD の領域使用量が大幅に増加することがあります。
セクター サイズ
ソフトウェア組織は多くの場合、512 バイトのディスク セクターに依存していますが、業界標準は 4 KB のディスク セクターに移行しています。 セクター サイズの変更によって発生する可能性のある互換性の問題を軽減するために、ハード ドライブのベンダーは、512 エミュレーション ドライブ (512e) と呼ばれる移行サイズを導入しています。
エミュレーション ドライブを使用すると、フォーマット効率の向上やエラー訂正コード (ECC) のスキームの改善など、4 KB のディスク セクターのネイティブ ドライブによって提供されるいくつかのメリットが得られます。 エミュレーション ドライブでは、ディスク インターフェイスで 4 KB のセクター サイズを公開すると、互換性の問題が少なくなります。
4 KB セクターを最大限に活用するには、512 バイトのディスク セクターではなく VHDX 形式を使用することをお勧めします。 ディスク サイズ間の互換性の問題を削減するには、移行サイズ設定用に 512e ドライブを実装します。
512e ディスクでの移行サイズのサポート
512e ディスクでは、物理セクターに関してのみ書き込み操作を実行できます。 この種類のディスクは、システムが発行する 512 バイトのセクターを直接書き込めません。 ディスクには、書き込み操作を可能にする内部プロセスがあります。これには、次の順序で Read-Modify-Write (RMW) 操作が含まれます。
まずディスクで、4 KB 物理セクターの内部キャッシュへの読み込みが行われます。 キャッシュには、書き込み操作で参照されている 512 バイトの論理セクターが含まれています。
次にディスクは、更新された 512 バイト セクターを含むように 4 KB バッファーのデータを変更します。
最後に、ディスクは更新された 4KB バッファをディスク上の物理セクタに書き戻します。
RMW プロセスの全体的なパフォーマンスへの影響は、ワークロードによって異なります。 この RMW プロセスは、以下の理由で、バーチャル ハード ディスクのパフォーマンスを低下させます。
容量可変 VHD および差分 VHD には、データ ペイロードの前に 512 バイトのセクター ビットマップがあります。 フッター、ヘッダー、および親ロケーターが 512 バイト セクターに整列されています。 バーチャル ハード ディスク ドライバーでは、これらの構造を更新するために 512 バイトの書き込み操作を実行します。これによってディスクで RMW プロセスが実行されます。
アプリケーションでは、一般的に、読み込み操作と書き込み操作を 4 KB の倍数のサイズで実行します (4 KB が NTFS の既定クラスタサイズであるため)。 動的仮想ハードディスクと差分仮想ハードディスクには、データ ペイロード ブロックの前に 512 バイトのセクター ビットマップがあります。 このビットマップにより、4 KB ブロックは物理 4 KB 境界に整列されません。 次の図は、物理的な 4 KB 境界に整列されていない VHD 4 KB ブロックを強調表示しています。
ペイロード データを更新するために現在のパーサーによって行われる 4 KB の各書き込み操作により、ディスク上の 2 つのブロックに対して 2 つの読み込み操作が行われます。 システムではその後ブロックが更新され、2 つのディスク ブロックに書き戻されます。 Windows Server 2016 の Hyper-V は、VHD スタック上の 512e ディスクに対するいくつかのパフォーマンスの影響を軽減します。 Hyper-V は、VHD 形式で 4 KB の境界に整列するための構造体を準備します。 この軽減策により、仮想ハード ディスク ファイル内のデータにアクセスする場合や、仮想ハード ディスクのメタデータ構造を更新するときに RMW 効果が回避されます。
前述のように、以前のバージョンの Windows Server からコピーされた VHD は、自動的に 4 KB に整列されません。 [ソースからコピー] ディスク オプションと Convert-VHD コマンドを使用すると、最適に整列されるようにディスクを手動で変換できます。
既定では、VHD は 512 バイトの物理セクターサイズで公開されます。 この方法により、旧バージョンの Windows Server からアプリケーションおよび VHD を移行したときに、物理セクターサイズに依存するアプリケーションが影響を受けなくなります。
既定では、システムで 4 KB の物理セクターサイズの VHDX ディスクが作成され、通常のディスクと大規模なディスクのパフォーマンス プロファイルが最適化されます。
ディスク サイズ間の互換性の問題を軽減するために、移行サイズ設定用に 512e ドライブを実装することをお勧めします。 4 KB のセクターを最大限に活用するには、VHDX 形式を使用します。
ネイティブ 4 KB ディスク
Windows Server 2012 R2 以降の Hyper-V では、4 KB のネイティブ ディスクがサポートされています。 仮想記憶域スタック レイヤーにソフトウェア RMW アルゴリズムを実装して、VHD ディスク データを 4 KB のネイティブ ディスクに格納することもできます。 このアルゴリズムは、512 バイトのアクセス要求と更新要求を、対応する 4 KB のアクセスと更新に変換します。
VHD ファイルは 512 バイトの論理セクター サイズのディスクとしてしか公開できないため、512 バイトの I/O 要求を発行するアプリケーションが存在する可能性があります。 このような場合、記憶域スタック レイヤーの RMW アルゴリズムが要求を満たし、パフォーマンスの低下を引き起こします。 論理セクター サイズが 512 バイトの VHDX ディスクでも同じ結果が発生します。
VHDX ファイルを 4 KB の論理セクター サイズのディスクとして公開するように構成できます。 この実装は、4 KB のネイティブ物理デバイスでホストされているディスクのパフォーマンスに最適な構成です。 ただし、4 KB の論理セクター サイズで、仮想ディスクを使用するゲストとアプリケーションの両方がサポートされるように注意してください。 VHDX 形式は、4 KB の論理セクター サイズのデバイスで正しく動作します。
VHD ファイルと VHDX ファイルで 4 KB のネイティブ ディスクを使用しないことをお勧めします。パフォーマンスが低下する可能性があります。 シナリオで 4 KB のネイティブ ディスクが必要な場合は、4 KB の論理セクター サイズのデバイスで VHDX 形式を使用する必要があります。
パススルー ディスク
VM の移行シナリオで導入された制限により、パススルー ディスクを使用することは避けることをお勧めします。
VHD ファイルではなく、VM 内の VHD を物理ディスクまたは論理ユニット番号 (LUN) に直接マッピングすることは、パススルー ディスクと呼ばれます。パススルー ディスクは、ルート パーティション内の NTFS ファイル システムをバイパスでき、これにより、ストレージ I/O の CPU 使用率が削減されます。 ただし、パススルー ディスクを使用すると、物理ディスクや LUN のマシン間での移行が VHD ファイルよりも困難になるリスクも伴います。
高度なストレージ機能
このセクションでは、高度なストレージ機能について考慮する必要があるパフォーマンスの最適化について説明します。
記憶域のサービスの品質 (QoS)
Windows Server 2012 R2 以降、Hyper-V には、VM 上の記憶域に対して特定の QoS (サービス品質) パラメーターを設定する機能が含まれています。 記憶域 QoS を実装して、追加の記憶域パラメーターにアクセスし、仮想ハード ディスクの最大/最小 IOPS しきい値を設定し、ディスクのパフォーマンスを監視することをお勧めします。 これらのパラメーターを実装すると、以下の利点を得られます。
マルチテナント型の環境で記憶域パフォーマンスの分離を構成する
仮想ハード ディスクの 1 秒あたりの最大および最小の入出力操作 (IOPS) を指定する
- 管理者は、1 つのテナントが他のテナントに影響を与える可能性のある過剰な記憶域リソースを消費しないように、記憶域の I/O を調整できます。 最小 IOPS 値を設定し、システムで最適なパフォーマンスのしきい値が満たされない場合に通知を受け取ります。 最大 IOPS 値と最小 IOPS 値を、8 KB ごとのデータを I/O とする正規化 IOPS で指定します。
VM ワークロードを効率的に実行するために、記憶域の I/O パフォーマンスが定義されたしきい値を下回ったときに通知を受け取る
VM メトリック インフラストラクチャの記憶域パラメーターにアクセスし、管理者がパフォーマンスとチャージバック関連のパラメーターを監視できるようにする
ただし、記憶域 QoS には次の制限があることにも注意してください。
仮想ディスクでのみ使用可能
差分ディスクは、親仮想ディスクを別のボリュームに置くことはできない
レプリカ サイトの QoS がレプリカ - プライマリ サイトとは別に構成される
記憶域 QoS は共有 VHDX をサポートしていません
詳細については、「Hyper-V の記憶域のサービスの品質」を参照してください。
大規模な VM の NUMA I/O レジストリ設定
Windows Server 2012 以降では、Hyper-V VM への仮想 Non-Uniform Memory Access (NUMA) トポロジの適用がサポートされています。 NUMA のサポートは、大量のメモリで構成された VM、または大規模な VM で実行されているワークロードのパフォーマンスを向上させるのに役立ちます。 大規模な VM 構成でこのサポートを有効にするには、I/O スループットの面でスケーラビリティが必要です。 大規模な VM の例には、64 個の仮想プロセッサで実行されている Microsoft SQL Server などがあります。
次の Windows Server の機能強化により、大規模な VM の I/O スケーラビリティ要件を満たすことができます。
ゲスト デバイスとホスト記憶域スタックの間の通信チャネルの増加。
より効率的な I/O 完了メカニズムで、仮想プロセッサ間で割り込みを分散して、負荷の高いプロセッサ間割り込みを回避します。
レジストリ キー
Windows Server NUMA レジストリ キー設定を使用して、大規模な VM で実行されているワークロードのパフォーマンスを向上させることをお勧めします。
前のセクションの拡張機能をサポートし、チャネルの数を調整できるように、いくつかのレジストリ エントリを追加および更新しました。 エントリは HKLM\System\CurrentControlSet\Enum\VMBUS\<device id>\<instance id>\StorChannel にあります。
パスの <device id>\<instance id>\ の部分は、構成の関連する値に対応しています。 また、これらのレジストリ エントリでは、I/O 完了を処理する仮想プロセッサを、アプリケーションによって I/O プロセッサとして割り当てられた仮想 CPU に整列させます。 システムは、レジストリ設定を、デバイスのハードウェア キーに基づいてアダプターごとに構成します。
検討すべき 2 つの主な設定を次に示します。
ChannelCount (ダブルワード) は、展開で使用できる通信チャネルの合計数です。 最大値は 16 です。 チャネル数の既定値は、仮想プロセッサの数を 16 で割った値に等しくなります。
ChannelMask (QWORD) は、チャネルに対するプロセッサのアフィニティです。 このキー設定を指定しない場合、または値が 0 の場合、チャネル マスクは、通常の記憶域またはネットワーク チャネルの既存のチャネル分散アルゴリズムに既定で設定されます。 既定のアクションにより、記憶域チャネルはネットワーク チャネルと競合しません。
オフロード データ転送の統合
オフロード データ転送 (ODX) 操作を使用して、VM ワークロードが物理環境で可能な方法で ODX 対応ストレージを使用できるようにすることをお勧めします。
VHD の重要なメンテナンス タスク (統合、移動、圧縮など) では、大量のデータをコピーする必要があります。 データをコピーする現在の方法では、システムが異なる場所へのデータの読み取りと書き込みを行う必要があります。これは時間がかかり、VM のサービスに使用される可能性のあった CPU リソースとメモリ リソースを使用します。
記憶域ネットワーク (SAN) ベンダーは、ODX と呼ばれるハードウェア機能を提供できます。 この機能により、大量のデータにをほぼ瞬時にコピーできる操作が提供されます。 ODX を使用すると、ディスクではなくシステムで、特定のデータ セットをある場所から別の場所に移動する方法を指定できます。
Windows Server 2012 以降の Hyper-V では ODX 操作がサポートされているため、コピーしたデータをゲスト OS からホスト ハードウェアに渡すことができます。 ワークロードでは、非仮想環境の場合と同様に、ODX 対応ストレージを使用できます。 Hyper-V ストレージスタックはまた、ディスクの統合や大量のデータ移行中の移行メタ操作の保管など、VHD のメンテナンス操作中にODX 操作を発行することができます。
マップ解除通知の統合
マップ解除通知を使用して VHDX ファイルの効率をさらに向上させ、基盤となる物理記憶領域デバイスで未使用領域を再利用できるようにすることをお勧めします。
VHD ファイルは、ストレージ ボリューム上のファイルとして存在し、使用可能な領域を他のファイルと共有します。 ファイル サイズが大きくなる傾向があるため、VHD ファイルは大量の領域を占有する可能性があります。 記憶域スペースの需要が高いほど、IT ハードウェアの予算に影響します。つまり、可能な限り物理領域の使用を最適化する必要があります。
Windows Server 2012 より前のバージョンの Windows Server では、ゲスト OS と Hyper-V ホストの Windows ストレージ スタックに制限があり、記憶域スペースを最適化できません。 アプリケーションが VHD 内のコンテンツを削除しても、記憶域スペースは破棄されたままになります。 システムは、削除された情報について VHD または物理記憶領域デバイスに通知しないため、Hyper-V ストレージ スタックが VHD ベースの仮想ディスク ファイルの領域を最適化できませんでした。 そのため基になる記憶装置は、削除されたデータが占有する未使用の領域を再利用できませんでした。
Windows Server 2012 以降、Hyper-V では マップ解除通知 がサポートされています。 この機能により、VHDX ファイルは削除されたデータをストレージ スタックに報告します。これにより、ファイル サイズのトリミングを維持し、スタックが他の用途のために未使用の記憶領域を再利用できるため、効率が最大化されます。
ゲスト OS からの unmap コマンドがホスト仮想記憶域スタックに到達できるのは、Hyper-V 固有の SCSI、対応する IDE、仮想ファイバー チャネル コントローラーだけです。 VHD では、VHDX に設定済みの仮想ディスクのみで、ゲスト OS からの unmap コマンドがサポートされています。