Re: [libvirt] libxl and non-absolute paths
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(a)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.
Regards,
Jim
-Stefan
--- libvirt-1.2.12.orig/docs/schemas/domaincommon.rng 2015-01-23 12:46:24.0000
+++ libvirt-1.2.12/docs/schemas/domaincommon.rng 2015-02-13 10:00:43.1616
@@ -258,7 +258,7 @@
</choice>
</attribute>
</optional>
- <ref name="absFilePath"/>
+ <ref name="filePath"/>
</element>
</optional>
<optional>
@@ -1060,7 +1060,7 @@
<optional>
<element name="bootloader">
<choice>
- <ref name="absFilePath"/>
+ <ref name="filePath"/>
<empty/>
</choice>
</element>