Libguestfs - Jul 2021 - Commit "v2v: Remove -o rhv-upload -oa preallocated"

For some reason I did not see this change in the mailing list:
https://github.com/libguestfs/virt-v2v/commit/18084f90d9dd9092831cb3487039328981796291

The commit message claims:
> Using -oa preallocated with -o rhv-upload always gave an error.  We
> should be able to implement this properly in modular virt-v2v, but as
> this option did nothing here remove it to simplify things.
But I used -oa preallocated and -oa sparse and it worked fine after removing
the unhelpful validation, and using:

   sparse=params["output_sparse"]

The code was already broken even before this change with block storage domain
(iSCSI/FC) and raw format (the default), since raw-sparse is not supported in
block base storage, but now there is no way to fix the code.

We can always use qcow2-sparse - this combination is most useful in RHV
but using raw preallocated volume can give better performance or reliability
and this is still the default format for block storage RHV.

Since RHV does not support the feature of selecting the image format and
allocation policy for the user, and does not make the available combinations
or the system defaults available via the API, virt-v2v must pass the decision
to the user of the program.

Nir

On Sat, Jul 03, 2021 at 04:34:09PM +0300, Nir Soffer
wrote:
> For some reason I did not see this change in the mailing list:
>
https://github.com/libguestfs/virt-v2v/commit/18084f90d9dd9092831cb3487039328981796291
I didn't post it ...  However the commit on its own is correct because
-oa preallocated was rejected with an error.  But see below because I
do intend to add the feature back (unbroken).
> The commit message claims:
> 
> > Using -oa preallocated with -o rhv-upload always gave an error.  We
> > should be able to implement this properly in modular virt-v2v, but as
> > this option did nothing here remove it to simplify things.
> 
> But I used -oa preallocated and -oa sparse and it worked fine after
removing
> the unhelpful validation, and using:
> 
>    sparse=params["output_sparse"]
> 
> The code was already broken even before this change with block storage
domain
> (iSCSI/FC) and raw format (the default), since raw-sparse is not supported
in
> block base storage, but now there is no way to fix the code.
> 
> We can always use qcow2-sparse - this combination is most useful in RHV
> but using raw preallocated volume can give better performance or
reliability
> and this is still the default format for block storage RHV.
> 
> Since RHV does not support the feature of selecting the image format and
> allocation policy for the user, and does not make the available
combinations
> or the system defaults available via the API, virt-v2v must pass the
decision
> to the user of the program.
In modular virt-v2v[1] we will be using nbdcopy to copy to a disk
pipeline.

For rhv-upload it will actually make no difference.  It will work the
same as current code, ie. nbdkit + python + rhv-upload-plugin.

However I was actually thinking we could get nbdcopy to use the
nbdcopy --allocated flag, essentially pushing zeroes (or hopefully
NBD_CMD_WRITE_ZEROES commands not actual zeroes) through the pipeline.
Now I think about it a bit more this seems like it's going to be
somewhat inefficient as far as imageio is concerned.

We can certainly put the -oa flag back again, passing it through
params["output_sparse"].  How does it fail if we select the wrong
combination? - can we check it in precheck?  Will there ever be a way
of querying what combinations are supported?

Rich.

[1] https://github.com/rwmjones/virt-v2v/tree/2021-virt-v2v-split

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html