Creare e gestire VM
Il flusso console principale inizia con un nodo topologia pianificato. Il provisioning trasforma poi quel nodo in un dominio libvirt usando la build selezionata o immagine catalogo abilitata.
Aggiungi un nodo pianificato
- Apri topologia di un progetto o di una build completata.
- Aggiungi un nodo VM.
- Assegna un nome sicuro: 1–63 caratteri, che inizi con lettera o cifra e contenga solo lettere, cifre, trattini o underscore.
- Imposta memoria, vCPU e dimensione disco root. I default attuali sono 4.096 MiB, 2 vCPU e 20 GiB; gli entitlement account possono limitarli più in basso.
- Scegli una variante boot e collega una o più reti topologia.
- Salva il grafo, poi deploya o avvia il nodo.
Aggiungere la sola scheda non riserva compute né crea una VM. Conferma che il nodo
passi da planned a uno stato runtime e abbia un identificatore libvirt prima di
aprire console o eseguire test.
Sorgenti immagine
Il picker variante boot può esporre le tue build completate e target catalogo pubblico abilitati dall’operatore. Il backend risolve target catalogo al loro artefatto fidato invece di accettare un path fornito dal browser come autorità.
Esiste anche un’API autenticata create-from-iso di livello inferiore per flussi
test e deploy interni. Il suo iso_path è un path immagine lato server, non un
upload browser generico o downloader URL remoto arbitrario.
Cambiare la variante boot di un dominio esistente sostituisce l’immagine CD-ROM, imposta CD-ROM first e cold-restart la VM. Il disco della VM è conservato. Non è la stessa cosa che installare l’immagine selezionata su quel disco.
Azioni lifecycle
| Azione console | Comportamento runtime | Rischio |
|---|---|---|
| Start | Avvia un dominio fermato | Il boot guest può comunque fallire |
| Shutdown | Richiede shutdown guest ACPI | Richiede cooperazione guest |
| Reboot | Richiede reboot guest graceful | Richiede cooperazione guest |
| Reset | Hard-reset del dominio in esecuzione | Può corrompere scritture in corso |
| Power off | Forza spento dominio | Equivalente a staccare alimentazione; possibile perdita dati |
| Delete | Rimuove dominio e disco/metadati gestiti | Distruttivo; conserva evidenza necessaria prima |
Non esiste una stima boot-time universale affidabile. Osserva stato runtime e console, e usa timeout run test dimensionati per l’immagine selezionata.
Accettazione install-to-disk
Per un’immagine che dichiara un installer:
- Provisiona con disco root scrivibile.
- Avvia dall’ISO e completa l’installer tramite VNC o percorso installer automatizzato supportato.
- Espelli o depriorizza il CD-ROM.
- Reboot e conferma che il disco, non l’ISO, sia la sorgente boot attiva.
- Verifica utenti, desktop, pacchetti, servizi e cleanup installer.
Un’icona installer che appare in sessione live non è evidenza sufficiente.
Overlay persistente e snapshot
Alcune immagini possono allegare un disco persistenza Zone 2. I controlli Zone espongono snapshot, rollback, export, import e reset per quell’overlay governato. Non fanno snapshot memoria VM, immagine base o dischi non correlati. La VM deve essere in esecuzione e il supporto Zone in-guest deve essere sano per queste operazioni.
Risoluzione problemi
- Se un nodo pianificato non si provisiona mai, ispeziona errore deploy e risposta entitlement corrente prima di riprovare.
- Se la console non si connette, conferma che il dominio sia in esecuzione e abbia un ID runtime risolvibile.
- Se un’azione graceful resta in stallo, ispeziona il guest prima di usare reset o power off.
- Se la rete fallisce, confronta edge scritto, interfaccia libvirt allegata, rete attiva, indirizzo DHCP/statico, route e configurazione DNS.
- Se un installer boota ripetutamente, controlla ordine boot ed espelli l’ISO.
Vedi Topologia di rete e Console VNC.