Re: [libvirt] libxl and non-absolute paths
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.l...@citrix.com Date: Fri Jan 9 14:32:18 2015 + 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. bootlaoderpygrub/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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl and non-absolute paths
On Mon, Feb 16, 2015 at 10:26:56AM +0100, Stefan Bader wrote: On 16.02.2015 10:18, Martin Kletzander wrote: On Fri, Feb 13, 2015 at 03:20:07PM +0100, 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. Not sure whether the libxl driver could query libxl for the path prefix. Right now the most straight forward way seems to move back to a full path for the 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? Maybe stupid question here... How does the string with the prefix look like then? Is it something like bootloaderpygrub:/path/to/loader ? No, sorry I should probably have added that: in both cases there is only the binary name in the config and libxl extends things internally. So bootloaderpygrub/bootloader and loaderhvmloader/loader. Sorry for late reply. I, personally, would be OK with that, I would just make sure that other drivers (e.g. QEMU) handles that as well. -Stefan -Stefan --- libvirt-1.2.12.orig/docs/schemas/domaincommon.rng 2015-01-23 12:46:24. +++ libvirt-1.2.12/docs/schemas/domaincommon.rng2015-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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list pgpcxxJkvm1ue.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl and non-absolute paths
On 18.02.2015 04:15, 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. Ok, I did not word that correctly. The main caveat here is that to figure out the device_model_version it calls out to what is set in def-emulator. So it needs a full path. Up to libvirt 1.2.8 at least the contents of def-emulator were actually rather ignored since we ended up with qemu-dm which was not true at all. 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.l...@citrix.com Date: Fri Jan 9 14:32:18 2015 + 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. Hm, ok. I guess there is upstream and upstream who might also be doing Debian (and derivatives of that). Since libxl is part of a version package the pathnames change between Xen versions. Maybe something to discuss about but not really here. Reality now causes the full path requirement to become a major pain in the butt. 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. bootlaoderpygrub/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? Potentially this has to be magically converged in postparse of libxl. This is where I currently move from the completely lying qemu-dm to /usr/lib/qemu-system-i386. Though this will depend on using xenlight.pc and that depends on it being there. The change currently only is on the devel master branch. So presumably Xen 4.6 may have it. For the reality of now I guess the best way around the issues is to either disable validation completely or at least make that absFilePath-filePath conversion. None of that though is worthy of being upstream. -Stefan 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. +++ libvirt-1.2.12/docs/schemas/domaincommon.rng2015-02-13 10:00:43.1616 @@ -258,7 +258,7 @@ /choice /attribute /optional -ref name=absFilePath/ +ref name=filePath/
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.l...@citrix.com Date: Fri Jan 9 14:32:18 2015 + 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. bootlaoderpygrub/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. +++ libvirt-1.2.12/docs/schemas/domaincommon.rng2015-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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl and non-absolute paths
On 16.02.2015 10:18, Martin Kletzander wrote: On Fri, Feb 13, 2015 at 03:20:07PM +0100, 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. Not sure whether the libxl driver could query libxl for the path prefix. Right now the most straight forward way seems to move back to a full path for the 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? Maybe stupid question here... How does the string with the prefix look like then? Is it something like bootloaderpygrub:/path/to/loader ? No, sorry I should probably have added that: in both cases there is only the binary name in the config and libxl extends things internally. So bootloaderpygrub/bootloader and loaderhvmloader/loader. -Stefan -Stefan --- libvirt-1.2.12.orig/docs/schemas/domaincommon.rng 2015-01-23 12:46:24. +++ libvirt-1.2.12/docs/schemas/domaincommon.rng2015-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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libxl and non-absolute paths
On Fri, Feb 13, 2015 at 03:20:07PM +0100, 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. Not sure whether the libxl driver could query libxl for the path prefix. Right now the most straight forward way seems to move back to a full path for the 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? Maybe stupid question here... How does the string with the prefix look like then? Is it something like bootloaderpygrub:/path/to/loader ? -Stefan --- libvirt-1.2.12.orig/docs/schemas/domaincommon.rng 2015-01-23 12:46:24. +++ libvirt-1.2.12/docs/schemas/domaincommon.rng2015-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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list pgp_uPbu5fD5M.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libxl and non-absolute paths
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. Not sure whether the libxl driver could query libxl for the path prefix. Right now the most straight forward way seems to move back to a full path for the 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? -Stefan --- libvirt-1.2.12.orig/docs/schemas/domaincommon.rng 2015-01-23 12:46:24. +++ libvirt-1.2.12/docs/schemas/domaincommon.rng2015-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 signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
