Re: [libvirt-users] with current libvirt git virsh expects vbox, refuses kvm define
2011/7/27 Whit Blauvelt <whit.virt(a)transpect.com>:
> What's the output of "# virsh -V" on your second
ubuntu box? I guess
> your libvirt on that box might not be compiled with qemu driver.
# virsh -V
Virsh command line tool of libvirt 0.9.3 ...
Compiled with support for:
Hypervisors: QEmu/KVM UML OpenVZ VirtualBox LXC ESX Test
Networking: Remote Daemon Network Bridging Nwfilter VirtualPort
Storage: Dir Filesystem SCSI Multipath LVM
Miscellaneous: SELinux Secrets Debug Readline
> Another possiablity is the libvirt is compiled with both qemu driver and
> vbox driver, but when you try to creat a new connection, vbox was the
> first succesfully connected one. In this case, you can try like below:
Why? Ah, I do have a couple stray vbox processes somehow:
root 25265 0.0 0.1 86076 4304 ? S 19:34 0:00
/usr/lib/virtualbox/VBoxXPCOMIPCD
root 25274 0.0 0.1 209964 6672 ? Sl 19:34 0:02
/usr/lib/virtualbox/VBoxSVC --pipe 4 --auto-shutdown
But that should cause it to deny it knows how to handle Qemu/KVM?
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.
> # virsh -c qemu:///sytem list --all
Okay, that one works.
Here you're telling libvirt to connect to QEMU explicitly, that's why
it doesn't do autodetection here.
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.
--
Matthias Bolte
http://photron.blogspot.com