GPU-P デバイスでのライブ マイグレーション

この記事では、SR-IOV (シングル ルート I/O 仮想化) パーティション分割によって仮想化された異種コンピューティング デバイス (GPU、NPU など) のライブ マイグレーションの機能設計について説明します。 WDDM ドライバー モデルと MCDM ドライバー モデルを使用したパーティション分割をサポートするデバイスは、Microsoft の仮想化オファリングの不可欠な部分となっています。 そのため、ライブ マイグレーションをサポートすること、そしてリソースの割り当てを変更する必要がある場合に、顧客への影響の点で、仮想化の抽象化が最大限に信頼できるものになるよう支援することが重要です。 この記事では、これらのデバイスのクイック マイグレーションについても説明します。

ライブ マイグレーションは Windows 11 バージョン 24H2 (WDDM 3.2) 以降でサポートされています。 より一般的には、機能を公開するドライバーの GPU 準仮想化 (GPU-P) DDI の拡張機能です。 GPU-P 仮想化インターフェイスを実装する MCDM ドライバーは、必要に応じて、トリアージ イベントを持つ拡張機能を含むこれらのライブ マイグレーション インターフェイスを実装することもできます。

この記事において「GPU」とは、単に GPU-P 仮想化フレームワークを実装するデバイスを指し、WDDM か MCDM か、GPU か NPU か、あるいはその他の異種コンピューティング デバイスかは関係ありません。

リソース移行の種類と目的

リソース移行とは、仮想化を新しい物理リソースに移動する機能です。 仮想化された実行は、次のようなさまざまな方法で移動できます。

• ハード電源オフ。 仮想マザーボードは直接電源を切ることができ、仮想リソースの実行を停止します。 電源のオフに対応していないアプリケーションでは操作しているデータが失われ、すべてのデバイス状態がワイプされます。 その後、仮想ハード ディスク (VHD) を別のホスト コンピューターで仮想化できるため、コールド ブートが実行されます。

• ソフト電源オフ。 この電源オフは、単にゲスト OS に電源要求を送信するという点で、ハード電源オフとは異なります。 その後、ゲスト OS は電源オフ メカニズムをアプリケーションに配布し、クリーンにシャット ダウンします。 アプリケーションではこの通知を使用することで、すべてのデータを安全に格納し、起動時に再起動するように登録できますが、これは各アプリケーションのプログラミングに依存します。 ソフト電源オフでは、このクリーン シャットダウンのメカニズムと、現在の状態を格納し、再電源オン時に再起動するための適切なサービスをサポートするゲスト OS が必要です。

• 休止状態。 この他のゲスト由来のテクノロジを使用すると、ゲストは高速起動スリープ電源状態に移行できます。この状態では、すべてのアプリケーション プロセスがフリーズし、デバイス状態が CPU メモリにパージされ、すべてのメモリがストレージに送信されてハードウェアの電源をオフにできます。 その後、VM ストレージ VHD を別のマシンで再起動すると、メモリの読み込み、デバイス状態の復元、プロセスのフリーズ解除ができます。 休止状態は、休止状態がサポートされているゲスト OS でのみ使用できます。 これは、ゲストの安定性に依存する干渉の多いプロセスですが、電源オフのメカニズムでは提供されない状態でアプリケーション プロセスを復元するメカニズムを提供します。

• クイック マイグレーション (VM の保存と復元とも呼ばれる)。 このテクノロジを使用すると、VM は一時停止され (vCPU がスケジューリングを停止)、新しい物理リソースの状態を復元するために必要なすべての状態がホスト OS 内に集められます。これには VM のメモリとすべてのデバイスの状態が含まれます。 その後、この状態は新しいホストに転送され、すべての vCPU コンテキストが読み込まれた VM が作成され、メモリが VM スペースにマップされてデバイスの状態が復元されます。 その後、PowerOnRestore によって vCPU の実行が再開されます。 このテクノロジはゲスト OS から独立しており、ゲスト環境での実行に依存しないため、休止状態よりも信頼性の高い、プロセスとデバイスの状態を維持管理する方法となっています。 VM メモリの消費量が GB 単位になり、転送時間が極めて長くなる可能性があるため、仮想化ユーザーが大幅なダウンタイムに気付く場合があります。

