Migrate VMs from vSphere

By the end of this page, VMs that ran in your vCenter run as KubeVirt VMs in a project on a supervisor, and you have checked that they arrived. Celum drives Forklift for the move: Forklift copies each VM’s disks, and virt-v2v converts the guest to run on KVM unless you ask for the disks as they are. Only vSphere is a source in this release, and only through a vCenter. Celum declares every source to Forklift as a vCenter (sdkEndpoint: vcenter), so a standalone ESXi host cannot be a source, and Celum refuses an ESXi host’s address (see Step 3). oVirt, OpenStack, Hyper-V and OVA appear in the form as “Not in this release”.

​

What this changes

On the supervisor. Turning migration on installs Forklift (konveyor-forklift/virt-forklift), the NetworkAttachmentDefinition CRD if it is missing, four admission policies, and one Cilium policy (celum-forklift-v2v) that lets Forklift reach its conversion pods inside isolated projects. The admission policies act only in namespaces labelled k8s-gate/migration-target; creating a plan sets that label on the plan’s project namespace. Talos nodes need no change: the conversion does not need user namespaces. In the project. The migrated VMs and their disks, as ordinary Celum VMs of that project. In vCenter. Celum reads the inventory. When a plan runs, each source VM is shut down — a cold plan at its start, a warm plan at cutover — and stays off in vCenter. A warm plan also takes snapshots of the source VM while it copies.

​

Before you start

• An onboarded supervisor with KubeVirt, CDI, cert-manager and Flux, and a Kubernetes version that serves admissionregistration.k8s.io/v1 MutatingAdmissionPolicy (GA in 1.36). If any of these is missing, turning migration on is refused with 409, and the card links to the onboarding step that installs it.
• The Secret Store onboarding step, if you register the vCenter for the platform (step 2). The credential lives in the secret store and reaches the supervisor through External Secrets.
• The cluster agent chart 1.30.462 or later on the supervisor. The plan wizard reads the vCenter inventory through it; with an older agent it cannot list VMs.
• A registry. Forklift’s images (about 5.6 GB) are copied into the supervisor’s registry when migration is turned on.
• A VDDK image, vddk:<version>, in the supervisor’s registry, for warm migration, for copying disks as they are, and for the fastest copy. VDDK is VMware’s Virtual Disk Development Kit, licensed by Broadcom, which you load into the registry yourself. A Celum appliance installed from a 1.314 OVA or later carries OpenVDDK, an independent Apache-2.0 drop-in for it, as vddk:0.7.4, and new sources take it by default. Updating an older appliance in place does not add it. Without a VDDK, a source can still use virt-v2v over HTTPS (step 3).
• vCenter reachable over HTTPS (/sdk) from the supervisor. For a warm migration, Changed Block Tracking (CBT) enabled on the VMs. To keep a VM’s address, VMware Tools running in the guest, so vCenter reports the address.
• Permissions, listed under Permissions.

​

The shape of it

Turn migration on → register the vCenter → add a source → build a plan → run it → verify. The first three are done once per supervisor; a plan is one wave of VMs.

​

Step 1 — Turn VM migration on for the supervisor

Result: the Forklift tile reads 6/6, “components up · destination ready”, and the VM migration on this supervisor card lists every component ready.

​

Step 2 — Register the vCenter for the platform

Register a vCenter once, and every supervisor’s sources (and Cluster API) can use it. Celum pins its certificate, tests the login, and keeps the user and password only in the secret store. Registering a vCenter, or rotating its password, refuses an ESXi host’s address with the same message as a source does (see Step 3). You can skip this step and type a vCenter’s address and credentials straight into a source. Registering it keeps one copy of the credential, which every source then reads.

​

Step 3 — Add a source

A source is the vCenter that VMs are migrated from, as Forklift sees it. Celum tests the login before it saves the source, and it refuses three sources that would only fail later, during a run:

• An ESXi host. Celum asks the address what it is before it sends the password, and refuses an ESXi host with “<host> is an ESXi host, not a vCenter — give the address of the vCenter that manages it”. It makes this check also when Skip TLS verification is on.
• No CA and no insecureSkipVerify. TLS is verified, so the source needs the CA the vCenter’s certificate chains to.
• No VDDK and TLS still verified. Without VDDK, virt-v2v copies the disks with curl, which ignores the CA, and the run would fail at conversion with curl error 60. Use a VDDK image, or accept insecureSkipVerify.

