2011/7/27 Whit Blauvelt <whit.virt@xxxxxxxxxxxxx>: >> That's not how libvirt works. The architecture is different than you >> seem to expect it. > > Matthias, > > Even with all you say - and I thank you for your patient explanation - there > remains a question: Why should 0.9.3+ git suddenly decide that the default > driver should be vbox, when 0.8.3 and 0.9.2 and 0.9.3, all on the same > system, and the second two similarly compiled with their defaults from the > tar, went to kvm instead? First, there is no default driver and nothing should have changed in the way drivers a selected. The only thing that has changed in this regard is that the type checking for the domain XML config was made stricter after 0.9.3. In 0.9.3 and before the VirtualBox driver happily accepted a domain config with type kvm. Basically all drivers didn't check whether or not a domain config was meant for them. Now the VirtualVtox driver only accepts type vbox and the QEMU driver accepts type qemu, kvm, kqemu and xen (xen for xenner). > There was no other change on the system. And the vbox processes I found > appear to have been started by libvirt itself, since vbox hasn't been run on > this system in over a year, during which time it's been rebooted without > vbox being invoked at all. I currently have no explanation for why libvirt 0.9.3+ picks VirtualBox for you now when it autoselected QEMU before. Are you sure that libvirt 0.9.3 and before had VirtualBox support compiled in? If not then VirtualBox can not supersede QEMU in the autodetection. That might explain it, but I don't see how that can happen apart from you explicitly disabling VirtualBox support at configure time. > If kvm is on the system as an option - which it has been all along - it > should be the libvirt default. KVM is the preferred hypervisor for all the > major distros. Having the libvirt default be a random, round robin selection > rather by ordered priority, in which kvm if available comes out on top, is > not good design. You're right the autodetection process is suboptimal and should be improved. But the selection is not random, the problem is that VirtualBox comes before QEMU in the probing order. This is due to how the remote driver interferes with the detection process. -- Matthias Bolte http://photron.blogspot.com
