Daniel P. Berrange wrote: > 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 > Blah, I shouldn't have been so lazy and done more investigation before posting this. I've sent a proper patch to fix these issues https://www.redhat.com/archives/libvir-list/2012-August/msg01950.html Thanks! Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list