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

[Matthias Bolte]

2011/7/27 Whit Blauvelt <whit.virt at transpect.com>:
> On Wed, Jul 27, 2011 at 09:21:08AM +0200, Matthias Bolte wrote:
>
>> 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.
>
> But shouldn't it autodetect _all_ available hypervisors and then, when an
> xml file specifies kvm - which is available - use it rather than complain it
> has a problem with it? You're describing the current behavior as if it's to
> be accepted. Clearly having libvirt recognize that the kvm hypervisor is
> available, and automatically using it when the xml file specifies it, does
> not take some extraordinary level of clever programming. "The xml specifies
> kvm. Do I have kvm? Why, yes I do!"
>
>> The initial "error: internal error unexpected domain type kvm,
>> expecting vbox" you saw was added recently to prevent incompatible
>> driver/config combinations. In you're case it highlighted that
>> autodetection didn't work for you as expected.
>
> Fine, so when it recognizes it has the wrong driver for the config, it
> should grab the right driver. No reason for it to complain to me about it.
> It should simply do its job. Right? This is a bug that it doesn't?
>
> Whit
>

That's not how libvirt works. The architecture is different than you
seem to expect it.

When you open a connection libvirt picks a driver for it. If you're
using virsh you may not be aware of the connection as this is
happening mostly implicit.

If you tell libvirt which driver/hypervisor you want then it'll try to
use that one. For example when you do virsh -c qemu:///system then
libvirt will ask it's connection/hypervisor drivers until it find one
that accepts this URI. In case of qemu:///system the QEMU driver will
accept it in the end (after going through the remote driver, but
that's transparent for the user). If you just run virsh then libvirt
will again ask it's drivers one after another if they can accept an
empty connection URI. In you case the VirtualBox driver accepted it
because it found a local VirtualBox installation that it can use.

Once the connection is opened and has a driver assigned then calls to
the libvirt API are dispatched to the selected driver. So when you do
a virsh define then this will call the implementation of the
virDomainDefine function in the VirtualBox driver (because that one
was autoselected). There is no driver selection in the API after the
connection is opened.

For libvirt to work as you describe it virsh define (actually
virDomainDefine) needs to parse the XML to the the type and pick a
driver based on that. That might work to some extend in the local case
where qemu:///system could be deduced from type=kvm, but won't work in
the general or remote case. For example a domain config with type
vmware can be used with the VMware ESX and the VMware Workstation
driver, so how to pick the driver here? Even when you solve this by
using vmware-esx and vmware-workstation instead then you need to tell
libvirt in the virDomainDefine call where the ESX server is and with
what options and credentials you want open the connection. In the
current libvirt architecture you do that when you open the connection
via the connection URI instead.

Your suggestion also implies that virsh list lists all domains on all
available hypervisors. This requires name/ID/UUID uniqueness across
multiple hypervisors, that gets hairy fast. Also you have the problem
of specifying the connection details to virsh list, maybe even for
multiple remote connections.

So there is no bug in general here, as this is how libvirt is designed
to work. One could argue that libvirt should be able to pick the right
driver in virDomainDefine, but that is not as simple as it sounds.
Also it doesn't fit to the way things currently work, so I don't see
that happening anytime soon.

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