[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

2011/7/27 Whit Blauvelt <whit virt 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]