“Can you live-migrate?” is the wrong first question. The useful question is whether the disk is shared, and whether you are buying vSphere HA or a VM move.
What ships
Live migration on kcore needs shared Ceph storage. The disk is an RBD image. Changing hosts does not copy guest blocks, because both nodes map the same image during cutover. The command is kctl migrate vm. Memory streams over TCP. A cold move is kctl drain node: the control plane reassigns the VMs, Nix stops them on the source and starts them on the destination. kctl migrate vm --allow-cold-fallback tries live, then cold, for that VM.
Local backends — filesystem, LVM, and ZFS — keep the disk on the host that runs the guest. Those are the right choice when latency matters. They are the wrong choice if the requirement is that this VM must move without a copy.
What this is not
Control-plane replication across datacenters is not vSphere HA. A second site that receives control-plane state does not restart your guests the way vSphere HA does. Do not put that sentence in a customer proposal.
Terraform provider 0.5.0 has no migrate or drain resource. Those stay kctl commands. A Ceph data disk can be a kcore_volume with storage class ceph. On that provider, kcore_vm storage_backend is filesystem, lvm, or zfs. The ceph flag on the VM is kctl.
How to choose
- An application server that should fail over: Ceph RBD, then a live or cold migrate.
- A database that needs local NVMe: LVM or ZFS, and a planned stop if the host is drained.
- A multi-site “HA” slide: read the limit again before you draw the arrow.
The operator runbook is the VM migration page. Ceph layout is on the kcore SAN page. Read those before you promise a maintenance window of zero.
Questions: team@tacconiconsulting.com.