[libvirt-users] with current libvirt git virsh expects vbox, refuses kvm define

[Matthias Bolte]

2011/7/27 Cole Robinson <crobinso at redhat.com>:
> On 07/27/2011 03:21 AM, Matthias Bolte wrote:
>> 2011/7/27 Whit Blauvelt <whit.virt at transpect.com>:
>>>> 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.

Sure, the problem is that QEMU goes through the remote driver (because
it's a daemon/stateful driver) and that one is last in the local
probing list. I don't currently see how we can give QEMU a higher
position in the list, except by special casing it in the probing
process.

-- 
Matthias Bolte
http://photron.blogspot.com