similar to: [PATCH 0/2] libvirt: fix check of custom QEMU

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

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. ---

These patches contain the beginnings of discard (a.k.a. trim or unmap) support. This will allow us to change virt-sparsify to work on disk images in-place (instead of using slow & inefficient copying). The approach used is to add an optional 'discard' parameter to add-drive. It has 3 possible settings: - 'disable' : the default, no discard is done - 'besteffort' :

On some architectures a certain machine type is used, so use it when querying the libvirt domain capabilities. --- lib/launch-libvirt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c index 864eae314..f2cad9300 100644 --- a/lib/launch-libvirt.c +++ b/lib/launch-libvirt.c @@ -431,7 +431,12 @@ launch_libvirt (guestfs_h *g, void

v1 was here: https://www.redhat.com/archives/libguestfs/2018-October/msg00047.html v2 was here: https://www.redhat.com/archives/libguestfs/2018-October/msg00051.html v3: - Back to using string/string_format and attribute/attribute_format. - Add both single_element and single_element_format. - Rebased and retested. 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

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

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>

Consolidate and extend the use of funky start_element() etc macros. Rich.

In version 2: - No substantial change, I just tidied up the code a bit. - Removed one case where whitespace changes had crept in. Rich.

Error out early if the path to the socket will not fit into sockaddr_un::sun_path, as we will not be able to connect to it. --- src/launch-unix.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/launch-unix.c b/src/launch-unix.c index 740c554..973e14b 100644 --- a/src/launch-unix.c +++ b/src/launch-unix.c @@ -47,6 +47,12 @@ launch_unix (guestfs_h *g, void *datav, const char

Use AS_CASE to properly map from the host cpu to the qemu cpu suffix; this avoids doing multiple string replacements using sed, and it is possible to use case-like syntax. --- configure.ac | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/configure.ac b/configure.ac index a571de5..75dfb37 100644 --- a/configure.ac +++ b/configure.ac @@ -755,15 +755,13 @@

Link to version 1: https://www.redhat.com/archives/libguestfs/2013-February/thread.html#00122 Changes since version 1: - I've pushed two (of the three) code refactoring patches. The third one proved rather hard to move. - selinuxnorelabel option is no more. Instead there is a second internal API (internal_set_libvirt_selinux_norelabel_disks). - fixed bogus commit message -

Hi, Debian calls qemu-kvm kvm so we should check for that one too. Please apply. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Debian-calls-qemu-kvm-kvm.patch Type: text/x-diff Size: 899 bytes Desc: not available URL: <http://listman.redhat.com/archives/libguestfs/attachments/20101105/f7ccb908/attachment.bin>

https://bugzilla.redhat.com/show_bug.cgi?id=912499 (especially comments 7 & 10) This patch set is the final fix so that we can access disks in use by other guests when SELinux and sVirt are enabled. Previously such disks were inaccessible because sVirt labels the disks with a random SELinux label to prevent other instances of qemu from being able to read them. So naturally the libguestfs

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.

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

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

This is tangentially related to: https://bugzilla.redhat.com/show_bug.cgi?id=1372668 The problem in that bug is that we didn't pass the source CPU model (Sandybridge in that case) through to the target RHV hypervisor. So when the Windows guest booted on the target it gives an error about CPU hardware being disconnected (although it otherwise boots and works fine). This patch series

Simple fix for this assert-fail found in: https://bugzilla.redhat.com/show_bug.cgi?id=1370424 Rich.