VMs defined by Kubernetes resources
The first big difference is in representation. In traditional virtualization systems, a VM is defined by an object or set of objects tightly controlled by the hypervisor. Its configuration, disk files, snapshots, and runtime state are all stored in a platform-specific way, enabling consistent backup semantics across different environments.
KubeVirt relies on the Kubernetes model instead. Virtual machines are defined using Kubernetes custom resources such as VirtualMachine, VirtualMachineInstance, and (with CDI) DataVolume, which are stored in the Kubernetes control plane. Their configuration is thus described declaratively in YAML, and their life cycle is managed by KubeVirt’s controllers. A VM definition in KubeVirt is therefore not a bundle of hypervisor objects, but a collection of Kubernetes resources describing compute, storage, networking, initialization, and storage volumes.
A generation of Kubernetes administrators have come to appreciate Kubernetes’ open, declarative model and YAML-based definitions, but for VM administrators it may be a bit confusing at first. More importantly for our purposes, the way this critical metadata is backed up and restored is entirely different. You’ll need to use Kubernetes-specific tools rather than the tools you’ve been using, and those tools will require at least a basic understanding of the Kubernetes control plane.
