KubeVirt 的一些后门

如果不修改 KubeVirt 源码的话有些需求很难实现，因为 KubeVirt 暴露出来的能力有限。但 KubeVirt 面向开发者提供了一些后门，可以用于一些深度定制需求。

1. libvirt log 设置修改#

有时候我们想要查看 libvirtd 日志，但如果我们进入 virt-launcher Pod 去修改 libvirtd 的日志并重启 libvirtd 进程，在 virt-launcher-monitor 看来 libvirtd 进程死了就意味着该虚拟机已经死亡。

KubeVirt 提供了 2 种方式让我们修改 libvirtd log 设置：

在 KubeVirt CR 中给 virtLauncher 设定 >=5 的 logVerbosity ，就可以在 virt-launcher Pod 的 log 中看到 libvirt 的 log。如下：

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

修改后无需重启任何 component pod，这部分配置是热载的。当然 virt-launcher Pod 无法动态修改

给 VMI 添加一个 kubevirt.io/libvirt-log-filters 的 annotation。可以直接指定 libvirt 的 log filter，详细设置规则可见：debug logs。

2. libvirt domain xml 修改#

KubeVirt VMI Spec 中开放的属性能满足大部分使用需求，但也有不少不支持的。例如 clock 的offset 属性就不支持设置为 localtime。

但 KubeVirt 提供了 hooksidecar 机制。在 virt-launcher 内根据 VMI Spec render 出 domain xml 后，会调用我们注册的 hook 让我们的 hook 有一次修改 domain xml 的机会。此时我们就可以任意修改 domain xml 了。

如果我们要自己开发一个 hooksidecar，那么可以在 KubeVirt 仓库的 cmd/example-*-hook-sidecar 中找到例子。

hooksidecar 会以 sidecar container 的方式运行在 virt-launcher Pod 内，通过 gRPC unix 与 virt-launcher 进行交互。

3. 持续更新中#

...