similar to: [PATCH] lib: Autodetect backing format and specify it explicitly.

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

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

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

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

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

On Fri, Jun 23, 2017 at 04:12:35PM +0300, Pavel Butsykin wrote: > This feature allows you to use different image formats for the fixed > appliance. The raw format is used by default. > > Signed-off-by: Pavel Butsykin <pbutsykin@virtuozzo.com> > --- > lib/create.c | 5 +++-- > lib/guestfs-internal.h | 2 ++ > lib/launch-direct.c | 2 ++ >

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

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

I have scoured the web and can't find anything on the topic: Is IPv6 supported for remote image targets? For example: guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 Does not work citing the following: libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: create: flags = 0, handle = 0x5560231bdfb0, program =

Unfortunately I do need to use the address explicitly as opposed to hostnames because the source of the data fed here is Ceph's monmap which returns the addresses explicitly. I've tried all the common ways to escape the : in the v6 address to no avail.  I definitely agree that the problem looks to be it parsing the colons as if the port comes next and then everything after that is

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

This worked wonderfully!  What are the odds of getting this upstream in the near future?  I'd rather not build from source in production. # ./run guestfish --format=raw --ro -a rbd://[fd00::cefc:1]:6789/images/CentOS-7-x86_64-GenericCloud-1901 libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_tmpdir "/root/libguestfs/tmp" libguestfs:

I believe the bug lies in libguestfs. Taking out the commands being sent to QEMU and using qemu-img info I can recreate the error: # qemu-img info "rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none" qemu-img: Could not open 'rbd:images/CentOS-7-x86_64-GenericCloud-1901:mon_host=[fd00::cefc:1]\:6789:auth_supported=none': invalid

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

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

v3: Change the flag from --vdsm-compat-11 to --vdsm-compat=1.1 Also the --machine-readable output has changed. I have also added a test. Rich.