[libvirt] libxl and non-absolute paths

[Daniel P. Berrange]

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 at citrix.com>
> 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 :|