Kyvernon

Concepts For: administrators

Migration overview

Which methods move a virtual machine from vSphere to Kyvernon today, what the import carries over and what it leaves to you.

A virtual machine moves from vSphere to Kyvernon as an exported package or as a disk file. The console reads the package in the browser, converts the disks to qcow2 while they arrive at the controller and creates the virtual machine. It does not copy a running machine, and it does not change anything inside the guest.

Import and export page (Show larger)
Import and export pageClose the larger view

Methods

MethodSourceState
OVA or OVF packageA virtual machine that was exported from vSphereAvailable in the console, the CLI and the API
VMDK diskThe disk files of a package, as streamOptimized, monolithic sparse or flat filesAvailable, as part of a package
Import from a running vCenter or ESXi hostThe source host, with streaming disk reads Planned
Migration assistantAssessment, planning in waves, cut-over and rollback Planned

Both available methods use the same function: an import lease. The controller reads the descriptor, makes a plan from it, creates the virtual machine and gives the import one file slot per disk. The console wizard on the page Import and export does the steps for you: you choose the package, the destination and the networks, and it sends the disks with progress. The CLI (kyvernon ovf import-vapp and kyvernon nfc), the native API and the vSphere tools that import through the vSphere API run the same function. See Import an OVA or OVF package.

What the import carries over

  • The number of vCPUs, the cores per socket and the memory.
  • Every disk with its capacity. The disks are thin qcow2 images on the datastore you choose; zero blocks are not stored.
  • Network adapters with their model and, when the package states one, their MAC address. An adapter is created only for a network that you connect to a network of Kyvernon.
  • The extra configuration of the package is stored with the virtual machine. The keys that start with guestinfo. are the ones cloud-init reads in the guest.
  • CD-ROM drives, created disconnected, with the ISO file of the package when it has one.
  • The name, the annotation and the guest operating system identifier. The name can be overridden.
  • The firmware, BIOS or UEFI, as the package states it, and Secure Boot when the package turns it on for UEFI. A guest installed with BIOS on an MBR disk keeps BIOS and boots as it did on the source.

What it changes or leaves out

  • Firmware. A package that states no firmware gets UEFI, and the plan says so in a warning. A package that asks for Secure Boot together with BIOS gets BIOS without Secure Boot, also with a warning.
  • Devices. Disks appear in the guest as virtio block devices and network adapters as virtio network adapters, whatever the source controller or adapter model was. The models vmxnet3, e1000e and e1000 are accepted and presented as virtio. Floppy drives are dropped with a warning. USB and PCI passthrough are not supported.
  • Snapshots. A disk that depends on a parent disk, for example after a snapshot, is refused: consolidate the snapshots at the source first. Raw device mappings are refused too.
  • Guest drivers and tools. Kyvernon does not install drivers in the guest and does not remove the tools of the source platform. See Prepare guests.
  • Disk size. A virtual disk can be at most 64 TiB.

Verification of a package

The disks of a package are read as they arrive. Verify the checksums in the manifest file (.mf) of the package yourself before the upload when the package has one, for example with sha256sum or sha1sum. The console does not read the manifest, and the certificate file (.cert) of a signed package is not verified by Kyvernon.

Version 0.1. Last changed: 2026-11-14