Re: [libvirt] [PATCH] Fix legacy xen driver when building without modules

On Wed, Aug 29, 2012 at 03:59:17PM -0600, Jim Fehlig wrote: > Jim Fehlig wrote: > >> When building without driver modules, I've noticed that the legacy xen >> driver no longer works. The attached patch fixes it, but I'm not sure >> if this is the correct fix. >> > Sorry, I should have elaborated here. I don't think this is the correct > fix because now libvirt.so has a dependency on xen libs, e.g. > libxenstore, which (I think) defeats the purpose of modularizing the build. > > >> I need to do some more testing with and >> without modules, but wanted to raise this on the list for >> comments/suggestions. >> >> > When building libvirt without driver modules, I'm not able to connect to > the legacy xen driver > > # virsh version > Compiled against library: libvirt 0.10.0 > Using library: libvirt 0.10.0 > Using API: QEMU 0.10.0 > error: failed to get the hypervisor version > error: internal error Cannot find suitable emulator for x86_64 > > # virsh -c xen:/// version > error: internal error libxenlight state driver is not active > error: failed to connect to the hypervisor > > Which is correct, since the libxl driver won't load if xend is active. > But why is the legacy xen driver not tried? I can connect to the libxl > one when xend is not active > > # virsh version > Compiled against library: libvirt 0.10.0 > Using library: libvirt 0.10.0 > Using API: xenlight 0.10.0 > Running hypervisor: xenlight 4.1.0 > > When building with driver modules and trying to connect to the legacy > xen driver > > # virsh version > Compiled against library: libvirt 0.10.0 > Using library: libvirt 0.10.0 > Using API: QEMU 0.10.0 > error: failed to get the hypervisor version > error: internal error Cannot find suitable emulator for x86_64 > Ok, it used QEMU there, so lets ignore that. > # virsh -c xen:/// version > Compiled against library: libvirt 0.10.0 > Using library: libvirt 0.10.0 > Using API: Xen 0.10.0 > Running hypervisor: Xen 4.1.0 > > So this is a change in behavior, where the connection must now be > explicitly specified. Same goes for connecting to the libxl driver when > built with driver modules > > Suggestions on how to go about fixing all of this would be much > appreciated :). > You'll want to set LIBVIRT_LOG_FILTERS="1:libvirt 1:xen 1:libxl" for libvirtd and see what it logs about the connection probing when opening the driver