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