• ライブ マイグレーション。 仮想化されたリソースがまだアクティブな状態でコンテンツを転送する機能があり、ダーティになったコンテンツを追跡できる場合は、仮想化をアクティブのままにしたまま、重要なコンテンツを転送できます。 その後、VM が一時停止されると、転送する必要があるコンテンツがはるかに少なくなり、仮想化が実行されない時間を最小限に抑えることができます。 その結果、移行中に発生するすべての操作が妨げられることなく継続され、リソース消費率への影響が現在可能な限り軽減されるため、エンドユーザーへの影響を最小限に抑えられます。 特に、停止期限 (外部エンドポイントを使用した TCP やその他のプロトコル タイムアウトなど、仮想化の停止に対する外部時間の制約) を最小限に抑えたり、排除したりできます。

それぞれの進行により、仮想化の物理的な割り当ての変更に顧客が気付く可能性が軽減されるかある程度 (通常は大幅に) 排除され、仮想化がより完全になってユーザーに対して透過的になります。 インフラストラクチャに対する顧客の依存関係を分離する他のテクノロジ (ホスト クラッシュの分離など) と共に、仮想化ソリューションは割り当ての独立性と真のエフェメラル コンピューティングの理想に移行します。

大規模な設計

ライブ マイグレーションでは、仮想化コンテンツをソース ホストからターゲット ホストに転送します。 仮想化は、メモリ、コンピューティング、ストレージを含むさまざまなステートフル デバイスで構成され、それぞれにソース上のデバイスからターゲット上のデバイスに転送する必要があるデータが含まれます。 クラスター間の仮想化を管理するエグゼクティブ エージェントはホストと通信し、既存の VM のソース移行 (コンテンツがホストから離れる場合) または新しい VM へのターゲット移行 (コンテンツを受信する目的) のためにオーケストレーションを設定するように通知します。 この相互作用の主要なプレイヤーを次の図に示します。

:

ソース ホストのエポック

次の図はソース側の移行状態を示しています。

:

ソース側のブート

一般的にホストが起動すると、KMD はさまざまな初期化呼び出しを通じてカーネルにデバイス機能を報告します。

KMD は DXGKQAITYPE_GPUPCAPS データの DxgkDdiQueryAdapterInfo 呼び出しを受信すると、DXGK_GPUPCAPS に追加された LiveMigration 機能ビットを設定できます。 KMD でこのビットが設定された場合に、ドライバーではライブ マイグレーションがサポートされることを示します。

ライブ マイグレーション サポートの前提条件は、「ダーティ ビット トラッキング」で説明されているように、すべての GPU ローカル メモリ セグメントで変更された VRAM ページの追跡をサポートすることです。 そのサポートは、他の指定された情報タイプに対する他の DxgkDdiQueryAdapterInfo 呼び出しを通じて報告されます。 ライブ マイグレーションのサポートを報告するドライバーは、ダーティ ビット トラッキングのサポートも報告する必要があります。 ライブ マイグレーションはサポートしているがダーティ ビット トラッキングはサポートしていない構成は無効であり、Dxgkrnl はアダプターの起動に失敗します。

VM がオンライン

ホストが起動し、管理スタックがオンラインになると、仮想マシンのアクティビティがインターネットに接続し始めます。 VM の起動と停止の要求が届き始め、GPU-P vGPU がこれらの仮想化に投影され始めます。

パフォーマンスの高いダーティ ビット プレーン機能を想定した場合、Dxgkrnl は VF (仮想関数) の VRAM リソースを予約した後に DxgkDdiStartDirtyTracking を呼び出します。これにより、後で VF が移行シナリオに参加した場合に、システムで VRAM のクリーンさを追跡できます。

この VM のスタートアップにより、割り込みテーブル アクセスのインターセプトが始まり、割り込みサポートが仮想化され、VM の有効期間にわたってこの状態が続きます。

ライブ マイグレーション送信の準備

管理スタックは、コントロールによって示されたときにライブ マイグレーションを開始するイベントを送信します。移行状態マシン管理は、ターゲット上の vGPU を再構築するために、仮想化の有効期間中は不変である仮想デバイスからすべての状態を収集します (vGPU パーティション構成メトリック)。 準備ができたら、トランスポート バッファーの準備とトランスポート スタックの初期化のプロセスが開始されます。

