Die realen CPUs eines Servers, die für den VM2000-Betrieb zur Verfügung stehen, können unter VM2000 in unterschiedliche, disjunkte CPU-Pools aufgeteilt werden. Mit diesem Konzept kann eine bessere Hardware-Effizienz und CPU-Affinität bei Servern mit vielen CPUs erreicht werden. Eine VM wird genau einem CPU-Pool zugeordnet.
VM2000 versucht die CPU-Leistung der realen CPUs eines CPU-Pools proportional zu den CPU-Quoten auf die einzelnen Gastsysteme, die einem CPU-Pool zugeordnet sind, aufzuteilen. Eine obere Schranke ergibt sich aus der maximalen CPU-Leistungsaufnahme einer VM.
Folgende Eigenschaften von CPU-Pools haben Einfluss auf die Performance des Servers:
CPU-Pools reduzieren den VM2000-Overhead, insbesondere bei einer größeren Anzahl realer CPUs
CPU-Pools erlauben eine gezielte, aber strikt begrenzte Leistung (Service-Level) für eine Menge von VMs ("begrenzte VM-Gruppe") bei zusätzlich reduziertem VM2000-Overhead
CPU-Pools auf /390-Servern ermöglichen es, für kritische Produktivsysteme eine feste CPU-Zuordnung (dedizierte CPUs) herzustellen
Kriterien für die Gestaltung von CPU-Pools sind:
Die Größe der CPU-Pools (die Anzahl der einem CPU-Pool zugeordneten realen CPUs) sollte geplant werden, so dass die zur Verfügung gestellte CPU-Leistung der Summe der geplanten Leistungsanteile für die dem CPU-Pool zugewiesenen VMs entspricht. Wie bei der CPU-Auslastung des ganzen Servers sollte auch die CPU-Auslastung der einzelnen CPU-Pools beim OLTP-Betrieb nicht höher als 75% liegen.
Die Auslastung der realen CPUs des Servers sollte möglichst gleich sein. Dementsprechend sollten die CPU-Pools möglichst gleich ausgelastet sein.
Bei CPU-Pools mit nur einer realen CPU ist zu erwarten, dass die Dehnung der Hardware-Bedienzeit (siehe "Peripherie") höher ist als bei CPU-Pools mit mehreren realen CPUs.
Wenn sich der Leistungsbedarf der Gastsysteme im Laufe der Session ändert, dann können dem CPU-Pool dynamisch mit /SWITCH-VM-CPU neue CPUs hinzugefügt oder CPUs entzogen werden.
Kriterien für die Zuordnung von VMs zu den CPU-Pools sind:
Bei Gastsystemen mit Anwendungen, deren Antwortzeitverhalten stark von der Dauer der Ein-/Ausgaben abhängt, sollten die konkurrierenden VMs bzw. Gastsysteme im gleichen CPU-Pool sorgfältig ausgewählt werden, damit sich die Dehnung der Hardware-Bedienzeit nicht ungünstig auswirkt.
Beispielweise sollte vermieden werden, dass einem CPU-Pool viele CPU-intensive Gastsysteme zugeordnet werden.Bei Gastsystemen mit besonders hoher Anforderung an die Performance kann der CPU-Pool mit so vielen realen CPUs ausgestattet werden, dass für jede aktive virtuelle CPU eine reale CPU zur Verfügung steht. VM2000 arbeitet auf /390-Servern dann beim Scheduling mit einer festen CPU-Zuordnung.
Mit dem Parameter VM-ACTIVE-IDLE=*AT-DEDICATED-CPUS (/390-Server) behält eine VM mit fester CPU-Zuordnung auch dann die Kontrolle über die reale CPU, wenn die darauf ablaufende virtuelle CPU der VM untätig ist (unterbrechbarer Wartezustand, "Idle").
Damit werden auch die Kontextwechsel beim Gastsystem-Wartezustand ("Idle") vermieden. Auf /390-Servern wird damit nahezu eine Performance wie im Native-Betrieb erreicht.Für VMs mit VM-ACTIVE-IDLE ist keine Auswertung der VM-ACTIVE-Zeiten möglich (/SHOW-VM-STATUS oder VM-Report von openSM2).
Bei Bedarf können einzelne VMs oder ganze VM-Gruppen mit /ASSIGN-VM(-GROUP)-TO-CPU-POOL dynamisch anderen CPU-Pools zugeordnet werden.