Choose a zone virtualization backend (PV or PVH)

3 min read · Intermediate

Platform Engineer Developer

Every Edera zone boots with a virtualization backend that determines how the zone’s kernel runs on the hypervisor. You can leave this to Edera, or pin it per workload with a single pod annotation.

Backends

BackendHardware requirementWhen it applies
auto (default)NoneFollows dom0: the zone boots PVH when the host supports it, otherwise PV.
pvNonePure paravirtualization. Works on any instance, including cloud VMs without hardware virtualization.
pvhVT-x / AMD-VParavirtualization inside a hardware-virtualized container. Better performance where hardware virtualization is available.

When you do not specify a backend, the zone uses auto. The auto heuristic mirrors dom0: on a host where dom0 booted in PVH, zones resolve to PVH; on a host running dom0 in PV, zones resolve to PV. This is why the same manifest can come up PVH on a bare-metal node and PV on a standard cloud VM—without any change to your pod.

ℹ️
PVH is currently required for GPU workloads. See GPU support.

Set the backend on a pod

Add the dev.edera/virt-backend annotation to the pod. Valid values are auto, pv, and pvh.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  annotations:
    dev.edera/virt-backend: pvh
spec:
  runtimeClassName: edera
  containers:
    - name: my-app
      image: my-app:latest

For standalone zones launched without Kubernetes, use the equivalent flag:

protect zone launch -V pvh

Verify the backend a zone booted with

The backend you request is not always the backend a zone runs as—auto resolves at boot. To confirm what a zone actually booted with, read the Xen guest type from inside the zone:

kubectl exec my-app -- cat /sys/hypervisor/guest_type

The value is the authoritative answer: PV, PVH, or HVM.

ℹ️
Early in a PVH zone’s boot log, dmesg reports Hypervisor detected: Xen HVM. This is expected—PVH boots inside a hardware-virtualized container—and does not mean the zone is running in HVM mode. Trust /sys/hypervisor/guest_type.

Hardware requirements and failure behavior

pv runs anywhere. pvh requires hardware virtualization extensions (VT-x or AMD-V). On most clouds those extensions are only exposed on bare-metal instances; for example, on AWS use a .metal instance type for PVH.

Requesting pvh on a host without hardware virtualization does not fall back to PV. The zone fails to start, and on the Kubernetes path the pod remains in ContainerCreating while the sandbox is repeatedly retried. For configurations that must run on mixed hardware, prefer auto (or omit the annotation) so each node selects the backend it can support. Reserve explicit pvh for workloads you know will land on hardware-virtualization-capable nodes, such as GPU nodes.

Related

Last updated on