このエポックにより、導入された DxgkDdiPrepareLiveMigration DDI への呼び出しが生成されます。 KMD は、VF の適正なパフォーマンスを維持しながら、ホスト内の VRAM からダーティ コンテンツをストリーミングするライブ マイグレーションの機能を規定する PF/VF スケジューリング ポリシーを確立する必要があります。 ダーティ トラッキングがパフォーマンスの低いものとして報告された場合、このタイミングでダーティ トラッキングは開始されます。

ライブ マイグレーション送信

:

次に、ダーティ VRAM 転送のアクティブ フェーズに入ります。 このフェーズでは、ダーティ ビットプレーン DDI を介して VF フレームバッファーのスナップショットを取得する呼び出しを行い、それらのページを GPU から先ほど準備した CPU バッファーにページングする必要があります。

この転送には、VM とそのすべての仮想デバイスが一時停止される段階があります。 ゲストについては VF のスケジュール設定を停止でき、そしてこの時点で、コンテンツのページングを完了するために PF に指定できる追加のタイムスライスが存在しているはずです。 VF と vCPU の両方が VM で一時停止されるため、この時点以降、移行されるコンテンツ (CPU またはデバイスローカル メモリ) への変更はありません。

一時停止されている移行の送信

ダーティ ページの最後のイテレーションは一時停止中に転送されます。 この時点で、アクティブである間は変更可能だったために先ほどの準備時に転送できなかったデバイスとドライバーの状態の最後の部分を収集する呼び出しが行われます。 この状態は、他方で必要な状態の再構築、トラッキング構造、または一般にターゲット側の VF 状態の復元を完了するために必要なすべての情報になります。

ライブ マイグレーションの破棄

最後に、VM とそのすべての仮想デバイスがその状態を新しい物理的実現に転送すると、ソース側で VM の残りの部分をクリーン アップできます。 バッファーとその他の移行状態がクリアされ、vGPU が破棄されます。

ターゲット ホストのエポック

次の図はターゲット側の移行状態を示しています。

:

ターゲット側のブート

ターゲットでのブートはソースと同じように見えます。 ブートはシステム全体を対象としており、ライフサイクル全体を通じて異なる VF のソースとターゲットにすることができます。 ドライバーは、参加するライブ マイグレーションのサポートを指定するだけで済みます。

ライブ マイグレーション受信準備

ターゲット側では、VM が構成され、新しい VM であるかのように起動します。 VM と仮想デバイスが作成されます。 この作成プロセスには、ソース側での作成時に使用した同じパラメーターを使って作成された仮想 GPU が含まれます。 作成後、検証データが受信されてドライバーに渡され、VM を復元するソースとの互換性がターゲット側にあるかどうかが検証されます。 その時点で、ドライバーのバージョン、ファームウェアのバージョン、ターゲット システムとドライバーのその他のアンビエント状態など、前述の互換性に影響を与える可能性のあるものがあれば確認する必要があります。 ドライバーは、VF がまだアクティブでない間に通常 VF に割り当てられるページングの、すべてのタイムスライスへの PF アクセスを許可するように構成します。

ライブ マイグレーション受信

:

ダーティ ページ データの受信は、ページングの方向が CPU バッファーから VRAM である点を除き、ソース上のステージと似ています。 VF が一時停止している間にすべての転送が行われるため、VF 予算内で転送全体を実行できます。

VM の起動と破棄

すべての VRAM 移行が完了すると、vGPU は転送する必要がある追加の状態 (最終的な、変更可能な保存データ) を設定する機会を得ます。 次に、ターゲットで VM を起動し、転送に使用されるバッファーを含め、移行状態を破棄します。

パフォーマンス目標

ライブ マイグレーションの重要な部分はその応答性です。 特に、外部から (仮想化のユーザーにも、接続先のエンドポイントにも) 応答しない仮想化のダウンタイムを最小限に抑えます。 ネットワーク スタック プロトコルの多くでは、再試行/再確立が失敗する前に非常に短いタイムアウトがリモート コンピューター間で発生するため、ドロップするとユーザーに混乱を招く可能性があります。 一般的な固定目標として、転送と開始の一時停止時間の合計を 1 秒の 4 分の 3 (750 ミリ秒) 未満にする必要があります。この場合、最も一般的なスタック タイムアウトの多くで連絡先のタイムアウト時間がプッシュされます。

