Re: [libvirt-users] with current libvirt git virsh expects vbox, refuses kvm define
2011/7/27 Whit Blauvelt <whit.virt(a)transpect.com>:
> 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