kubevirt: VMs fail to launch with Insufficient devices.kubevirt.io/tun

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened: try to launch a vm on 0.7.0 . the related pod stays in pending mode, with the following message Warning FailedScheduling 5s (x6 over 20s) default-scheduler 0/1 nodes are available: 1 Insufficient devices.kubevirt.io/tun.

What you expected to happen: vm launches

How to reproduce it (as minimally and precisely as possible): deploy 0.7.0 with a configmap to useEmulation create a vm cry

Anything else we need to know?:

Environment:

  • KubeVirt version (use virtctl version): Client Version: version.Info{GitVersion:“v0.7.0”, GitCommit:“b5b91243f540739eb5db61af89b2f1e5ba449dfa”, GitTreeState:“clean”, BuildDate:“2018-07-04T14:16:40Z”, GoVersion:“go1.10”, Compiler:“gc”, Platform:“linux/amd64”} Server Version: &version.Info{GitVersion:“v0.7.0”, GitCommit:“b5b91243f540739eb5db61af89b2f1e5ba449dfa”, GitTreeState:“clean”, BuildDate:“2018-07-04T14:16:40Z”, GoVersion:“go1.10”, Compiler:“gc”, Platform:“linux/amd64”}

  • Kubernetes version (use kubectl version): oc v3.10.0-rc.0+c20e215 kubernetes v1.10.0+b81c8f8 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://kubevirt:8443 openshift v3.10.0-rc.0+e132a20-38 kubernetes v1.10.0+b81c8f8

  • VM or VMI specifications:

  • Cloud provider or hardware configuration:

  • OS (e.g. from /etc/os-release):

  • Kernel (e.g. uname -a):

  • Install tools:

  • Others:

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 77 (62 by maintainers)

Most upvoted comments

Seems that during my tests, the configmap being created on kube-system was good because the underlying hipervisor had indirect support for nested vms, I’ve replaced the name and create it after the operator is deployed and worked fine so far.

Thanks!

troubleshooted this with mark and the issue was that minishift lacks nested virt so using emulation mode is necessary on this platform (and our http://kubevirt.io/get_kubevirt/ page needs to be updated to reflect it)

The workaround for oc and minishift will be required until openshift releases an update to 3.10 or 3.11. Eventually there is a change on KubeVirt which would also fix this as a side effect - btu the ETA here is unclear as well.

We should adjust the getting started content in the meantime …

There is just no quick fix.

I see a similar error when attempting to launch a VMI with upstream Kubernetes 1.10 + KubeVirt 0.7.0 on CentOS 7.5 using software emulation on AWS.

[centos@ip-10-0-4-56 tests]$ kubectl version Client Version: version.Info{Major:“1”, Minor:“10”, GitVersion:“v1.10.5”, GitCommit:“32ac1c9073b132b8ba18aa830f46b77dcceb0723”, GitTreeState:“clean”, BuildDate:“2018-06-21T11:46:00Z”, GoVersion:“go1.9.3”, Compiler:“gc”, Platform:“linux/amd64”}

kubectl describe vmi Message: 0/1 nodes are available: 1 Insufficient devices.kubevirt.io/tun. Reason: Unschedulable

  • /dev/net/tun exists
  • The existence of the ‘tun’ kernel module didn’t make a difference.
  • devices.kubevirt.io/tun doesn’t show in allocatable section nor capacity section
  • virt-handler log shows kvm device not found and I have software emulation enabled using a ConfigMap to set useEmulation to true.

[centos@ip-10-0-4-56 tests]$ kubectl logs virt-handler-nd44c -n kube-system level=info timestamp=2018-07-18T18:03:22.909622Z pos=virt-handler.go:87 component=virt-handler hostname=ip-10-0-4-56.ec2.internal level=info timestamp=2018-07-18T18:03:22.914610Z pos=vm.go:210 component=virt-handler msg=“Starting virt-handler controller.” level=info timestamp=2018-07-18T18:03:22.915565Z pos=cache.go:151 component=virt-handler msg=“Synchronizing domains” level=info timestamp=2018-07-18T18:03:23.016930Z pos=device_controller.go:131 component=virt-handler msg=“Starting device plugin controller” level=info timestamp=2018-07-18T18:03:23.016994Z pos=device_controller.go:111 component=virt-handler msg=“kvm device not found. Waiting.”