さらに、アクティブなシステムに対するパフォーマンスの変更によって、可能な限り、他のエンドユーザーの中断がトリガーされないようにする必要があります。 これらの DDI を使用するデバイスでは、スケジュールされたタイムスライスを遅らせて、システムが TDR のレートを大幅に上げないようにする必要があります。 現在、ほとんどの TDR は長いパケットではなくデバイスをハングさせることが想定されているため、パケットの実行時間を 2 倍または 3 倍にしても、タイムアウト秒数が長い場合にほとんどのパケットがプッシュされません。 ただし、一般的なパフォーマンスの状況ではタイムアウトがトリガーされないことに注意する必要があります。

デバイス ドライバー インターフェイス

一般に、ライブ マイグレーション DDI は、WDDM および MCDM DDI の一般的な概念と、特に GPU-P 仮想化 DDI を指します。

• hAdapter は通常、このドライバーが管理する特定のデバイスを表すハンドル トークンを指します。 システムによって列挙された複数の物理デバイスがあるシステムでは、ドライバーが複数の hAdapter を管理する可能性があるため、hAdapter は特定のデバイスにローカライズされます。

• vfIndex は参照されている仮想関数/vDEV を識別します。 特定の仮想デバイスにローカライズされます。 パーティション ID と呼ばれることもあります。

• DeviceLuid は特定の仮想デバイスもローカライズしますが、仮想デバイス管理を使用して UMED インターフェイスの言語でダウンします。

• SegmentId は、デバイスに保存されているコンテンツ (VRAM 予約など) を参照するときに、特定の VidMm セグメント露出を識別します。

インターフェイスの定義に関する注意

この記事では、動的にサイズ設定された構造体について説明します。 こうした構造体は、動的にサイズ設定された配列を通じて実装されます。この配列は、参照ページで次のように記述されています。

    size_t       ArraySize;
    ElementType  Array[ArraySize];

ここで、インターフェイスは構造体の前の配列サイズを渡し、インターフェイス オブジェクトの解析は、配列が指定されたときにその多くの要素を反復処理します。 これらの言語は静的にサイズ設定されたフラグメントを表すため、これらの宣言は有効な C/C++ ではありません。 最初に静的なサイズの構造体を読み取り、次にコードで動的に解析します。

デバイスの起動と上限のレポート

次の機能が DXGK_GPUPCAPS に追加されます。

• LiveMigration の上限は、ライブ マイグレーション機能に対するドライバーのサポートを示します (一般に、DxgkDdiSetVirtualGpuResources2 を除き、この記事で言及している追加された DDI)。
• ScatterMapReserve の上限は、将来のリリースで追加される DxgkDdiSetVirtualGpuResources2 のドライバー サポートを示します。

OS が DxgkDdiQueryAdapterInfo を DXGKQAITYPE_GPUPCAPS 要求で呼び出すときは、KMD でこれらの上限を入力する必要があります。 DxgkDdiStartDevice が呼び出された後、およびアダプターが GPU パーティション分割をサポートしている場合、OS はデバイスの初期化中に上限を照会します。

ドライバーが ScatterMapReserve 上限を返す場合は、OS がドライバーのスキャッター予約機能を照会できるように、追加された DXGKQAITYPE_SCATTER_RESERVE 型を次の関連する構造体で公開する必要があります。

• pInputData の場合は DXGK_QUERYSCATTERRESERVEIN
• pOutputData の場合は DXGK_QUERYSCATTERRESERVEOUT

スキャッターページングのサポート

この機能は、フレームバッファーとの間で連続しないダーティ ページの転送をサポートするために、連続した物理アドレスでサポートされていない GPU-VA マッピングを最初に実行する機能の 1 つです。 現在のページング インターフェイスは、常にページ テーブルでサポートされている一般可能性であるため、このサポートのために更新する必要はありません。 ただし、連続性に関する仮定を行った潜在的な実装の詳細は、この変更によって公開される可能性があります。 そのため、この OS メカニズム、および仮想ページング インターフェイスを実行する仕組みを理解し、ページングがこの変更に対して堅牢であることを確認することが重要です。

特に、TransferVirtual インターフェイスは、フレームバッファー上で連続してマップされていない VA 範囲を渡すようになりました。

ライブ マイグレーション開始の送信側

