KubeVirt VM Creation Sequence

KubeVirt VM Creation Sequence A sequence diagram generated by Archify. create VirtualMachine mutating + validating webhooks admitted VM added (informer) create VMI VM controller startVMI; VMI webhooks run again create virt-launcher Pod phase Pending -> Scheduling Pod bound to node start pod phase Scheduled VMI on this node (informer) SyncVirtualMachine gRPC unix socket define + create domain lifecycle event: started HandleDomainEvent notify status.phase = Running VMI Running Admit and reconcile Schedule Start domain virtctl · or kubectl · Sequence participant virtctl or kubectl kube-apiserver · CRDs, etcd · Sequence participant kube-apiserver CRDs, etcd virt-api · webhooks · Sequence participant virt-api webhooks virt-controller · VM + VMI ctrls · Sequence participant virt-controller VM + VMI ctrls kubelet · after scheduling · Sequence participant kubelet after scheduling virt-handler · node agent · Sequence participant virt-handler node agent virt-launcher · pod, per VMI · Sequence participant virt-launcher pod, per VMI libvirt · QEMU/KVM · Sequence participant libvirt QEMU/KVM Legend request return security async trace default message

Two controllers, two objects

  • • VM controller creates the VMI per runStrategy (watch/vm/vm.go startVMI)
  • • VMI controller renders the launcher Pod and drives the phase to Scheduled (watch/vmi/vmi.go)

Node handoff

  • • virt-handler alone reaches the launcher: gRPC over a unix socket (virt-handler/vm.go)
  • • virt-launcher owns libvirt and builds the domain XML, incl. SEV launchSecurity (virtwrap/manager.go)

How Running is decided

  • • libvirt lifecycle events go launcher notify client -> handler notify server
  • • Running reflects the domain state, not the Pod state; then Succeeded or Failed