この例では、拡張可能な予約を持つリソース プールの機能を示します。
図に示すように、次のシナリオを想定しています。
- 親プールの 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. 拡張可能なリソース プールを使用したアドミッション コントロール：正常にパワーオンされなかった場合