システムは、移行のライブ コンポーネントを開始するときに、追加された DxgkDdiPrepareLiveMigration DDI を呼び出す必要があります。 この呼び出しは、このエポックが開始されたことをドライバーに通知し、移行の VF スケジューリング ポリシーを構成できるようにします。これにより、PF ページング用に自由に使用できる VF 移行予算の一部を割り当てる必要があります。

その後、Dxgkrnl は KMD の DxgkDdiSaveImmutableMigrationData DDI を呼び出し、ターゲット側で復元するデバイスに関する情報を収集します。

システムで不変データと検証データを収集して送信すると、ダーティ送信のメイン反復ループが開始されます。

反復保存/送信

概要セクションで説明したように、反復保存操作では DxgkDdiQueryDirtyBitData を使用して、各イテレーションの開始時に VF の現在のダーティ ビットプレーンをスナップショットし、標準の DXGK_OPERATION_VIRTUAL_TRANSFER 操作を使用して報告されたダーティ ページをページングします。 ダーティ トラッキング機能について、パフォーマンスへの影響がごくわずかではないことを報告したデバイスでこの操作が発生した場合、システムの反復制御では最初にダーティ トラッキングが有効になり、最初の呼び出しの前にフレームバッファー全体が転送され、ダーティ ビットプレーンに対してクエリが実行されます。

仮想転送の場合、マッピングが連続した VA から連続した PA に対して行われていないことがプライマリ更新動作となります。 代わりに、マッピングの下に PA の切断されたページが存在する可能性があります。 それ以外の場合、動作は元のページングとダーティ ビットプレーン トラッキングに関するドキュメントで説明されているとおりであり、この機能は追加されません。

ライブ マイグレーション終了の送信側

移行の終了時に、まだ転送されていない再構築状態とトラッキングを完了するために必要なすべてのデバイスとドライバーの状態をシステムで収集する必要があります。 このデータを転送できなかったのは、先に説明した移行データの不変性要件に適合せず、VRAM ダーティ コンテンツではなかったためです。 Dxgkrnl は追加された DxgkDdiSaveMutableMigrationData DDI を呼び出してこれを行います。 この DDI の使用方法は DxgkDdiSaveImmutableMigrationData と似ています。

最終的に、この VF で移行構成の必要がなくなったら、DxgkDdiEndLiveMigration が呼び出されます。 すべてのスケジューリングと状態は移行されない構成に戻ります。

ライブ マイグレーション開始の受信側

不変データが受信側に入ると、システムは DxgkDdiRestoreImmutableMigrationData への呼び出しを通じてそれを直接 KMD に渡します。

この DDI は、現在一時停止されている VF に対してのみ呼び出す必要があります。

反復復元/受信

ここでも、スキャッター ページングは反復的に動作しますが、今回は、ターゲットのダーティ ビットプレーンがページングによって構築されるため、VF によって予約されたフレームバッファーに関連付けられているダーティ ビットプレーンを検査する呼び出しはありません。 ページングの方向が逆になります。 受信したバッファー内のコンテンツは、ページの配置が決められた状態で VRAM に転送されます。

ライブ マイグレーション終了の受信側

移行が終了すると、受信側システムは、復元する状態の最終的なパッケージでドライバーの DxgkDdiRestoreMutableMigrationData 関数を呼び出します。 このパッケージは、ドライバーが状態の復元とトラッキングのために転送するため、および VF 状態の残りの復元のためにすべてのコンテンツを提供する必要があります。

この DDI は、現在一時停止されている VF に対してのみ呼び出す必要があります。

この呼び出しの後、システムは KMD の DxgkDdiEndLiveMigration 関数を呼び出して、通常の VF スケジューリングの復元など、ライブ マイグレーションに関する状態をクリーン アップすることをターゲット側に通知します。

UMED との通信

ユーザーモード エミュレーション DLL (UMED) インターフェイスは IGPUPMigration インターフェイスと共に拡張され、ライブ マイグレーション中にコンテンツを保存および検証する機能が公開されます。

HRESULT SaveImmutableGpup(
    [in]     PLUID     DeviceLuid,
    [in,out] UINT64 *  Length,
    [in,out] BYTE *    SaveBuffer
    );

HRESULT RestoreImmutableGpup(
    [in] PLUID   DeviceLuid,
    [in] UINT64  Length,
    [in] BYTE *  RestoreBuffer
    );

