Creating and Managing VMs
The main console workflow starts with a planned topology node. Provisioning later turns that node into a libvirt domain using the selected build or enabled catalog image.
Add a planned node
- Open a project or a completed build’s topology.
- Add a VM node.
- Give it a safe name: 1–63 characters, beginning with a letter or digit and containing only letters, digits, hyphens, or underscores.
- Set memory, vCPUs, and root-disk size. The current defaults are 4,096 MiB, 2 vCPUs, and 20 GiB; account entitlements can clamp them lower.
- Choose a boot variant and connect one or more topology networks.
- Save the graph, then deploy or start the node.
Adding the card alone does not reserve compute or create a VM. Confirm the node
changes from planned to a runtime state and has a libvirt identifier before
opening a console or running tests.
Image sources
The boot-variant picker can expose your completed builds and public catalog targets enabled by the operator. The backend resolves catalog targets to their trusted artifact rather than accepting a browser-supplied path as authority.
There is also a lower-level authenticated create-from-iso API for internal
test and deployment workflows. Its iso_path is a server-side image path, not
a general browser upload or arbitrary remote-URL downloader.
Changing the boot variant of an existing domain replaces the CD-ROM image, sets CD-ROM first, and cold-restarts the VM. The VM’s disk is retained. This is not the same as installing the selected image onto that disk.
Lifecycle actions
| Console action | Runtime behavior | Risk |
|---|---|---|
| Start | Starts a stopped domain | Guest boot can still fail |
| Shutdown | Requests an ACPI guest shutdown | Requires guest cooperation |
| Reboot | Requests a graceful guest reboot | Requires guest cooperation |
| Reset | Hard-resets the running domain | Can corrupt in-flight writes |
| Power off | Forces the domain off | Equivalent to pulling power; data loss is possible |
| Delete | Removes the domain and its managed disk/metadata | Destructive; retain needed evidence first |
There is no reliable universal boot-time estimate. Watch the runtime state and console, and use test-run timeouts sized for the selected image.
Install-to-disk acceptance
For an image claiming an installer:
- Provision with a writable root disk.
- Boot from the ISO and complete the installer through VNC or the supported automated installer path.
- Eject or deprioritize the CD-ROM.
- Reboot and confirm the disk, not the ISO, is the active boot source.
- Verify users, desktop, packages, services, and installer cleanup.
An installer icon appearing in a live session is not sufficient evidence.
Persistent overlay and snapshots
Some images can attach a Zone 2 persistence disk. The Zone controls expose snapshot, rollback, export, import, and reset operations for that governed overlay. They do not snapshot VM memory, the base image, or unrelated disks. The VM must be running and the in-guest Zone support must be healthy for these operations.
Troubleshooting
- If a planned node never provisions, inspect the deployment error and current entitlement response before retrying.
- If the console cannot connect, confirm the domain is running and has a resolvable runtime ID.
- If a graceful action stalls, inspect the guest before using reset or power off.
- If networking fails, compare the authored edge, attached libvirt interface, active network, DHCP/static address, route, and DNS configuration.
- If an installer repeatedly boots, check boot order and eject the ISO.
See Network topology and VNC console.