Result: the source’s row shows TLS verified and state ready. New plan stays disabled until at least one source is ready.

​

Step 4 — Build a plan

A plan names the VMs to move, the source, the project they land in, and how their networks, addresses and disks map. It holds at most 500 VMs. Source & target. The source, the Target project, a Plan name (a DNS label of at most 55 characters, such as erp-wave-3), and an optional description. The project’s namespace is where the VMs land; they become that project’s VMs. VMs. The source’s VMs, with their power state, OS, size and Concerns. vSphere Cluster Services (vCLS) agent VMs are not listed. The wizard will not go on with a VM whose name or MAC address is already in use on the supervisor, a VM with a critical concern, or a VM with more than one NIC on the pod network; in a warm plan, also a VM without CBT or with shared disks. vSAN needs VDDK. Networks. Each vCenter network the chosen VMs use goes to the Pod network or is ignored; a NIC on an ignored network is dropped. The pod network is masquerade, as for every Celum VM: the guest takes its address by DHCP. Mapping a network to a VLAN of its own is not offered yet. Addresses. A VM can keep the address VMware Tools reports for it, inside a subnet declared adoptable: it becomes the VM’s identity address, a routed /32 that follows it through live migration. The address is claimed only once that VM’s migration has succeeded. The other VMs get the pod address only, or an address from the project’s pool. Keeping addresses needs cilium:Apply, a NIC on the pod network, and cannot be combined with Preserve static IPs. Hosts still on the source subnet reach a kept address only once that subnet is extended (see Reach moved VMs from the source network), or once its gateway answers ARP for it. Storage. Each datastore maps to a StorageClass. A VM keeps live migration between the supervisor’s nodes only on a class whose volumes are ReadWriteMany. Migration type. Review. The plan as it will be created, and what it does to the source: each VM is shut down in vCenter before its disks are copied and stays off there. Create plan creates it; Create and start also starts it as soon as Forklift has validated it (with VDDK that includes a check job, which can take a minute). Neither asks again.

​

Step 5 — Run it

The plan’s page follows each VM through Forklift’s steps — Initialize, DiskTransfer, Cutover, ImageConversion, VirtualMachineCreation — with when each started and how long it took. A warm VM lists its precopies; a converted VM lists virt-v2v’s own phases. The page refreshes every 5 seconds while a run is going. A plan is validating, needs attention, ready, running, succeeded, failed, canceled or archived. Mappings shows where each network and datastore went, and each VM’s identity address with its state.

​

Reach moved VMs from the source network

A VM that kept its address has left its source subnet. Hosts that stay behind in that subnet reach it again only when the subnet is extended: an ARP-proxy appliance, a small VM on the source VLAN, answers for exactly the addresses that moved and hands their traffic to the subnet’s own gateway, which routes each one to the supervisor. Nothing on the fabric changes. It bridges a migration in progress: move the whole subnet as soon as you can, retire the source environment, then remove the hybrid subnet.

​

Verify

• The plan reads succeeded, and VMs migrated counts every VM of the latest run.
• Each VM is in Workloads, in the plan’s project, running (unless you chose Off).
• A converted VM shows its guest agent connected. A copied-as-is VM has no guest agent, by design.
• A VM that kept its address shows it on Mappings as done, and answers on it. From a host left in the source subnet, it answers only once that subnet is extended.

​

If you need to undo it

There is no reverse migration. The source VM is still in vCenter, powered off: power it back on there to return to it.

• Cancel the run powers back on the VMs Forklift shut down, removes a warm plan’s snapshot, and removes what the run had built on the supervisor.
• Retry runs again only the VMs that did not get across. A plan that succeeded cannot be run again.
• Archive cleans up what failed and canceled VMs left behind.
• Delete removes the plan. It never touches the VMs that migrated.
• Disable on the VM migration on this supervisor card removes Forklift’s sources, their credentials and the plans, and leaves the CRDs. It is refused with 409 while a run is going; Disable anyway… overrides that. It never touches migrated VMs.

Removing a source, cancelling, archiving or deleting a plan, disabling migration and removing a vCenter have no MCP tool: they are left to a person on purpose. Use the dashboard or the API.

​

What commonly goes wrong

​

Permissions

Three checks happen inside a request rather than on its route: Create and start also needs migration:StartPlan; keeping addresses needs cilium:Apply; and Load from vCenter needs capi:Install.

​

Next