similar to: [PATCH] aarch64: appliance: Use AAVMF (UEFI) if available for running the appliance.

Previously the code had two places where an identical set of AAVMF paths were stored. Put this information into one place. This is just refactoring. --- src/appliance.c | 26 +++++--------------------- src/guestfs-internal-frontend.h | 1 + src/utils.c | 12 ++++++++++++ v2v/utils-c.c | 27 +++++++++++++++++++++++++++ v2v/utils.ml

There were various places in the library where we open coded making temporary filenames. This uses the utility function instead. --- lib/appliance-uefi.c | 4 +++- lib/command.c | 5 +++-- lib/drives.c | 4 +++- lib/inspect-icon.c | 12 +++++++++--- lib/launch-direct.c | 5 ++--- lib/launch-libvirt.c | 5 ++--- lib/launch-uml.c | 5 ++--- 7 files changed, 24

This is only lightly tested. In particularly I only tested that the non-secure-boot path still works. I didn't test it on RHEL 7.3 yet because I haven't got enough free disk space for these giant source *.ova files :-( Will try to give that a go later. Rich.

First version was posted here: https://www.redhat.com/archives/libguestfs/2016-August/thread.html#00100 This is semantically the same as the first version. However I've split the patch up into two parts. In the first part, I factor out the UEFI paths so now they are created by the generator and written in the library and v2v/ directory directly, instead of the complex business of having a C

After the previous commit, wherever we had: start_element ("foo") { string ("bar"); } end_element (); this can now be replaced by: single_element ("foo", "bar"); --- common/utils/libxml2-writer-macros.h | 2 +- lib/launch-libvirt.c | 78 ++++++++-------------------- p2v/physical-xml.c | 15 ++---- 3 files

This QEMU property is specific to x86/x86_64, so add it only on these architectures. --- lib/launch-direct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index bc43dcea2..3b848165c 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -519,8 +519,10 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) arg ("-rtc",

In some places when generating XML output in C code we use some clever macros: start_element ("memory") { attribute ("unit", "MiB"); string ("%d", g->memsize); } end_element (); This commit which is mostly refactoring moves the repeated definitions of these macros into a common header file. I also took this opportunity to change / clean up

On Friday, 2 November 2018 16:05:04 CET Richard W.M. Jones wrote: > diff --git a/common/utils/libxml2-writer-macros.h b/common/utils/libxml2-writer-macros.h > index d74dcd465..a99b245bb 100644 > --- a/common/utils/libxml2-writer-macros.h > +++ b/common/utils/libxml2-writer-macros.h > @@ -86,7 +86,7 @@ > * > * which produces C<<< <name>text</name>

The latter is a better way to disable the qemu display output as we need to, without enabling extra devices (which are disabled already, anyway). Also, related to the change above, ban the -display parameter from the ones that can be supplied by the user. --- configure.ac | 8 ++++---- src/launch-direct.c | 12 ++++++++---- src/launch.c | 1 + 3 files changed, 13 insertions(+), 8

https://bugzilla.redhat.com/show_bug.cgi?id=1338083 Now that UEFI is fully open source the UEFI firmware can be included in Fedora. The location will be slightly different. These patches do a bit of code rearrangement and add the new paths. Rich.

Starting with 5.2.0, libvirt has a way to select the firmware by specifying its type, provided configuration files for the firmware are shipped. Currently we start the appliance as UEFI if any of the firmware are found, so instead we can try to just set the firmware type iff: - the libvirt autoselection works - the 'efi' firmware is available The only behaviour change is that the default

Introduce a new struct version with few helper functions for it: this allows to "atomically" represent a version number, without different variables to be used and checked together. Add a initialization function from a libvirt-style version number, and apply it for the qemu and libvirt versions in the direct and libvirt backends. --- src/Makefile.am | 1 +

In case you configure libguestfs with a custom QEMU, e.g.: $ ./configure [...] QEMU=/path/to/qemu then the libvirt backend did not use to override it, launching the appliance with the default QEMU for libvirt. This does not change the manual emulator overriding using set-hv. Pino Toscano (2): launch: libvirt: get default QEMU from domcapabilities launch: libvirt: fix custom hypervisor

These safe wrappers around Pervasives.open_in and Pervasives.open_out ensure that exceptions escaping cannot leave unclosed files. --- common/mlstdutils/std_utils.ml | 39 ++++++++++++++++++++-------------- common/mlstdutils/std_utils.mli | 12 +++++++++++ common/mltools/tools_utils.ml | 39 +++++++++++++++++----------------- dib/dib.ml | 9 ++++----

libguestfs has used double and triple underscores in identifiers. These aren't valid for global names in C++. (http://stackoverflow.com/a/228797) These large but completely mechanical patches change the illegal identifiers to legal ones. Rich.

v1 -> v2: - Remove the unnecessary calls to guestfs_int_lazy_make_tmpdir in the final patch. Rich.

Miscellaneous small cleanups in lib/ directory. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2018-October/msg00047.html However it was broken in a few ways. First of all the documentation was broken because "/**" enhanced comments were not permitted on macros. This is fixed in the new 1/4 patch. Secondly we didn't use single_element() everywhere possible, which is fixed in the new 4/4 patch. Lastly I've

Currently implemented as guestfish commands, provide them instead as single source -> destination functions for the library, so they can be used also in other places. These functions are not added to guestfish, since guestfish has its own implementation (which will soon switch to call copy-in and copy-out for multiple paths). --- generator/actions.ml | 28 ++++++ po/POTFILES | 1 +

Hi, things are progressing slowly, but I feel that eventually I'll be getting there: supermin can be built on all Linux-based architectures that are part of Debian/unstable[1] -- (except for sparc, but I'll ignore that for now.) libguestfs on the other hand currently fails launching the appliance (necessary for running tests) on everything but x86 and mips. Apparently, qemu-system-arm