Feature: Kubernetes: KubeVirt support enhancements
KubeVirt is a libvirt virtual machine management add-on for Kubernetes. It adds new Kubernetes kind "vms" allowing to deploy virtual machines in a similar way to pods. virtual machines are actually run inside containers (KubeVirt architecture).
- Goal: Show and interact with KubeVirt virtual machines (VMs) in case Kubevirt is installed.
- This enhancement should only be visible to user if connected Kubernetes cluster is a KubeVirt instance.
- Scope: Conditionally enabled Virtual Machines listing showing logs and links to relative entities in expandable area and visually distinguishing KubeVirt related pods and nodes in existing listings.
- UI corresponding to
kubectl get vms
- Answers to questions:
- Virtual Machine listing: What virtual machines are running in the cluster? Are all VMs running OK? Where is the VM running (which node, which pod)?
- Visual marking of KubeVirt related pods and containers: Is my KubeVirt infrastructure running ok? Are my KubeVirt virtual machines running ok? How does kubevirt infrastructure looks like? Where is the container running libvirt?
- 'machines' plugin is expected to be used for detailed manipulation with VMs.
Phillip J. Fry leads a small IT at a moderately sized firm. His company has a modest data center.
Phillip is running manages private company applications. New ones are already conteinerized and running natively on Kubernetes. Old application are run in VMs using KubeVirt on the same Kubernetes infrastructure.
Phillip is reported one of old apps is not running ok. He uses Virtual Machines view of 'kubernetes' plugin to look at deployed VMs, their state and logs.
Bender Bending Rodriguez leads a small IT at a moderately sized firm. His company has a modest data center.
Bender uses Kubernetes to manage containers only. He manages VMs in different environment. When Bender opens 'kubernetes' Cockpit plugin, there is no 'Virtual Machines' listing since KubeVirt is not installed on his cluster.
Dr. John A. Zoidberg leads a small IT at a moderately sized firm. His company has a modest data center. The data center uses KubeVirt to run virtual machines.
Zoidberg wants to perform a regular check whether KubeVirt infrastructure is running ok.
Prof. Hubert J. Farnsworth leads a small IT at a moderately sized firm. His company has a modest data center.
Professor uses Kubernetes to manage containers only. He manages VMs in different environment. However he is curious about KubeVirt and want to get to know more about this technology. Professor installs KubeVirt to explore it and evaluate its benefits.
- Open Virtual Machines listing and identifies broken VM by its state.
- Expands row of broken VM and inspect the log.
- Based on logs makes a guess what the causes of the problem uses general tab to jump to the relevant entity.
- Opens Containers view, applies filter to see only KubeVirt related containers and checks if all of them are ok.
- Or opens Details > Pods listing, applies filter to see only KubeVirt related pods and checks if all of them are ok.
- Install a clean KubeVirt instance.
- Opens Containers listing and Details > Pods listing and inspects how does KubeVirt infrastructure looks like, what containers comes from kubernetes itself, what containers are added by KubeVirt.
- Deploys a virtual machine.
- Inspects what containers and pods were added by starting a new virtual machine, view virtual machine details in Virtual Machine listing.
- KubeVirt doesn't currently have any UI.
- 'kubernetes' plugin of Cockpit allows to manage pure Kubernetes.
- 'machines' Cockpit plugin, oVirt, virt-manager allows to manage libvirt virtual machines.
Virtual Machines view
Distinguishing KubeVirt related containers
KubeVirt related containers marked (each container has at most one marker):
Filtering of containers according to markers (filters are applied immediately):
I'm not sure the cockpit-machines link works. cockpit-machines only works with VMs running on that host. The VM may be running somewhere else. Also the UI may be running in a container in which case it won't have access to the nodes at all. It might be better just to stick to a generic link to cockpit on that node.
- Yes, I agree - the link will probably not work. In general we should assume that cockpit is running in the "pod" mode where it is floating on a cluster, we should not work with the assumption that any host related cockpit pages are available locally or remote.