VM-image zones – Edera
VM-image zones
TL;DR
A VM-image zone boots an unmodified raw or qcow2 virtual machine disk image directly as an Edera zone, alongside Edera’s OCI-based zones. It runs on the KVM backend and keeps the same zone isolation guarantees—without requiring the image to be repackaged as a container.
Why VM-image zones
Edera zones are normally built from OCI images: Edera supplies the kernel and initrd and composes the root filesystem from container layers. That model doesn’t fit workloads distributed as whole virtual machines—GPU vendor fleet images, vendor-supplied appliances, or any system that expects to own its bootloader and kernel. Repackaging those into containers is often infeasible.
VM-image zones remove that barrier. You hand Edera a disk image, and it boots as-is inside a zone.
How a VM-image zone boots
An OCI zone and a VM-image zone diverge at boot:
- An OCI zone boots the Edera-supplied kernel and initrd, then pivots into a root filesystem composed from OCI layers.
- A VM-image zone carries no Edera kernel or initrd. Edera boots it through a UEFI firmware payload—shipped with Edera—under Cloud Hypervisor on the KVM backend. The firmware runs the image’s own bootloader, which loads the kernel packaged in the image, exactly as it would on any UEFI virtual machine.
Because the image supplies its own kernel and root filesystem, the container-payload options (--kernel, --initrd, addons, scratch disks) don’t apply and are rejected for VM-image zones.
Provisioning and lifecycle
To bring a VM-image zone under the same control plane as an OCI zone, Edera attaches a read-only cloud-init seed to the VM. When the guest’s cloud-init runs, it applies the seed, which installs and starts Edera’s in-zone agent. Once the agent connects, the zone reports ready and supports the same operations as any zone: protect zone exec, protect zone logs, and metrics.
This is why a VM-image zone needs a cloud-init-enabled image. Without cloud-init the VM still boots, but Edera can’t provision the agent, so the zone won’t reach ready.
Each image file backs a single running zone at a time. Edera takes a lock on the raw or qcow2 file at launch and releases it when the zone is destroyed, which prevents two zones from corrupting a shared writable disk.
What stays the same
A VM-image zone is still an Edera zone. The isolation guarantees are identical to OCI-based zones:
| Guarantee | OCI zone | VM-image zone |
|---|---|---|
| Dedicated kernel per zone | Yes | Yes (from the image) |
| Isolated memory and address spaces | Yes | Yes |
| Independent device namespaces | Yes | Yes |
| Independent zone lifecycle | Yes | Yes |
protect CLI compatibility |
Yes | Yes |
| Agent-based exec, logs, and metrics | Yes | Yes (via cloud-init) |
VM-image zones and OCI zones coexist on the same host.
Constraints
- KVM backend. VM-image zones run only on the KVM backend, which is itself Early Access. They are not available on Xen.
- Explicit disk format. The format (raw or qcow2) is always specified explicitly; Edera does not detect it automatically.
- One zone per image file. A raw or qcow2 file can back only one live zone at a time.