similar to: Re: [PATCH 1/2] launch: add support for autodetection of appliance image format

If you use the libguestfs tools which open disk images read-only (eg. virt-df), with formats such as 'vdi', then you will see an error: error: invalid value for backingformat parameter 'vdi' This is because opening a disk image read-only will try to create a qcow2 file with the original image as a backing file. However the list of permitted backing formats was very restrictive

On Tue, Jun 27, 2017 at 07:42:20PM +0300, Pavel Butsykin wrote: > This feature allows you to use different image formats for the fixed > appliance. The raw format is used by default. I wonder if you're stil using this feature? Unfortunately because of a recent change in libvirt it is no longer possible to have a backing file where libvirt will autodetect the format. See:

Commit 588af1953e5f7ab74009b9175cc5d3efb8bb651a started with a very conservative list of permitted backing formats (just "raw" or "qcow2"). We can allow almost any format permitted by qemu, but this commit just adds "vmdk" to this whitelist. --- src/create.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/create.c b/src/create.c index

When creating the qemu-img command, use the guestfs_int_cmd_add_arg & guestfs_int_cmd_add_arg_format APIs to add the proper filename directly, without creating a string for it. This should cause no functional change. --- lib/create.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/lib/create.c b/lib/create.c index 60e467fb6..fcc5855e0 100644

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

A lot of code runs 'qemu-img create' or 'truncate' to create blank disk images. In the past I resisted adding an API to do this, since it essentially duplicates what you can already do using other tools (ie. qemu-img). However this does simplify calling code quite a lot since qemu-img is somewhat error-prone to use (eg: don't try to create a disk called "foo:bar")

On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > In the guestfs_disk_create API we have traditionally allowed you to > set backingfile without setting backingformat. The meaning of this is > to let qemu autodetect the backing format when opening the overlay > disk. > > However libvirt >= 6.0 refuses to even pass such disks to qemu (see >

On Monday, 9 March 2020 11:40:46 CET Richard W.M. Jones wrote: > On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > > In the guestfs_disk_create API we have traditionally allowed you to > > > set backingfile without setting backingformat. The meaning of this is > > > to let

On Mon, Mar 09, 2020 at 11:19:39AM +0000, Richard W.M. Jones wrote: > On Mon, Mar 09, 2020 at 12:07:08PM +0100, Pino Toscano wrote: > > On Monday, 9 March 2020 11:40:46 CET Richard W.M. Jones wrote: > > > On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > > > > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > > > > In

In the guestfs_disk_create API we have traditionally allowed you to set backingfile without setting backingformat. The meaning of this is to let qemu autodetect the backing format when opening the overlay disk. However libvirt >= 6.0 refuses to even pass such disks to qemu (see https://bugzilla.redhat.com/show_bug.cgi?id=1798148). For this reason, move the autodetection earlier and make it

On Mon, Mar 09, 2020 at 12:07:08PM +0100, Pino Toscano wrote: > On Monday, 9 March 2020 11:40:46 CET Richard W.M. Jones wrote: > > On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > > > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > > > In the guestfs_disk_create API we have traditionally allowed you to > > > > set

On Mon, Mar 09, 2020 at 11:07:20AM +0100, Pino Toscano wrote: > On Thursday, 6 February 2020 18:20:19 CET Richard W.M. Jones wrote: > > In the guestfs_disk_create API we have traditionally allowed you to > > set backingfile without setting backingformat. The meaning of this is > > to let qemu autodetect the backing format when opening the overlay > > disk. > >

This is just code refactoring. --- src/launch.c | 172 +++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 109 insertions(+), 63 deletions(-) diff --git a/src/launch.c b/src/launch.c index 46d7ab9..84d5e82 100644 --- a/src/launch.c +++ b/src/launch.c @@ -293,9 +293,7 @@ guestfs_impl_config (guestfs_h *g, #endif #if defined(__aarch64__) -#define EARLYPRINTK "

The main purpose of this change is two-fold: (1) Ensure that we run the same version of qemu-img that we are built against. (2) Allow the qemu-img path to be overridden at build time in case it's on a nonstandard path or (like RHV) has a nonstandard name. --- docs/guestfs-building.pod | 6 ++++++ lib/command.c | 4 ++-- lib/create.c | 4 ++-- lib/info.c

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

See http://rwmj.wordpress.com/2014/11/23/mapping-files-to-disk/

For raw, this allows "off" as a synonym for "sparse" (to make it consistent with qcow2). For qcow2, this allows "sparse" as a synonym for "off". It also adds qcow2 "full" preallocation, which is actually mapped to the qemu option "falloc" (see arguments about this on the qemu-devel mailing list, which we lost). This also updates the

Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1), so stop forcing compat=0.10 for these targets. Thanks: Yaniv Kaul, Michal Skrivanek. --- v2v/output_rhev.ml | 4 ----

Only in end-user messages and documentation. This change was done mostly mechanically using the Perl script attached below. I also changed don't -> don’t etc and made some other simple fixes. See also: https://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html ---------- #!/usr/bin/perl -w use strict; use Locale::PO; my $re = qr{'([-\w%.,=?*/]+)'}; my %files = (); foreach my $filename

When listing the subvolumes of a btrfs filesystem, ignore the default subvolume: we get the content of it when mounting the whole device (without specifying any particular subvolume), so avoid listing it twice. --- src/listfs.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/listfs.c b/src/listfs.c index 98e74c7..de3b6f5 100644 --- a/src/listfs.c +++ b/src/listfs.c @@ -169,8