similar to: [PATCH] rhv-upload: Support qcow2 disks

On Mon, Nov 25, 2019, 11:15 Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Nov 20, 2019 at 03:06:55AM +0200, Nir Soffer wrote: > > diff --git a/v2v/v2v.ml b/v2v/v2v.ml > > index 03590c9e..58bb06c3 100644 > > --- a/v2v/v2v.ml > > +++ b/v2v/v2v.ml > > @@ -739,7 +739,9 @@ and copy_targets cmdline targets input output = > > | TargetURI

On Mon, Nov 25, 2019 at 04:27:11PM +0200, Nir Soffer wrote: > On Mon, Nov 25, 2019, 11:15 Richard W.M. Jones <rjones@redhat.com> wrote: > > > On Wed, Nov 20, 2019 at 03:06:55AM +0200, Nir Soffer wrote: > > > diff --git a/v2v/v2v.ml b/v2v/v2v.ml > > > index 03590c9e..58bb06c3 100644 > > > --- a/v2v/v2v.ml > > > +++ b/v2v/v2v.ml > > >

On Wed, Nov 20, 2019 at 03:06:55AM +0200, Nir Soffer wrote: > diff --git a/v2v/v2v.ml b/v2v/v2v.ml > index 03590c9e..58bb06c3 100644 > --- a/v2v/v2v.ml > +++ b/v2v/v2v.ml > @@ -739,7 +739,9 @@ and copy_targets cmdline targets input output = > | TargetURI uri -> uri in > [ "qemu-img"; "convert" ] @ > (if not (quiet ()) then

When using oVirt >= 4.3, we can enable the NBD based backend in imageio by specifying that we transfer raw data when creating a transfer. With   the NBD backend, we can import to disks using qcow2 format. To make it work, we override output#transfer_format to return always raw format, but we create the disk on RHV side using qcow2 format. The pipeline looks like this: qemu-img convert

Add support for qcow2 disk format, enabled by imageio NBD backend in RHV 4.3. To use this feature manually, you can run virt-v2v with "-of qcow2". Here is example run: Source disk: $ qemu-img info /var/tmp/fedora-30.img image: /var/tmp/fedora-30.img file format: raw virtual size: 6 GiB (6442450944 bytes) disk size: 1.15 GiB virt-v2v: $ ./run virt-v2v \ -v \ -i disk

All the current output modes use the default, It's just that I have a patch that uses this, so there might be someone in the future who wants to use this and if not, then at least you can tell me if this is wrong or not. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/types.ml | 15 +++++++++++++++ v2v/types.mli | 8 +++++++- v2v/v2v.ml | 17 +++-------------- 3

It will be used to do extra checks in the output before copying the disks. Partially revert commit 3bafec4e693a25ef1c84abc0fd1bc3251862c7de. --- v2v/output_glance.ml | 2 +- v2v/output_json.ml | 2 +- v2v/output_libvirt.ml | 2 +- v2v/output_local.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_openstack.ml | 2 +- v2v/output_qemu.ml | 2 +- v2v/output_rhv.ml

We previously implicitly supported writing to block devices instead of local files, but there were several problems: * Block devices could be deleted, especially if virt-v2v failed during a conversion. * Block devices could be overwritten by a file with the same name, although I believe this is just an observed consequence of the previous point, or at least I was not able to reproduce this

PROBLEMS: - Spools to a temporary disk - Need to specify direct/indirect upload via flag - Location of ca.pem - Target cluster - Delete disks on failure, or rename disks on success? - Handling of sparseness in raw format disks This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more

PROBLEMS: - Spools to a temporary disk - Target cluster - Delete disks on failure, or rename disks on success? - Handling of sparseness in raw format disks - Manual page This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not need to go via the

The previous patches seem OK. On a quick glance this one also seems a good start. On Thu, 22 Feb 2018 13:57:25 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > PROBLEMS: > - Spools to a temporary disk > - Need to specify direct/indirect upload via flag > - Location of ca.pem We surely need a new argument for that. When running on VDSM host the certificate

This changes the infrastructure to allow the target_file to be a QEMU URI. Rich.

Factor out copying the overlays to final disk images into a separate function. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 227 +++++++++++++++++++++++++++++++------------------------------ 1 file changed, 114 insertions(+), 113 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index afffde2..703038c 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -110,121 +110,9 @@ let

This way it is possible to override the UUIDs of the uploaded disks, instead of letting RHV generate them. This can be useful to force certain UUIDs, and to specify the disks in --no-copy mode (which now can be used). --- v2v/output_rhv_upload.ml | 43 ++++++++++++++++++++++++++++++++----- v2v/rhv-upload-plugin.py | 2 ++ v2v/virt-v2v-output-rhv.pod | 23 ++++++++++++++++++++ 3 files

PROBLEMS: - Target cluster defaults to "Default". - Using Insecure = True, is that bad? - -of qcow2 does not work, with multiple problems - Need to attach disks to VMs somehow This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not

On 03/08/2018 12:57 PM, Nir Soffer wrote: > On Thu, Mar 8, 2018 at 11:37 AM Richard W.M. Jones <rjones@redhat.com > <mailto:rjones@redhat.com>> wrote: > > PROBLEMS: >  - Target cluster defaults to "Default". >  - Using Insecure = True, is that bad? >  - -of qcow2 does not work, with multiple problems >  - Need to attach disks

"qemu-img convert" detects zeroes in allocated areas and punch holes in the destination image. This may save space on the destination image, but slows down conversion when using outputs such as rhv-upload, which have very large overhead per requests. Using the -S flag, we can treat small areas filled with zeroes as data, limiting the number of requests, and speeding the operation. Here

On Thu, 8 Mar 2018 09:37:19 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > PROBLEMS: > - Target cluster defaults to "Default". > - Using Insecure = True, is that bad? Since you have --rhv-cafile mandatory, there is no reason to set Insecure=True. > - -of qcow2 does not work, with multiple problems > - Need to attach disks to VMs somehow

On Tue, Sep 1, 2020 at 4:56 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > We previously implicitly supported writing to block devices instead of > local files, but there were several problems: > > * Block devices could be deleted, especially if virt-v2v failed during > a conversion. > > * Block devices could be overwritten by a file with the same name, >

On Tue, Sep 01, 2020 at 08:55:38PM +0300, Nir Soffer wrote: ... > > Note this commit intentionally does not prevent you from writing qcow2 > > to a block device. RHV uses this so it is a thing that people do. ... > > +Note that you must create block devices of the correct size, and you > > +need to use I<-of raw> since other output formats would not normally >