2011/7/27 Whit Blauvelt <whit.virt@xxxxxxxxxxxxx>: > 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
