On 07/27/2011 03:21 AM, Matthias Bolte wrote: > 2011/7/27 Whit Blauvelt <whit.virt@xxxxxxxxxxxxx>: >>> What's the output of "# virsh -V" on your second ubuntu box? I guess >>> your libvirt on that box might not be compiled with qemu driver. >> >> # virsh -V >> Virsh command line tool of libvirt 0.9.3 ... >> >> Compiled with support for: >>  Hypervisors: QEmu/KVM UML OpenVZ VirtualBox LXC ESX Test >>  Networking: Remote Daemon Network Bridging Nwfilter VirtualPort >>  Storage: Dir Filesystem SCSI Multipath LVM >>  Miscellaneous: SELinux Secrets Debug Readline >> >>> Another possiablity is the libvirt is compiled with both qemu driver and >>> vbox driver, but when you try to creat a new connection, vbox was the >>> first succesfully connected one. In this case, you can try like below: >> >> Why? Ah, I do have a couple stray vbox processes somehow: >> >> root   25265  0.0  0.1  86076  4304 ?     S   19:34  0:00 /usr/lib/virtualbox/VBoxXPCOMIPCD >> root   25274  0.0  0.1 209964  6672 ?     Sl  19:34  0:02 /usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown >> >> But that should cause it to deny it knows how to handle Qemu/KVM? > > The point is that libvirt autodetects the available hypervisors at > runtime when you don't specify a connection URI. For example, just > running virsh results in autodetecting VirtualBox because you have it > installed in a way that it's still working and due to the way libvirt > works internally VirtualBox comes before QEMU in the autodetection > list. > I think this should be changed actually. I think it's clear that there are far more libvirt+kvm users than libvirt+vbox users, we should adjust the driver probing to match. Unfortunately it doesn't look like a simple change. - Cole
