VMs anlegen und verwalten
Der Haupt-Console-Workflow startet mit einem geplanten Topologie-Node. Provisioning wandelt diesen Node später in eine libvirt-Domain mit gewähltem Build oder enabled catalog image.
Geplanten Node hinzufügen
- Projekt oder Topologie eines abgeschlossenen Builds öffnen.
- VM-Node hinzufügen.
- Sicheren Namen vergeben: 1–63 Zeichen, beginnend mit Buchstabe oder Ziffer, nur Buchstaben, Ziffern, Bindestriche oder Unterstriche.
- Memory, vCPUs und Root-Disk-Größe setzen. Aktuelle Defaults: 4.096 MiB, 2 vCPUs, 20 GiB; Account-Entitlements können niedriger clampen.
- Boot-Variant wählen und eine oder mehrere Topologie-Netzwerke verbinden.
- Graph speichern, dann Node deployen oder starten.
Allein die Karte hinzuzufügen reserviert kein Compute und erzeugt keine VM. Bestätigen,
dass der Node von planned in einen Runtime-Zustand wechselt und eine libvirt-ID hat,
bevor Konsole oder Tests geöffnet werden.
Image-Quellen
Der Boot-Variant-Picker kann abgeschlossene Builds und vom Operator enabled catalog targets zeigen. Das Backend löst Catalog-Targets zu trusted artifact auf statt browser-supplied path als Autorität zu akzeptieren.
Es gibt auch eine lower-level authenticated create-from-iso-API für interne Test- und
Deployment-Workflows. Ihr iso_path ist ein server-side image path, kein allgemeiner
Browser-Upload oder arbitrary remote-URL downloader.
Boot-Variant eines bestehenden Domain wechseln ersetzt das CD-ROM-Image, setzt CD-ROM first und cold-restartet die VM. Die VM-Disk bleibt. Das ist nicht dasselbe wie das gewählte Image auf diese Disk zu installieren.
Lifecycle-Aktionen
| Console-Aktion | Runtime-Verhalten | Risiko |
|---|---|---|
| Start | Startet gestoppte Domain | Gast-Boot kann trotzdem fehlschlagen |
| Shutdown | Fordert ACPI guest shutdown an | Braucht Gast-Kooperation |
| Reboot | Fordert graceful guest reboot an | Braucht Gast-Kooperation |
| Reset | Hard-reset der laufenden Domain | Kann in-flight writes korrupt machen |
| Power off | Erzwingt Domain off | Entspricht Strom ziehen; Datenverlust möglich |
| Delete | Entfernt Domain und managed disk/metadata | Destruktiv; benötigten Nachweis zuerst behalten |
Es gibt keine zuverlässige universelle Boot-Zeit-Schätzung. Runtime-Zustand und Konsole beobachten und Test-Run-Timeouts passend zum gewählten Image wählen.
Install-to-Disk-Abnahme
Für ein Image mit Installer-Claim:
- Mit beschreibbarer Root-Disk provisionieren.
- Von ISO booten und Installer über VNC oder supported automated installer path abschließen.
- CD-ROM ejecten oder depriorisieren.
- Reboot und bestätigen, dass Disk, nicht ISO, aktive Boot-Quelle ist.
- User, Desktop, Pakete, Dienste und Installer-Cleanup verifizieren.
Ein Installer-Icon in Live-Session reicht nicht als Nachweis.
Persistent overlay und Snapshots
Manche Images können Zone-2-Persistence-Disk anbinden. Zone-Controls exponieren Snapshot, Rollback, Export, Import und Reset für dieses governed overlay. Sie snapshotten keinen VM-Memory, kein Base Image und keine unrelated disks. VM muss laufen und in-guest Zone support healthy sein für diese Operationen.
Fehlerbehebung
- Provisioniert geplanter Node nie, Deployment-Fehler und aktuelle Entitlement-Response prüfen vor Retry.
- Konsole verbindet nicht, Domain läuft und hat resolvable runtime ID.
- Graceful action hängt, Gast inspizieren vor reset oder power off.
- Netzwerk scheitert, authored edge, attached libvirt interface, active network, DHCP/static address, route und DNS vergleichen.
- Installer bootet wiederholt, Boot-Order prüfen und ISO ejecten.
Siehe Netzwerk-Topologie und VNC-Konsole.