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. 持續更新中#

...