All, Even with Guido/Pritesh's recent changes to the vbox open routine, the auto-detection in libvirt is currently broken. What happens is that in src/libvirt.c:do_open(), at the start of the loop to auto-detect drivers, ret->uri is NULL. As each driver declines, it remains NULL. However, the very first thing the vboxOpen() routine does is: if (conn->uri == NULL) { conn->uri = xmlParseURI(uid ? "vbox:///session" : "vbox:///system"); if (conn->uri == NULL) { return VIR_DRV_OPEN_ERROR; } So, any driver that is trying to auto-probe after vboxOpen sees a conn->uri with a scheme of vbox and a path of system/session, and they all fail (including Qemu, which is what I'm mostly concerned with at the moment).

Pritesh Kothari wrote: > On Tuesday 12 May 2009 11:36:50 Chris Lalancette wrote: >> All, >> Even with Guido/Pritesh's recent changes to the vbox open routine, >> the auto-detection in libvirt is currently broken. What happens is that >> in src/libvirt.c:do_open(), at the start of the loop to auto-detect >> drivers, ret->uri is NULL. As each driver declines, it remains NULL. >> However, the very first thing the vboxOpen() routine does is: >> >> if (conn->uri == NULL) { >> conn->uri = xmlParseURI(uid ? "vbox:///session" : >> "vbox:///system"); if (conn->uri == NULL) { >> return VIR_DRV_OPEN_ERROR; >> } >> >> So, any driver that is trying to auto-probe after vboxOpen sees a >> conn->uri with a scheme of vbox and a path of system/session, and they >> all fail (including Qemu, which is what I'm mostly concerned with at the >> moment). > > this seems to be common case in all other drivers also, for example uml, > openvz, etc does the same and not to mention that qemu driver does it > also, so i guess the fix should apply to all and not just vbox driver. Well, yes and no. They all do it, but only *after* doing their probe routines. At least, I've never had a problem with auto-detection until I enabled vbox to build in my libvirt config.

On Tue, May 12, 2009 at 11:36:50AM +0200, Chris Lalancette wrote: > All, > Even with Guido/Pritesh's recent changes to the vbox open routine, the > auto-detection in libvirt is currently broken. What happens is that in > src/libvirt.c:do_open(), at the start of the loop to auto-detect drivers, > ret->uri is NULL. As each driver declines, it remains NULL. However, the very > first thing the vboxOpen() routine does is: > > if (conn->uri == NULL) { > conn->uri = xmlParseURI(uid ? "vbox:///session" : "vbox:///system"); > if (conn->uri == NULL) { > return VIR_DRV_OPEN_ERROR; > } > > So, any driver that is trying to auto-probe after vboxOpen sees a conn->uri with > a scheme of vbox and a path of system/session, and they all fail (including > Qemu, which is what I'm mostly concerned with at the moment). Please re-test with the patch I posted yesterday http://www.redhat.com/archives/libvir-list/2009-May/msg00198.html > In point of fact, this whole auto-detection thing is fragile. We got away with > it before because the qemuOpen() routine bombs out before doing the whole > conn->uri == NULL check, but in general, it's very easy for one buggy driver to > mess up auto-detection for all drivers. The general rule is that a driver should not set conn->uri to non-NULL until *after* it has determined that it can handle it. The problem here was that virtualbox driver was setting the uri to non-NULL, and only then seeing if virtalbox was available. My patch fixes that logic ordering bug