Once KubeVirt is installed on a cluster, running a VM follows the same basic shape as deploying anything else on Kubernetes: define the desired state as an object, apply it, and let the control plane reconcile reality to match. Here's what that workflow actually looks like end to end.
1. Prepare a disk image
A VM needs a boot disk, typically a standard cloud image in qcow2 or raw format — the same kind of image used with any KVM/QEMU-based virtualization platform. That image is made available to the cluster either as a container disk (packaged inside a container image) or attached via a PersistentVolumeClaim, so it goes through the cluster's normal storage system.
2. Define the VirtualMachine object
A VirtualMachine manifest describes CPU, memory, the disk to boot from, and network interfaces — conceptually similar to a Pod spec, just describing virtualized hardware instead of a container image. It also declares whether the VM should be running, the same way a Deployment declares a replica count.
3. Apply it and let Kubernetes take over
Applying the manifest creates a VirtualMachineInstance, which virt-controller schedules onto a node exactly like a pod. From that point, standard commands work as expected — listing running VMs, watching status, tailing events — because a VM is a native API object, not something bolted on beside Kubernetes.
4. Access the console
KubeVirt exposes a serial console and a VNC-style graphical console through the Kubernetes API itself, so operators can reach a VM's console the same way they'd exec into a pod — no separate hypervisor management network to route through.
5. Attach storage and networking
Additional disks attach as PersistentVolumeClaims; additional or specialized network interfaces attach through the cluster's CNI plugin, with Multus handling cases that need more than one network attached to a single VM.
6. Day-2: snapshot, clone, migrate
The same declarative model extends to ongoing operations — snapshotting a VM's disk state, cloning it into a new instance, or live-migrating it off a node before maintenance — all expressed as Kubernetes objects and reconciled the same way the initial VM was.
Doing this without hand-written YAML
That workflow is accurate and it works — but writing and tracking YAML by hand for every VM, image, snapshot and migration doesn't scale past a handful of machines. A Kubernetes management platform like AetherVirt wraps this workflow in a console: golden images and flavors so a new VM starts from an approved baseline, one-click snapshot and migration, and RBAC-checked, audit-logged actions instead of raw kubectl apply.