Skip to main content

Exit Nutanix · the h2kvm side

Exported. Now make it boot.

Transiva gets the disk out of Nutanix. h2kvm repairs it offline, converts it and lands it, so the VM runs on plain KVM or KubeVirt.

Abridged. The recorded numbers are further down this page.

Where h2kvm sits

The middle of the exit.

A VM leaves Nutanix as a qcow2 plus a manifest. h2kvm makes that disk bootable and puts it where it will run.

How Transiva, h2kvm and the landing targets fit togetherNutanix Prism v4 is exported by Transiva into a qcow2 and manifest, h2kvm repairs and converts it, and it lands on KVM, KubeVirt with Zorvia (both run), or Kairon and Machina (not run yet). Chimera is a test stand-in for Nutanix.SOURCEChimeratest double (simulator)Prism v4 + NFSNutanixPrism Central v4storage container(NFS)stands in forEXPORTTransivadiscover and exporthyperexportdaemon + REST APIweb dashboardqemu-img convertv4ARTIFACTArtifactdisk.qcow2manifest.jsonREPAIR AND CONVERTh2kvmfirst-boot scienceGuestKit repairconvert + checksumdomain XMLWindows: not runLANDLinux KVMlibvirt: boots, answers pingKubeVirt + ZorviaReady, Zorvia lists itKaironvia Veyron: not run yetMachinalibvirt host: not run yetrun end to endnot run yet, or a test stand-inChimera stands in for a real Prism in tests.

Four stages

What each stage did.

1 · Export

Transiva pulls the disk out of Nutanix over Prism v4 and writes a qcow2 plus artifact-manifest.json.

2 · Repair

GuestKit inspects the guest offline and fixes what stops it booting on KVM. If a guest has no network configuration at all, h2kvm installs a DHCP fallback.

3 · Convert

Flatten, convert to qcow2 and checksum, with a JSON report.

4 · Land

Emit a libvirt domain, or hand off to Kairon through Veyron. KVM and KubeVirt were booted; Kairon and Machina were not run.

Order of calls

Who calls whom.

Order of calls in a Nutanix exitThe script runs hyperexport, which negotiates the Prism v4 version, lists the VM, reads the disk from the NFS container and converts it to qcow2 with a manifest. The script then runs h2kvm and boots the result.ScripthyperexportPrism v4NFS containerh2kvmKVM / KubeVirtrun, -provider nutanix -vm <name>OPTIONS /unversioned/info (negotiate v4.3)GET vms, then GET vm: disks and containerread .acropolis/vmdisk/<disk>/qemu-img convert, write manifestrun, --cmd local --vmdk <disk> --emit-domain-xmlinspect, repair, convert, checksumno network config: install DHCP fallbackboot the converted diskguest gets a lease, answers pingReal run (Ubuntu 24.04): 7 of 7 stages, 747 s. The Prism endpoint was a simulator.

The run

Measured, not promised.

Image: Ubuntu 24.04 cloud image. One unattended run; see results.json for the raw stages.

7 / 7

stages passed

unattended

747 s

end to end

download to running guests

2 / 2

targets booted

KVM (UEFI) and KubeVirt

Export16 s
Convert (h2kvm)277 s
Boot on KVM79 s
Boot on KubeVirt335 s

Straight talk

What it does and doesn't prove.

What ran verified

  • Export, convert and boot, unattended, in one script
  • Ubuntu 24.04 boots on libvirt/KVM (UEFI) and on KubeVirt, guest answers ping
  • A guest with no network config comes up through the DHCP fallback
  • Prism endpoint was Chimera, a simulator, not a real cluster

What did not run

  • A real Nutanix cluster
  • Windows, multi-disk and large VMs
  • Boot repair on a guest that needs it (the Ubuntu image needed only the network fallback)
  • Kairon and Machina landings
  • Checks inside the guest beyond ping

Try it on your own host.

One script, no clicks.