CPU Model / nested virt problem after lifemigration

[rbo]

After a life migration of a virtualized cluster node, virt-handler on that particular node won't start with error:

$ kubectl logs -n kubevirt virt-handler-4w99d virt-launcher
error: failed to get emulator capabilities

error: internal error: Failed to start QEMU binary /usr/libexec/qemu-kvm for probing: libvirt: error : cannot execute binary /usr/libexec/qemu-kvm: Permission denied

Check journalctl at the node:

    [core@ocp1-worker-3 ~]$ journalctl -b | grep kvm
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU4 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU1 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU0 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm_intel: Inconsistent VMCS config on CPU 7
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm_intel: Inconsistent VMCS config on CPU 5
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm_intel: Inconsistent VMCS config on CPU 3
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU6 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU2 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU5 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU7 failed
    Jan 09 10:40:20 ocp1-worker-3 kernel: kvm: enabling virtualization on CPU3 failed

Reboot of worker VM helps...

Looks like we have to settle the CPU features of a minimum or add a proper selector.

/cc @rguske idea?

[rguske]

I think we have to configure it properly: https://access.redhat.com/solutions/6692341

[rbo]

Looks like we have to avoid host-passthrough, and use:

features:
    - name: vmx
      policy: require
model: <CPU model>  # Optional

[DanielFroehlich]

@rbo @rguske is this still needed or can it be closed?

[rbo]

With #312 we definitely need the option to define a CPU model.