于 2011年07月27日 08:04, Whit Blauvelt 写道: Hi, Whit 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. 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: # virsh -c qemu:///sytem list --all Or you can set the ENV variable VIRSH_DEFAULT_CONNECT_URI or LIBVIRT_DEFAULT_URI to the URI of the hypervisor you want to connect to. Osier

2011/7/27 Whit Blauvelt <whit.virt(a)transpect.com&gt;: 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. 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

2011/7/27 Whit Blauvelt <whit.virt(a)transpect.com&gt;: That's not how libvirt works. The architecture is different than you seem to expect it. When you open a connection libvirt picks a driver for it. If you're using virsh you may not be aware of the connection as this is happening mostly implicit. If you tell libvirt which driver/hypervisor you want then it'll try to use that one. For example when you do virsh -c qemu:///system then libvirt will ask it's connection/hypervisor drivers until it find one that accepts this URI. In case of qemu:///system the QEMU driver will accept it in the end (after going through the remote driver, but that's transparent for the user). If you just run virsh then libvirt will again ask it's drivers one after another if they can accept an empty connection URI. In you case the VirtualBox driver accepted it because it found a local VirtualBox installation that it can use. Once the connection is opened and has a driver assigned then calls to the libvirt API are dispatched to the selected driver. So when you do a virsh define then this will call the implementation of the virDomainDefine function in the VirtualBox driver (because that one was autoselected). There is no driver selection in the API after the connection is opened. For libvirt to work as you describe it virsh define (actually virDomainDefine) needs to parse the XML to the the type and pick a driver based on that. That might work to some extend in the local case where qemu:///system could be deduced from type=kvm, but won't work in the general or remote case. For example a domain config with type vmware can be used with the VMware ESX and the VMware Workstation driver, so how to pick the driver here? Even when you solve this by using vmware-esx and vmware-workstation instead then you need to tell libvirt in the virDomainDefine call where the ESX server is and with what options and credentials you want open the connection. In the current libvirt architecture you do that when you open the connection via the connection URI instead. Your suggestion also implies that virsh list lists all domains on all available hypervisors. This requires name/ID/UUID uniqueness across multiple hypervisors, that gets hairy fast. Also you have the problem of specifying the connection details to virsh list, maybe even for multiple remote connections. So there is no bug in general here, as this is how libvirt is designed to work. One could argue that libvirt should be able to pick the right driver in virDomainDefine, but that is not as simple as it sounds. Also it doesn't fit to the way things currently work, so I don't see that happening anytime soon. -- Matthias Bolte http://photron.blogspot.com

2011/7/27 Whit Blauvelt <whit.virt(a)transpect.com&gt;: 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). 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. 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

On Wed, Jul 27, 2011 at 08:42:59AM -0400, Whit Blauvelt wrote: [..] Virsh first opens a connection to an hypervisor, and then tries to run the commands (can be multiple one for example in shall mode). What you're suggestion is to do some introspection on the XML, and then change the way virsh works just for that command, that's not that trivial nor very clean. On the other hand what was improved recently is that if a command like create uses the "wrong" hypervisor type in the XML we are now reporting the expected hypervisor type instead of just failing the operation as you got. If you try with 0.9.4-rc1 it should have that improvement, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2011/7/27 Cole Robinson <crobinso(a)redhat.com&gt;: Sure, the problem is that QEMU goes through the remote driver (because it's a daemon/stateful driver) and that one is last in the local probing list. I don't currently see how we can give QEMU a higher position in the list, except by special casing it in the probing process. -- Matthias Bolte http://photron.blogspot.com