Kubevirt Flow

  1. user calls kubectl create -f cluster/vm.json which triggers discovery and the HTTP call POST http://192.168.200.2:8184/apis/kubevirt.io/v1alpha1/namespaces/default/vms
  2. virt-controller is long polling the kubernetes API server, notices the new entry, and creates the a VM container definition
  3. kubernetes stores the VM definition in etcd
  4. Kubernetes scheduler picks up VM container defintion and...
  5. ...places virt-launcher container on node
  6. virt-hander sees the new VM definition
  7. virt-hander makes call to libvirtd via the libvirt API to create the new VM
  8. libvirt uses the virt-launcher container (which has been busy waiting) to create the new vm
Note: HA proxy is in between most of the callers and servers. While it provides an essential part of the system management, it does nothing specific to Kubernetes or Kubevirt, and is thus not shown in the diagram.
Adam Young