In diesem Beispiel wird dargestellt, wie ein Ressourcenpool mit erweiterbaren Reservierungen funktioniert.
Stellen Sie sich das folgende Szenario vor, wie in der Abbildung dargestellt.
- Der übergeordnete Pool RP-MAMA verfügt über eine Reservierung von of 6 GHz und eine ausgeführte virtuelle Maschine VM-M1 mit einer Reservierung von 1 GHz.
- Sie erstellen einen untergeordneten Ressourcenpool RP-KIND mit einer Reservierung von 2 GHz und der festgelegten Option Erweiterbare Reservierung (Expandable Reservation).
- Sie fügen zwei virtuelle Maschinen, nämlich VM-K1 und VM-K2, mit einer Reservierung von je 2 GHz zum untergeordneten Ressourcenpool hinzu und versuchen, sie einzuschalten.
- VM-K1 kann direkt von RP-KIND (mit 2 GHz) Ressourcen reservieren.
- Für VM-K2 sind lokal keine Ressourcen verfügbar, weshalb diese virtuelle Maschine Ressourcen des übergeordneten Ressourcenpools RP-MAMA entleiht. RP-MAMA verfügt über 6 GHz minus 1 GHz (reserviert durch die virtuelle Maschine), minus 2 GHz (reserviert durch RP-KIND), sodass nicht reservierte Ressourcen von 3 GHz übrig bleiben. Mit den verfügbaren 3 GHz kann die virtuelle 2 GHz-Maschine eingeschaltet werden.
Abbildung 1. Zugangssteuerung bei erweiterbaren Ressourcenpools: Einschalten erfolgreich
Betrachten wir nun ein anderes Szenario mit VM-M1 und VM-M2.
- Sie schalten in RP-MAMA zwei virtuelle Maschinen mit einer Gesamtreservierung von 3 GHz ein.
- Sie können auch VM-K1 in RP-KIND einschalten, da lokal 2 GHz verfügbar sind.
- Wenn Sie versuchen, VM-K2 einzuschalten, weist RP-KIND keine nicht reservierte CPU-Kapazität auf und muss den übergeordneten Ressourcenpool prüfen. RP-MAMA weist lediglich 1 GHz nicht reservierte Kapazität auf (5 GHz von RP-MAMA sind bereits in Verwendung: 3 GHz werden durch die lokalen virtuellen Maschinen reserviert, 2 GHz werden von RP-KIND reserviert). Als Ergebnis kann VM-K2 nicht eingeschaltet werden, da eine Reservierung von 2 GHz nicht möglich ist.
Abbildung 2. Zugangssteuerung bei erweiterbaren Ressourcenpools: Einschalten verhindert
