Migration
Migration from vSphere
Kyvernon imports virtual machines exported from vSphere as OVA or OVF packages, without the VDDK. CPU, memory, disks, network adapters with their MAC addresses and the guest configuration come along.
Import methods
| Method | Source | Availability |
|---|---|---|
| OVA and OVF import | Exported appliances and virtual machines | Available |
| VMDK disk upload | The disk files of a package: streamOptimized, monolithic sparse or flat | Available |
| Import from a running source host | vCenter or ESXi API with streaming disk read | Planned |
| Migration assistant | Assessment, wave planning, cut-over and rollback | Enterprise release, planned |
Both available methods work through an import lease, from the console API, the CLI or vSphere tools that import through the vSphere API. Disks are converted to thin qcow2 images while they arrive.
Carried over
- vCPUs, cores per socket and memory
- Every disk with its capacity, in the order of the package
- Network adapters and their MAC addresses, on the networks you map
- The extra configuration of the package, including the
guestinfo.keys that cloud-init reads - Name, annotation and guest operating system identifier
- Firmware as stated in the package: BIOS or UEFI, with Secure Boot for UEFI
The guest itself is not changed: its IP configuration, applications and data stay as they were.
Changed on import
- Disks are presented as virtio block devices and network adapters as virtio adapters
- A package without a firmware statement gets UEFI
- The virtual machine gets a new instance UUID
- Snapshots must be consolidated at the source before export
Guest preparation
Install virtio drivers in the guest before export, and remove the tools of the source platform afterwards. The documentation has a checklist per operating system.
Migration assistant Planned
| Stage | Function |
|---|---|
| Assessment | Inventory of virtual machines, networks, storage, snapshots, guest operating systems and connected tools |
| Mapping | Source clusters, networks and datastores to Kyvernon clusters, segments and storage pools |
| Wave planning | Grouping by application, dependency and maintenance window, with a dry run per wave |
| Transfer | Disk copy while the source runs, final synchronisation of changed blocks at cut-over |
| Verification and rollback | Checks on guest agent, network and registered services, with rollback to the source within a set window |
All migration steps are recorded as tasks and events.
Compatibility of existing tooling
After migration, Terraform state, Ansible inventories, PowerCLI scripts, monitoring templates and backup jobs connect to Kyvernon through the vSphere-compatible endpoints. See compatibility.