On Tue, Feb 17, 2015 at 08:15:34PM -0700, Jim Fehlig wrote: > Stefan Bader wrote: > > Just recently we moved to libvirt 1.2.12 for the next release. Which brought up > > a few problems when working with configs which we and Debian used to have. > > > > A mild complaint towards the xml validation: it would be really nice of that > > would be a bit more specific about what exactly it complains. It took me a while > > to realize that "Extra element os in interleave" was trying to tell me > > that the string of the loader element within the os section was not an absolute > > path. > > > > The issue here is that with libxl, I think the goal was to rather allow the > > library to select the path prefix (like for pygrub where the full path got > > removed recently). But now the xml validation disagrees. > > > > This would go for bootloader for xenpv and loader (within os) for xenfv. And for > > emulator in the device section. Though for that things are a bit more > > complicated. The libxl driver now calls that with the help option and decides > > from the output whether this is the "traditional" xen forked qemu or the > > upstream qemu binary. Then it selects the device model depending on that outcome. > > > > It only sets the device_model_version > (LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN vs > LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL). device_model is > directly VIR_STRDUP'ed from def->emulator. > > > Not sure whether the libxl driver could query libxl for the path prefix. > > I asked about that too, but the Xen community preferred a build-time > approach. Wei Liu added a pkgconfig module to Xen, enabling build-time > detection of the paths > > commit babeca328413baebfdca366a5b17c06acf4295e8 > Author: Wei Liu <wei.liu2@xxxxxxxxxx> > Date: Fri Jan 9 14:32:18 2015 +0000 > > libxl: provide xenlight.pc > > A pkg-config file for libxl. It also contains two variables > (xenfirmwaredir and libexec_bin) so that tools that are very keen on > knowing the locations of Xen binaries (say, libvirt) can use them to > determine the location of the binaries. > > We are not yet making use of xenlight.pc in libvirt. But this work aims > to improve reporting the correct paths in *capabilities*. It could also > be used in the xl.cfg to domXML conversion code. > > > Right > > now the most straight forward way seems to move back to a full path for the > > emulator. > > Full paths are required as per the documentation. From > http://libvirt.org/formatdomain.html#elementsOSBootloader > > "The content of the |bootloader| element provides a fully qualified path > to the bootloader executable in the host OS." > > Same for <emulator>. > > > At least now, by using the standard qemu binary for everything, we got > > a predictable path that does not change with Xen versions. So its possible to > > force migrate over to put /usr/bin/qemu-system-i386 there. > > > > But for loader and bootloader, do you think it reasonable to change the > > templates from absFilePath to filePath? > > > > There's probably a fair bit of existing config with e.g. > <bootlaoder>pygrub</bootloader> that no longer validates. ATM, I don't > have a good answer :-/. Is correct capabilities information and xl.cfg > -> libvirt.xml conversion, along with better error reporting enough? > Should users change their non-validating domXML? > > From libvirt's perspective, I think full paths, discovered from > capabilities, should be required. I'd like to hear Daniel's opinion. > He may have considered such cases when enabling the validation. Yeah, I really think it should be using full paths for bootloader too Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list