KMD が同様に呼び出されるライブ マイグレーション準備アクションの間、UMED は、移行のために UMED の準備に役立つ可能性のある情報を送信したり、UMED レベルで環境が移行をサポートしていることを検証したりする機会を得ます。 これは、UMED の標準インターフェイス コントラクト (スレッド処理とプロセス コンテキスト、制限付き OS 公開など) がある UMED のオプション インターフェイスです。 その呼び出しパターンは KMD DDI を模倣し、2 フェーズの保存が行われます。 これらの呼び出しは、デバイスとその LUID の有効期間を通じて有効で一定である必要があるため、他の保存/復元 UMED インターフェイスのような状態フラグはありません。

UMED の変更可能な状態は、既存の保存/復元インターフェイスで転送されます。 以前は、このインターフェイスは GPU-P ドライバーでの実行がブロックされていましたが、KMD で LiveMigration のサポートが報告されるとブロックが解除されます。 この UMED コールアウト関数と KMD 機能の紐づけは意図的なものです。 ライブ マイグレーションは、システムがこれらのデバイスの仮想化のためにクイック マイグレーションを実装する方法です。 同じ一連のタスクが実行されるため、クイック マイグレーション (保存/復元) を、アクティブな転送のない特殊なケースのライブ マイグレーションと考えることができます。 保存/復元をサポートする UMED でも、ライブ マイグレーション DDI をサポートする KMD が必要です。 同様に、UMED は IGPUPMigration インターフェイスを認識し、KMD をライブ マイグレーションする前にその設計で必要かどうかを評価する必要があります。

割り込みの仮想化

移行中にベースとなるハードウェアの変更に応じて MSI-X テーブル アクセスを適切に処理するには、ゲスト割り込み管理の物理アドレス指定を仮想化する必要があります。 UMED は、ライブ マイグレーションをサポートするすべてのドライバーで MSI-X 割り込みテーブルをインターセプトする必要があります。 [メッセージの上位アドレス] フィールドと [メッセージ アドレス] フィールドへの読み取りまたは書き込みはすべて、実際のハードウェア値にマップする必要があります。 Dxgkrnl は仮想化された (またはゲスト) アドレスのマッピングを維持し、呼び出しスタックで必要に応じて置換を実行します。

OS は、テーブルの読み取りまたは書き込みがゲスト側を参照する可能性があるゲスト物理アドレスの仮想化/マッピングを管理し、実際の割り込みサービスに必要なホスト物理アドレスを使用します。 この一般的なパスでは、個別の UMED 実装やカーネル転送は必要ありません。また、OS がテーブルをインターセプトしても、OS は UMED に通知しません。 UMED の唯一の要件は、テーブルの BAR ページに対してデバイスの軽減策を設定する必要があるということです。

ただし、カーネルでは、Dxgkrnl で KMD による実際の書き込みの処理が必要です。 KMD ではこれを行うために、追加された DxgkDdiWriteVirtualizedInterrupt コールバック関数を実装します。

UMD は (仮想化/ゲスト翻訳形式で) 書き込みをローカルで追跡するため、読み取りの必要はありません。そのため、高価なカーネル ジャンプは必要ありません。 このトラッキングは仮想デバイスと共に移行されます。

DDI 同期と IRQL コンテキスト

VF スケジューリングに関する重要な考慮事項

転送の効率は、PF でのページング転送のスケジューリングに大きく左右されます。 PF がバスを飽和させ、最高のスループットを得るために使用できるデバイスのページング エンジンへのアクセスが多いほど、一般的に転送のパフォーマンスが向上し、特に一時停止されている転送でそれが顕著になります。 特定の時間内にキャプチャして送信できるコンテンツが多いほど、少なくともネットワークの飽和状態までパフォーマンスが良くなります。

スケジュール設定の変更はページング エンジンにのみ影響し、他のデバイス リソースには影響しないことが理想的ですが、すべての VF スケジューリング設計でこれが可能なわけではありません。 最低でも、スケジュール設定には以下が必要です。

• 移行対象の VF または未割り当て VF スケジュールからのみ予算を取得します。
• コンピューター上の他の仮想化のパフォーマンスを低下させないようにします。

ターゲット側では、VF が転送全体を一時停止し、予算全体を使用できるため、これらの条件をはるかに簡単に満たすことができます。 ソース側では、移行のニーズと VM のニーズのバランスを取る必要があり、最終的には一時停止転送の目標を満たす必要があります。