Initialisieren einer VM

Bevor mit einer VM gearbeitet werden kann, muss sie in VM2000 eingerichtet werden. Diesen ersten Bedienungsschritt bezeichnet man als Initialisieren einer VM. Das Initialisieren einer VM wird mit /CREATE-VM (VM2000-Administrator) durchgeführt. Es setzt voraus, dass noch keine VM oder VM-Definition mit dem angegebenen VM-Namen eingerichtet ist. Der VM-Administrator kann eine VM nicht initialisieren, wohl aber beenden.

Auch mit /ACTIVATE-VM-DEFINITION kann eine VM initialisiert und ggfs. gestartet werden, wenn dafür eine entsprechende persistente VM-Definition existiert. Nähere Informationen zu VM-Definitionen finden Sie im Abschnitt „Arbeiten mit VM-Definitionen".

Beim Initialisieren werden der VM Attribute und Betriebsmittel zugeordnet:

• VM-Index und VM-Name (Identifikation der VM)

• Größe des Hauptspeichers für die VM

• minimale und maximale Größe des Hauptspeichers für die VM bei Hauptspeicher-Rekonfiguration

• Lage der VM im Hauptspeicher von VM2000

• CPU-Quote und maximale CPU-Leistungsaufnahme der VM

• Maximale I/O-Leistungsaufnahme der VM

• Zuordnung der VM zu einer VM-Gruppe

• Zuordnung der VM zu einem CPU-Pool

• Multiprozessorgrad der VM

• Kennwort für den Dialogzugang

• Kommandoumfang für den VM2000-Administrator und VM-Administrator

• Privilegien der VM

• Einstellungen zur Kontrolle über die reale CPU

• Attribut PERSISTENT

Nach erfolgreichem Initialisieren befindet sich die VM im Zustand INIT-ONLY.

Auf SU x86 wird die Firmware-Komponente einer VM bereits beim Initialisieren der VM gestartet. Die VM nimmt deshalb trotz des Zustandes INIT-ONLY bereits minimal CPU-Leistung auf.

