similar to: [PATCH] launch: libvirt: Implement drive secrets (RHBZ#1159016).

Since v1: - Base64 decode the Ceph secret before passing it to libvirt. - Don't call virSecretFree (NULL) [libvirt bug?] - Small cleanups.

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

Thanks: Laine Stump, Andrea Bolognani, Marcel Apfelbaum. --- src/guestfs-internal.h | 6 +++--- src/launch-libvirt.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/src/guestfs-internal.h b/src/guestfs-internal.h index d437b9a..428da7f 100644 --- a/src/guestfs-internal.h +++ b/src/guestfs-internal.h @@ -137,17 +137,17 @@ /*

From: "Richard W.M. Jones" <rjones@redhat.com> AAVMF is an open source UEFI implementation for aarch64 based on OVMF. As aarch64 is heading for requiring UEFI even inside guests, if the AAVMF firmware is installed on the host, use it as a hint that we should boot the guest using AAVMF instead of the default "empty machine". Note this requires very recent AAVMF, libvirt,

We've been carrying this exact patch in RHEL 7 for several years. It reverts the change made in 2014 where we switched to using the virbr0 bridge for libguestfs networking instead of SLIRP. We thought SLIRP was going to become unsupported in qemu, but recently there have been more encouraging signs since it looks like SLIRP will be spun off as a separate project, running as a modular process

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

This commit implements some hairy C macros to simplify XML generation. Given the target XML: <cpu mode="host-passthrough"> <model fallback="allow"/> </cpu> The old code would have looked like this: XMLERROR (-1, xmlTextWriterStartElement (xo, BAD_CAST "cpu")); XMLERROR (-1, xmlTextWriterWriteAttribute (xo, BAD_CAST

On Sat, Feb 08, 2020 at 01:25:28AM +0200, Mykola Ivanets wrote: > From: Nikolay Ivanets <stenavin@gmail.com> > > I faced with situation where libguestfs cannot recognize partitions on a > disk image which was partitioned on a system with "4K native" sector > size support. > > In order to fix the issue we need to allow users to specify desired > physical

In some places when generating XML output in C code we use some clever macros: start_element ("memory") { attribute ("unit", "MiB"); string_format ("%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 /

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 +

Previously, is_custom_hv() used to compare the QEMU executable found during configure to the hypervisor set to check whether it is a custom one; however, the QEMU found at configure time can be different than what libvirt was configured with. This fixes the libvirt backend when libguestfs is configured with a different QEMU, that now will be specified as emulator overriding the libvirt one. ---

If the user doesn't specify a format (ie. they want autodetection) then we must do the file format detection ourselves since libvirt disabled this and now doesn't work at all on qcow2 overlays that have no backing_fmt field set. --- src/launch-libvirt.c | 90 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 56 insertions(+), 34 deletions(-) diff --git

From: Nikolay Ivanets <stenavin@gmail.com> I faced with situation where libguestfs cannot recognize partitions on a disk image which was partitioned on a system with "4K native" sector size support. In order to fix the issue we need to allow users to specify desired physical and/or logical block size per drive basis. It is definitely not a complete patch but rather a way to

From: Nikolay Ivanets <stenavin@gmail.com> Nowadays there are hard drives and operating systems which support "4K native" sector size. In this mode physical and logical block size exposed to the operating system is equal to 4096 bytes. GPT partition table (as a known example) being created in this mode will place GPT header at LBA1 which is 4096 bytes. libguetfs is unable to

From: Nikolay Ivanets <stenavin@gmail.com> Nowadays there are hard drives and operating systems which support "4K native" sector size. In this mode physical and logical block size exposed to the operating system is equal to 4096 bytes. GPT partition table (as a known example) being created in this mode will place GPT header at LBA1 which is 4096 bytes. libguetfs is unable to

Previously we had assumed that when running as root, libvirt would always run qemu as a non-root user (eg. qemu.qemu), unless you modify a global configuration file (/etc/libvirt/qemu.conf). It turns out there is a little-known feature to make libvirt run qemu as root without modifying any configuration files. We have to add a <seclabel/> element to the appliance XML: <seclabel

Because of previous automated commits, such as changing 'guestfs___' -> 'guestfs_int_', several function calls no longer lined up with their parameters, and some lines were too long. The bulk of this commit was done using emacs batch mode and the technique described here: http://www.cslab.pepperdine.edu/warford/BatchIndentationEmacs.html The changes suggested by emacs were

Require qemu >= 1.3.0, the first version that supported `qemu-img --output=json'. This means we require yajl (for parsing the JSON output of qemu-img), and that in turn has consequences elsewhere. --- README | 10 +- builder/Makefile.am | 2 - builder/sources.ml | 9 +- builder/yajl-c.c | 30 ----- builder/yajl.ml | 2 - builder/yajl.mli

From: "Richard W.M. Jones" <rjones at redhat.com> You can now add remote NBD drives using: ><fs> add-drive "" format:raw protocol:nbd server:localhost (Note that you also need to add port:NNNN if the server is running on a non-standard port). The corresponding qemu-nbd service can be started by doing: qemu-nbd disk.img -t This commit also adds a test. ---

Thanks: Eric Blake. --- src/Makefile.am | 1 + src/command.c | 7 ++---- src/guestfs-internal.h | 4 +++ src/launch-direct.c | 11 +++------ src/launch-uml.c | 11 +++------ src/umask.c | 10 ++------ src/wait.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 84 insertions(+), 27 deletions(-) create mode 100644