Validate host's virtualization capabilities before calling libvirt

[a-darwish]

When running elbe initvm create on a host with no /dev/kvm or just no /dev/net/tun, the cryptic error messages below are produced:

libvirt: Capabilities Utils error : invalid argument: could not find capabilities for arch=x86_64 domaintype=kvm 
Traceback (most recent call last):
  File "/usr/bin/elbe", line 55, in <module>
    cmdmod.run_command(sys.argv[2:])
  File "/usr/lib/python2.7/dist-packages/elbepack/commands/initvm.py", line 98, in run_command
    action.execute(directory, opt, args[1:])
  File "/usr/lib/python2.7/dist-packages/elbepack/initvmaction.py", line 560, in execute
    self.conn.defineXML(xml)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3750, in defineXML
    if ret is None:raise libvirtError('virDomainDefineXML() failed', conn=self)
libvirt.libvirtError: invalid argument: could not find capabilities for arch=x86_64 domaintype=kvm 

This is for example the case in LXC containers.

libvirt virt-host-validate was quite helpful in showing where the problem is:

$ virt-host-validate 
  QEMU: Checking for hardware virtualization                                 : PASS
  QEMU: Checking if device /dev/kvm exists                                   : PASS
  QEMU: Checking if device /dev/kvm is accessible                            : PASS
  QEMU: Checking if device /dev/vhost-net exists                             : WARN (Load the 'vhost_net' module to improve performance of virtio networking)
  QEMU: Checking if device /dev/net/tun exists                               : FAIL (Load the 'tun' module to enable networking for QEMU guests)
  QEMU: Checking for cgroup 'cpu' controller support                         : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support                     : PASS
  QEMU: Checking for cgroup 'cpuset' controller support                      : PASS
  QEMU: Checking for cgroup 'memory' controller support                      : PASS
  QEMU: Checking for cgroup 'devices' controller support                     : PASS
  QEMU: Checking for cgroup 'blkio' controller support                       : PASS
  QEMU: Checking for device assignment IOMMU support                         : PASS
  QEMU: Checking if IOMMU is enabled by kernel                               : PASS
   LXC: Checking for Linux >= 2.6.26                                         : PASS
   LXC: Checking for namespace ipc                                           : PASS
   LXC: Checking for namespace mnt                                           : PASS
   LXC: Checking for namespace pid                                           : PASS
   LXC: Checking for namespace uts                                           : PASS
   LXC: Checking for namespace net                                           : PASS
   LXC: Checking for namespace user                                          : PASS
   LXC: Checking for cgroup 'cpu' controller support                         : PASS
   LXC: Checking for cgroup 'cpuacct' controller support                     : PASS
   LXC: Checking for cgroup 'cpuset' controller support                      : PASS
   LXC: Checking for cgroup 'memory' controller support                      : PASS
   LXC: Checking for cgroup 'devices' controller support                     : PASS
   LXC: Checking for cgroup 'freezer' controller support                     : PASS
   LXC: Checking for cgroup 'blkio' controller support                       : PASS
   LXC: Checking if device /sys/fs/fuse/connections exists                   : PASS

ELBE should do a basic host sensitization test like above before issuing any libvirt calls. Maybe also informing users about virt-host-validate so they can solve the problem on their own.

Thanks,

[a-darwish]

Side note, for completeness.

libvirt API calls failed after fixing the /dev/net/tun issues due to a read-only sysfs inside LXC container. virt-host-validate should have warned about that, but it didn't. Submitted a bug report:

• virt-host-validate: Check for sysfs write access

[t-8ch]

KVM validation is now done ( 976df59 and f6b66e2 )