Skip to main content

Exit Nutanix · the whole picture

Many projects. One exit.

Transiva takes the VM out of Nutanix. h2kvm makes it boot. KVM, KubeVirt, Kairon or Machina run it. Chimera lets us test all of it without a real cluster.

The h2kvm sideTransiva quick start

Abridged. The recorded numbers are further down this page.

System map

Follow the disk.

A VM leaves Nutanix as a plain qcow2 plus a manifest. Everything after that is standard Linux virtualization.

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.

Read the case studyThe h2kvm side