この例では、拡張可能な予約を持つリソース プールの機能を示します。

図に示すように、次のシナリオを想定しています。

  • 親プールの RP-MOM に、6GHz の予約と、1GHz を予約する実行中の 1 台の仮想マシン VM-M1 があります。

  • 2GHz の予約を持ち、拡張可能な予約 が選択された子リソース プール RP-KID を作成します。

  • それぞれ 2GHz の予約を持つ 2 台の仮想マシン VM-K1 と VM-K2 を子リソース プールに追加し、これらの仮想マシンのパワーオンを試みます。

  • VM-K1 は、(2GHz を持つ) RP-KID からリソースを直接予約できます。

  • VM-K2 が使用できるローカル リソースはないので、VM-K2 は親リソース プール RP-MOM からリソースを借ります。RP-MOM は、6GHz マイナス 1GHz (仮想マシンによる予約) マイナス 2GHz (RP-KID による予約) を持ち、3GHz が未予約として残ります。3GHz が使用可能なので、2GHz の仮想マシンをパワーオンすることができます。

    図 1. 拡張可能なリソース プールを使用したアドミッション コントロール:正常にパワーオンされた場合


    拡張可能なリソース プールと正常にパワーオンされた仮想マシンとのアドミッション コントロール

次に、VM-M1 と VM-M2 を使用した別のシナリオについて考えます。

  • 予約の合計が 3GHz である、RP-MOM 内の 2 台の仮想マシンをパワーオンします。

  • この場合でも、2GHz はローカルで使用可能なので、RP-KID 内の VM-K1 をパワーオンすることができます。

  • VM-K2 をパワーオンするとき、RP-KID には未予約の CPU 容量がないため、親を確認します。RP-MOM には未予約で使用可能な容量が 1GHz しかありません (RP-MOM 用に 5GHz が使用済みで、ローカル仮想マシンが 3GHz を予約し、RP-KID が 2GHz を予約しています)。その結果、2GHz の予約が必要な VM-K2 をパワーオンできません。

    図 2. 拡張可能なリソース プールを使用したアドミッション コントロール:正常にパワーオンされなかった場合


    拡張可能なリソース プールと正常にパワーオンされなかった仮想マシンとのアドミッション コントロール