Die Monitor-VM wird automatisch initialisiert. Ihre Attribute und Betriebsmittel werden beim Installieren von VM2000 konfiguriert (siehe Kapitel „Installieren von VM2000").

Die maximale Anzahl der VMs, die initialisiert werden können, ist von der Architektur der Server Unit abhängig, siehe "CREATE-VM (VM initialisieren)". Sie wird auch bei /SHOW-VM-RESOURCES INFORMATION=*CONFIGURATION ausgegeben.

Identifikation der VM

Die Identifikation VM-ID bezeichnet die VM in den VM2000-Kommandos. VM-ID kann der VM-Index oder der VM-Name sein. VM-Index und VM-Name werden beim Initialisieren einer VM vergeben. Sie bezeichnen eine VM eindeutig und können nach dem Initialisieren der VM nicht mehr geändert werden.

Der VM-Index ist eine ganze Zahl n von 1 bis 99 (die Obergrenze ist abhängig von der Architektur der Server Unit) und kennzeichnet die VM als VM1 bis VMn. Der VM2000-Administrator kann den VM-Index explizit vorgeben. Wenn kein VM-Index vorgegeben wird (Standard), dann wählt VM2000 den nächsten freien Index. Der VM-Index dient der Verwaltung einer VM innerhalb von VM2000.

Der VM-Name wird vom VM2000-Administrator gewählt (Standard). Er soll den Benutzer oder die Benutzungsart der VM charakterisieren. Er sollte explizit vergeben werden, um die wenig aussagekräftigen Standardnamen zu vermeiden.
Wenn kein VM-Name angegeben wird, dann vergibt VM2000 den Standardnamen VM00nn, wobei nn der VM-Index (nn=01..99) ist. Das Initialisieren der VM wird abgewiesen, falls ein angegebener VM-Name dem Standardnamen einer anderen VM entspricht (z.B. VM-INDEX=5, VM-NAME=VM0002) oder bereits vergeben ist.

Empfehlungen für die Gestaltung und Verwendung von VM-Namen

Der VM-Administrator sollte als VM-Identifikation in Prozeduren den VM-Namen angeben. Der VM-Index sollte in Prozeduren vermieden werden, da er sich in jeder Session ändern kann.

Der VM-Name sollte eindeutig innerhalb einer VM2000-Installation sein.

Der Standardname der Monitor-VM auf SU x86 ist MONITOR. Beim Einrichten einer VM auf SU x86 wird der VM-Name als Domänen-Name übernommen. Die Sonderzeichen #, $ und @ sollten deshalb im VM-Namen nicht verwendet werden; sie werden im Domänen-Namen durch n, s und a ersetzt.

Die Namenskreise für VMs, VM-Gruppen und CPU-Pools sollten disjunkt sein.

Wird eine VM bei Teilnehmerwechsel (ohne Beenden und erneutem Initialisieren der VM) übernommen, kann mit /MODIFY-VM-ATTRIBUTES und Angabe des bisherigen VM-Namens das Erzeugen von Abrechnungssätzen initiiert werden. In diesem Fall werden BS2000-Abrechnungssätze von VM2000 für die betroffene VM und die ihr zugeordneten Geräte geschrieben (siehe "Abrechnung für VM2000").

 

Größe des Hauptspeichers der VM

Dieses Attribut bestimmt die Größe des Hauptspeichers für die VM (siehe Abschnitt „Hauptspeicher verwalten"). Die maximale Hauptspeichergröße unter VM2000 beträgt 1 TByte (Terabyte; 1 TByte = 1024 Gbyte = 1 048 576 MByte).

	Auf SU /390 beginnt ein Hauptspeicherbereich auf einer 1 MByte-Grenze und hat als Größe ein Vielfaches von 1 MByte.
	Auf SU x86 hat ein Hauptspeicherbereich eine Größe in Vielfachen von 2 MByte.  Zusätzlich zum Hauptspeicher für ein BS2000-Gastsystem wird ein kleines Kontingent des Hauptspeichers einer VM für die Firmware-Komponente benötigt. Der Hauptspeicher einer VM auf SU x86 muss deshalb mindestens 1024 MByte groß sein.

 

Minimale Größe des Hauptspeichers der VM

Die minimale Größe des Hauptspeichers sollte für eine VM nur dann festgelegt werden, wenn der Hauptspeicher der VM bei aktivem Gastsystem verkleinert werden soll (siehe "Hauptspeicher rekonfigurieren").

Die minimale Größe des Hauptspeichers kann mit /EXTEND-VM-MEMORY vergrößert und, auf SU /390, mit /REDUCE-VM-MEMORY (implizit) verkleinert werden (siehe "REDUCE-VM-MEMORY (Hauptspeicher einer VM verkleinern)").

Hinweis zur Dimensionierung der minimalen Hauptspeichergröße

Die minimale Größe des Hauptspeichers für eine VM muss so hoch gewählt werden, dass mindestens die residenten Speicheranforderungen im Gastsystem befriedigt werden können. Der Bedarf an residentem Speicher ist abhängig vom Einsatz des Software-Produkts DAB.

Der aktuelle Verbrauch von residentem Speicher kann aus den Werten der Reportgruppe MEMORY von openSM2 ermittelt werden (siehe Handbuch „openSM2“ [9]):
Residenter Speicher = TOTAL - Pageable Frames .

Auf SU x86 beträgt die minimale Größe des Hauptspeichers einer VM mindestens 1024 MByte, siehe oben.

Wird der Hauptspeicher einer VM bis zur minimalen Größe verkleinert, muss die Last des Gastsystems entsprechend reduziert werden.

 

Maximale Größe des Hauptspeichers der VM (SU x86)

Die maximale Größe des Hauptspeichers sollte für eine VM nur dann festgelegt werden, wenn der Hauptspeicher der VM bei aktivem Gastsystem vergrößert werden soll (siehe "Hauptspeicher rekonfigurieren").

Wenn der Hauptspeicher der VM im laufenden Betrieb nicht vergrößert werden soll, dann sollte für die maximale Größe (MAX-MEMORY-SIZE) der gleiche Wert wie für die Hauptspeichergröße der VM (MEMORY-SIZE) gewählt werden.

Standardwert für die maximale Größe des Hauptspeichers ist die doppelte, durch MEMORY-SIZE vorgegebene Größe des Hauptspeichers für die betreffende VM.
Die maximale Größe des Hauptspeichers der VM wird begrenzt durch den zur Verfügung stehenden Hauptspeicher (Ausgabezeile TOTAL REAL MEMORY SIZE bei /SHOW-VM-RESOURCES INFORMATION=*CONFIGURATION).
Eine VM kann (ohne Meldung) eine kleinere maximale Größe des Hauptspeichers als gewünscht erhalten, wenn:

• der gewünschte Wert (explizit angegeben oder implizit durch den Standardwert) größer ist als der zur Verfügung stehende Hauptspeicher

• die minimale Größe der VM zu klein für den impliziten Standardwert (die doppelte Größe des Hauptspeichers der VM) ist

Wenn aber der Wert der maximalen Größe im letzteren Fall explizit angegeben wird, dann wird eine solche Kombination der Speicherwerte abgewiesen (VMS4093).

Auf SU /390 wird die maximale Größe des Hauptspeichers einer VM ignoriert. Eine VM kann immer bis zum Anfang der nächsten VM bzw. bis zum Hauptspeicherende erweitert werden.

 

Lage der VM im Hauptspeicher

	Auf SU /390 bestimmt dieses Attribut die Lage der VM im Hauptspeicher von VM2000 (siehe "Hauptspeicher verwalten und rekonfigurieren"). Die Adresse muss ein Vielfaches von 1 MByte sein. Wird die Lage nicht angegeben, wählt VM2000 einen geeigneten Bereich aus. Die Lage der VM im Hauptspeicher kann nachträglich mit /MOVE-VM verändert werden.
	Auf SU x86 kann die Lage einer VM nicht angegeben werden. Deshalb kann für dieses Attribut nur der Standardwert angegeben werden (*ANY, die Lage der VM im Hauptspeicher wird nicht vorgegeben).

CPU-Quote und maximale CPU-Leistungsaufnahme der VM

Diese Parameter bestimmen die langfristige Verteilung der zur Verfügung stehenden CPU-Leistung auf die VMs.

Auf SU /390 bestimmt die CPU-Quote einer VM, die keiner VM-Gruppe zugeordnet ist, den eigenen Anteil an der CPU-Leistung des CPU-Pools im Vergleich zu den VM-Gruppen und den übrigen VMs, die keiner VM-Gruppe zugeordnet sind. Für eine VM, die einer VM-Gruppe zugeordnet ist, bestimmt die Mitglieds-CPU-Quote den eigenen Anteil an der CPU-Leistung des CPU-Pools im Vergleich zu den VMs der gleichen VM-Gruppe. Der CPU-Anteil einer VM kann durch die maximale CPU-Leistungsaufnahme der VM oder der VM-Gruppe begrenzt werden.

Auf SU x86 bestimmt die CPU-Quote der VM den Anteil der VM an der CPU-Leistung des CPU-Pools im Vergleich zu den übrigen VMs. Der CPU-Anteil einer VM kann durch die maximale CPU-Leistungsaufnahme der VM begrenzt werden.

Weiterführende Informationen finden Sie im Abschnitt „Verteilung der CPU-Leistung auf die VMs planen".

CPU-Quote und maximale CPU-Leistungsaufnahme können mit /MODIFY-VM-ATTRIBUTES geändert werden.

Maximale I/O-Leistungsaufnahme der VM

Die I/O-Leistungsaufnahme einer VM kann durch die maximale I/O-Leistungsaufnahme der VM begrenzt werden.

	Auf SU /390 überwacht das BS2000-Subsystem IORM die maximale I/O-Leistungsaufnahme in der Funktion IOLVM, siehe "Einsatz von IORM im VM2000-Betrieb".
	Auf SU x86 kann für dieses Attribut nur der Standardwert (100, unbegrenzte Leistungsaufnahme) verwendet werden.

Die maximale I/O-Leistungsaufnahme kann mit /MODIFY-VM-ATTRIBUTES geändert werden.

Zuordnen der VM zu einer VM-Gruppe

Eine VM kann als (Einzel-)VM oder als Mitglied einer VM-Gruppe betrieben werden.

	Auf SU /390 kann die VM bereits beim Initialisieren über den Operanden CPU-QUOTA=*BY-VM-GROUP(...) einer VM-Gruppe zugeordnet werden. Sie erhält dabei eine Mitglieds-CPU-Quote.
	Auf SU x86 stehen VM-Gruppen nicht zur Verfügung.

 

Zuordnen der VM zu einem CPU-Pool

Jede VM ist stets genau einem CPU-Pool zugeordnet.

Wenn die VM keiner VM-Gruppe zugeordnet ist, dann kann der CPU-Pool frei gewählt werden. Im Standardfall (Operand CPU-POOL-NAME=*STD) wird die VM beim Initialisieren dem Standard-CPU-Pool zugeordnet. Die Zuordnung der VM zu einem CPU-Pool kann mit /ASSIGN-VM-TO-CPU-POOL geändert werden.

Wenn die VM einer VM-Gruppe zugeordnet wird (SU /390, Operand CPU-QUOTA=*BY-VM-GROUP(...)), dann wird sie automatisch auch dem CPU-Pool der VM-Gruppe zugeordnet (Operand CPU-POOL-NAME=*STD). Die Zuordnung der VM-Gruppe zu einem CPU-Pool kann mit /ASSIGN-VM-GROUP-TO-CPU-POOL geändert werden.

Weitere Informationen zu CPU-Pools finden Sie im Abschnitt „CPU-Pools verwalten".

Multiprozessorgrad der VM

Dieses Attribut legt fest, auf wie vielen CPUs eine VM gleichzeitig ablauffähig sein soll. Folgende Multiprozessorgrade werden von VM2000 (Implementierungsgrenze) unterstützt:

1	(MONO)	ein Prozessor (virtuelle CPU 0)
2	(BI)	zwei Prozessoren (virtuelle CPUs 0 und 1)
3	(TRIPLE)	drei Prozessoren (virtuelle CPUs 0, 1 und 2)
4	(QUADRO)	vier Prozessoren (virtuelle CPUs 0 bis 3)
5	(5-Way)	fünf Prozessoren (virtuelle CPUs 0 bis 4)
6	(6-Way)	sechs Prozessoren (virtuelle CPUs 0 bis 5)
7	(7-Way)	sieben Prozessoren (virtuelle CPUs 0 bis 6)
8	(OCTO)	acht Prozessoren (virtuelle CPUs 0 bis 7)
. . .		. . .
32	(32-Way)	32 Prozessoren (virtuelle CPUs 0 bis 31)

   

  Auf SU /390 ist der maximale Multiprozessorgrad 16.

Der Multiprozessorgrad einer VM muss kleiner oder gleich der Anzahl realer Normal-CPUs sein, die für den VM2000-Betrieb zur Verfügung stehen können.

Ausnahme: siehe Hinweis zum Operanden PROCESSOR=*EXTRA-AND-NORMAL im Abschnitt "Leistungssteigerung mit Extra-CPUs".

Die daraus resultierenden virtuellen CPUs der VMs werden auf den verfügbaren realen CPUs zum Ablauf gebracht, siehe Abschnitt „Scheduling-Verfahren".

Der Multiprozessorgrad einer VM bildet die Obergrenze für die maximale CPU-Leistungsaufnahme der VM, siehe "CPU-Quote und maximale CPU-Leistungsaufnahme der VM". Beispielsweise kann eine Bi-VM maximal die CPU-Leistung von zwei realen CPUs aufnehmen.

Für die Monitor-VM wird der Multiprozessorgrad beim Installieren von VM2000 eingestellt (siehe Kapitel „Installieren von VM2000").

Der Multiprozessorgrad kann nach dem Einrichten einer VM nicht mehr verändert werden.

Kennwort für die Administration und das Operating

Dieses Attribut legt ein Kennwort fest, das sowohl der VM-Administrator (im ADMIN-Dialog) wie auch der Gastsystem-Operator (im VC-Dialog) bei der Dialogeröffnung mit /BEGIN-VM-DIALOG angeben muss. Wird kein Kennwort vergeben, ist die Angabe eines Kennwortes bei /BEGIN-VM-DIALOG nicht nötig. Das Kennwort kann nachträglich mit /MODIFY-VM-ATTRIBUTES geändert werden. Für das Operating über eine BS2000-Konsole gelten andere Schutzmechanismen.

Kommandoumfang für den VM2000-Administrator und VM-Administrator

Dieses Attribut legt den Kommandoumfang für den VM2000-Administrator und VM-Administrator fest. Für den VM2000-Administrator kann der Kommandoumfang eingeschränkt, für den VM-Administrator erweitert werden (siehe "Erweitern und Einschränken des Kommando-/Funktionsumfangs").

Der Kommandoumfang kann nachträglich mit /MODIFY-VM-ATTRIBUTES geändert werden.

Privilegien der VM

Privileg IO-RESET

Die IO-RESET-Operation dient als äußerste Maßnahme zur Behebung von Problemen in der Ein-/Ausgabe-Konfiguration. Dazu muss die VM mit dem Privileg IO-RESET=*YES versehen werden (beim Initialisieren der VM oder mit /MODIFY-VM-ATTRIBUTES).

	Auf SU /390 wird empfohlen, eine VM ohne Privileg, also mit IO-RESET=*NO, einzurichten und nur im Bedarfsfall das Privileg mit /MODIFY-VM-ATTRIBUTES zu vergeben.
	Auf SU x86 kann für dieses Attribut nur der Standardwert (*NO, keine Problembehebung mit IO-RESET) verwendet werden.

Für eine VM mit IO-RESET=*YES führt VM2000 auf SU /390 folgende Maßnahmen durch:

1. Bei /START-VM (bzw. Restart des Gastsystems) wird ein System-Reset analog zu einem Firmware-IPL ausgeführt. Für diese VM werden dann alle Kanäle in der Hardware zurückgesetzt, an denen der VM wenigstens eine Platte in der Benutzungsart EXCL (exklusiv) oder SH(D) (Benutzungsart SHARED, Direct-I/O) zugeordnet ist.

2. Beim Rücksetzen eines Kanals durch das Gastsystem auf der VM (z.B. bei lokaler Kanalrekonfiguration) wird der Kanal in der Hardware zurückgesetzt.

3. Bei /REMOVE-VM-DEVICES mit FORCE=*YES (expliziter Aufruf oder Ausführung während /DELETE-VM) werden bei Bedarf alle Kanäle, an denen das Gerät angeschlossen ist, in der Hardware zurückgesetzt.

Für eine VM mit IO-RESET=*NO wird das Rücksetzen der Kanäle vom VM2000-Hypervisor für die VM emuliert, es führt zu keiner Aktion in der Hardware.

• Auswirkungen auf andere VMs:
  In den obigen drei Fällen werden alle laufenden Ein-/Ausgabe-Aufträge anderer Gastsysteme auf den betroffenen Kanälen abgebrochen. Der weitere Ablauf dieses Gastsystems ist abhängig von der entsprechenden Fehlerbehandlungsroutine im Gastsystem.
• IO-RESET in der Monitor-VM:
  Für die Monitor-VM wird die Maßnahme 2 stets durchgeführt.
  Die Maßnahme 1 wird beim Restart des Monitorsystems durchgeführt, wenn für die Monitor-VM IO-RESET=*YES beim Initialisieren der Monitor-VM oder mit /MODIFY-VM-ATTRIBUTES eingestellt wurde.

Privileg IO-PRIORITY

Unter VM2000 gibt eine VM, die z.B. nach dem Start einer Ein-/Ausgabe in den Wartezustand (IDLE) geht, die reale CPU an eine andere, betriebsbereite VM ab. Die gestartete Ein-/Ausgabe kann, z.B. bei schnellen Cache-Medien, abgeschlossen sein bevor die VM wieder auf einer realen CPU zum Ablauf kommt (so genannte I/O-Dehnung). Die VM wartet, bis sie mit dem Scheduling (siehe "Scheduling-Verfahren") wieder auf einer realen CPU zum Ablauf kommt und kann erst dann das Ergebnis der Ein-/Ausgabe bearbeiten.

Eine VM bzw. ein Gastsystem, das durch diese I/O-Dehnung in unerwünschter Weise verlangsamt wird, kann diesen Effekt mit dem Privileg IO-PRIORITY=*YES verhindern.

Auf SU /390 wird eine VM im Wartezustand mit diesem Privileg unmittelbar nach Ende der anstehenden Ein-/Ausgabe wieder auf einer realen CPU zum Ablauf gebracht. Das Gastsystem kann dann sofort das Ergebnis der Ein-/Ausgabe bearbeiten.

Das Privileg IO-PRIORITY=*YES kann bereits beim Initialisieren der VM oder mit /MODIFY-VM-ATTRIBUTES zugeordnet werden. Es gilt für alle virtuellen CPUs der VM.

	Auf SU /390 wird empfohlen, eine VM ohne Privileg, also mit IO-PRIORITY=*NO, einzurichten und nur im Bedarfsfall das Privileg mit /MODIFY-VM-ATTRIBUTES zu vergeben.
	Auf SU x86 kann für dieses Privileg nur der Standardwert (*NO, keine I/O-Priorisierung) verwendet werden.

Die Summe der virtuellen CPUs aller VMs mit dem Privileg IO-PRIORITY=*YES darf nicht größer sein als die Anzahl der realen Normal-CPUs der Server Unit.

Privileg AUTO-SNAP-ASSIGNMENT

Dieses Privileg erlaubt dem Gastsystem auf einer VM, sich Snap-Units eines Snapset implizit zuzuordnen, ohne dass VM und Gerät mit dem Privileg bzw. Attribut ASSIGN-BY-GUEST versehen sind.

Privileg ASSIGN-BY-GUEST

Dieses Privileg steuert, ob das Operating implizit (z.B. mit /ATTACH-DEVICE) der eigenen VM Geräte bestimmter Assignment Sets zuordnen darf, siehe "Assignment Sets, implizite Gerätezuordnung und -freigabe".

Für die implizite Gerätezuordnung muss die VM mit dem Privileg ASSIGN-BY-GUEST für die gewünschten Assignment Sets versehen werden (beim Initialisieren der VM oder mit /MODIFY-VM-ATTRIBUTES).

Zusätzlich muss jedes Gerät, das implizit zugeordnet werden soll, mit dem Attribut ASSIGN-BY-GUEST ausgestattet sein (siehe "MODIFY-VM-DEVICE-ATTRIBUTES (Attribute von Geräten ändern)"). Dabei wird das Gerät auch dem gewünschten Assignment Set zugeordnet.

Einstellungen zur Kontrolle über die reale CPU

Auf SU /390 bestimmt dieses Attribut, ob eine VM bei fester CPU-Zuordnung (Dedizierte CPUs) auch dann die Kontrolle über eine reale CPU behält, wenn die darauf ablaufende virtuelle CPU der VM untätig ist (unterbrechbarer Wartezustand, „Idle“).

Auf SU x86 kann für dieses Attribut nur der Standardwert (*NO) verwendet werden.

Auf SU /390 entzieht der VM2000-Hypervisor bei VM-ACTIVE-IDLE=*NO die zugeordnete reale CPU, wenn die darauf ablaufende virtuelle CPU der VM untätig ist (unterbrechbarer Wartezustand, „Idle“).

Bei VM-ACTIVE-IDLE=*AT-DEDICATED-CPUS behält die VM die Kontrolle über die zugeordnete reale CPU auch dann, wenn die darauf ablaufende virtuelle CPU der VM untätig ist (unterbrechbarer Wartezustand, „Idle“).

In diesem Fall wird ein Performance-Gewinn erreicht, weil ein Kontextwechsel nicht stattfindet. Diese Idle-Zeit wird dann aber in den Abrechnungssätzen von VM2000, bei /SHOW-VM-STATUS (Ausgabespalte VM-ACTIVE) und im VM2000-Report von openSM2 als Zeit, in der die VM die reale CPU aktiv nutzt, ausgewiesen.

Diese Einstellung bringt keinen Performance-Gewinn, wenn viele Ein-/Ausgaben für gemeinsam genutzte Platten oder bei virtuellen Konsolen zu erwarten sind.

VM-ACTIVE-IDLE=*AT-DEDICATED-CPUS wirkt bei fester CPU-Zuordnung nur dann, wenn die maximale CPU-Leistungsaufnahme der VM (siehe "CPU-Quote und maximale CPU-Leistungsaufnahme der VM") nicht begrenzt ist.

Die Einstellung kann auch nachträglich mit /MODIFY-VM-ATTRIBUTES geändert werden.

Attribut PERSISTENT

Das Attribut PERSISTENT legt fest, ob eine persistente VM eingerichtet wird (PERSISTENT=*YES). Eine persistente VM erhält eine persistente VM-Definition.

Für die Monitor-VM kann das Attribut PERSISTENT nicht gesetzt werden.

Eine persistente VM-Definition steht auch nach einem Neustart einer Server Unit zur Verfügung. Mit ihrer Hilfe wird eine persistente VM wieder eingerichtet und bei entsprechender Angabe im Parameter AUTO-IPL sofort wieder gestartet. Eine persistente VM-Definition wird bei /DELETE-VM nicht gelöscht.

Eine VM ohne das Attribut PERSISTENT erhält eine nicht-persistente VM-Definition. Diese wird bei /DELETE-VM gelöscht.

Nähere Informationen zu VM-Definitionen finden Sie im Abschnitt „Arbeiten mit VM-Definitionen".