要用 Go 直连 Kubevirt API 创建虚拟机，必须使用 kubevirt.io/client-go 初始化 clientset 并注册 CRD 类型，否则无法识别 VirtualMachine；Create 成功但 Pending 常因 spec.running=false 或控制器未就绪；判断 SSH 可用需轮询 VMI 的 IP 和 Ready Condition；删除 VM 需显式处理 VMI 和 finalizer。
怎么用 Go 直连 Kubevirt API 创建虚拟机
不能只靠 kubectl 或 YAML 文件，得用 Go client 真正发请求。Kubevirt 没有独立 client-go 分支，它复用 Kubernetes 原生 client，但必须手动注册自定义资源（CRD）类型，否则 clientset 根本不认识 VirtualMachine 这类对象。
实操要点：
- 必须引入
kubevirt.io/client-go（不是client-go官方库），它封装了 Kubevirt CRD 的 Scheme 注册和 clientset 构建逻辑 - 初始化 clientset 时，不能只传
*rest.Config，还得显式调用kubecli.NewForConfig，它内部会自动添加VirtualMachineVirtualMachineInstance等 GroupVersion - 如果跳过这一步，直接用标准
clientset.CoreV1()去 getVirtualMachine，会报错：the server doesn't have a resource type "virtualmachine"
示例关键行：
client, err := kubecli.NewForConfig(config)
if err != nil {
panic(err)
}
vm, err := client.VirtualMachine(vmNamespace).Create(context.TODO(), vmObj, metav1.CreateOptions{})
为什么 Create() 成功但 VM 一直 Pending
常见现象：Go 代码返回 no error，kubectl get vm 显示 Phase: Pending，且长时间不变成 Running。这不是代码问题，而是 Kubevirt 控制器没触发或资源不满足调度条件。
立即学习“go语言免费学习笔记（深入）”；
排查重点：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 检查
VirtualMachine的.spec.running字段是否为true—— 如果是false，它只会创建但不启动，状态就是 Pending - 确认对应命名空间下是否存在
VirtualMachineInstance（VMI）：运行kubectl get vmi -n <ns>，没有说明控制器压根没响应；有但状态是Failed或Scheduling，说明节点资源或 CNI 插件有问题 - Kubevirt 要求节点有
kubevirt.io/virt-handlerDaemonSet 正常运行，且 CPU 支持虚拟化（cat /proc/cpuinfo | grep vmx|svm），缺一不可
如何用 Go 获取 VMI 实时状态并判断是否真正可 SSH
仅看 VMI.Status.Phase == "Running" 不够 —— 它只表示 QEMU 进程已启动，不代表网卡就绪、cloud-init 完成、SSH 服务监听。得组合多个字段做判断。
实操建议：
- 轮询
client.VirtualMachineInstance(vmiNamespace).Get()，关注VMI.Status.Interfaces是否非空且.IP字段有值 - 同时检查
VMI.Status.Conditions中是否有type: "Ready"且status: "True"的条目（这是 Kubevirt 0.50+ 引入的明确就绪信号） - 避免硬编码等待时间，用
wait.PollImmediate(2*time.Second, 3*time.Minute, ...)配合自定义 check 函数更可靠 - 注意：
VMI.Status.Interfaces[0].IP是 Pod 网络 IP，若用 NodePort 或 LoadBalancer 暴露 SSH，需额外查 Service 或路由规则
删除 VM 时为什么 Delete() 返回成功但 VMI 还在运行
这是 Kubevirt 的级联删除行为导致的。默认 Delete() 只删 VirtualMachine 对象，不会自动删关联的 VirtualMachineInstance —— 因为 VM 是声明式“模板”，VMI 是运行时实例，二者生命周期解耦。
要真正清干净：
- 设置
PropagationPolicy：在metav1.DeleteOptions{}中传入metav1.PropagationPolicy(metav1.DeletePropagationBackground)或DeletePropagationForeground，前提是 VM 的.spec.template.spec已正确配置ownerReferences - 更稳妥的做法是先删 VM，再主动调用
client.VirtualMachineInstance().Delete()清理残留 VMI（加context.WithTimeout防卡死） - 如果 VM 处于
Stopping状态，直接删可能被控制器拦截；应先 patch.spec.running = false，等 VMI 自动终止后再删 VM
容易忽略的一点：Kubevirt 的 finalizer（如 kubevirt.io/vm-finalizer）若未清理，VM 对象会卡在 Terminating 状态，此时得手动 patch 删除 finalizers 字段。
