Some Backdoors of KubeVirt

If you don't modify the KubeVirt source code, some requirements are difficult to implement because the capabilities exposed by KubeVirt are limited. However, KubeVirt provides some backdoors for developers to use for deep customization needs.

1. Modifying libvirt log settings#

Sometimes we want to view the libvirtd log, but if we enter the virt-launcher Pod to modify the log of libvirtd and restart the libvirtd process, the virt-launcher-monitor will consider that the libvirtd process has died, which means that the virtual machine has died.

KubeVirt provides two ways for us to modify the libvirtd log settings:

Set logVerbosity to >=5 for virtLauncher in the KubeVirt CR, and you can see the libvirt log in the log of the virt-launcher Pod. For example:

apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
  name: kubevirt
  namespace: kubevirt
spec:
  configuration:
    developerConfiguration:
      logVerbosity:
        virtLauncher: 2
        virtHandler: 3
        virtController: 4
        virtAPI: 5
        virtOperator: 6

No need to restart any component pod after modification, this configuration is hot-loaded. Of course, the virt-launcher Pod cannot be dynamically modified.

Add an annotation kubevirt.io/libvirt-log-filters to the VMI. You can directly specify the libvirt log filter. For detailed setting rules, see: debug logs.

2. Modifying libvirt domain xml#

The properties opened in the KubeVirt VMI Spec can meet most usage requirements, but there are also many unsupported ones. For example, the offset attribute of clock does not support setting it to localtime.

However, KubeVirt provides a hooksidecar mechanism. After rendering the domain xml based on the VMI Spec in virt-launcher, it will call the hook we registered to give our hook a chance to modify the domain xml. At this time, we can freely modify the domain xml.

If we want to develop a hooksidecar ourselves, we can find examples in the cmd/example-*-hook-sidecar of the KubeVirt repository.

The hooksidecar will run as a sidecar container inside the virt-launcher Pod and interact with virt-launcher through gRPC unix.

3. Continuously updating#

...