[Libguestfs] [PATCH v2] v2v/v2v.ml: Use larger request size for -o rhv-upload

[Richard W.M. Jones]

On Mon, Feb 14, 2022 at 03:59:34PM +0200, Nir Soffer wrote:
> On Mon, Feb 14, 2022 at 3:01 PM Richard W.M. Jones <rjones at redhat.com> wrote:
> >
> > On Mon, Feb 14, 2022 at 12:53:01PM +0100, Laszlo Ersek wrote:
> > > On 02/14/22 10:56, Richard W.M. Jones wrote:
> > > > This change slowed things down (slightly) for me, although the change
> > > > is within the margin of error so it probably made no difference.
> > > >
> > > > Before:
> > > >
> > > > $ time ./run virt-v2v -i disk /var/tmp/fedora-35.qcow2 -o rhv-upload -oc https://ovirt4410/ovirt-engine/api -op /tmp/ovirt-passwd -oo rhv-direct -os ovirt-data -on test14 -of raw
> > > > [   0.0] Setting up the source: -i disk /var/tmp/fedora-35.qcow2
> > > > [   1.0] Opening the source
> > > > [   6.5] Inspecting the source
> > > > [  10.5] Checking for sufficient free disk space in the guest
> > > > [  10.5] Converting Fedora Linux 35 (Thirty Five) to run on KVM
> > > > virt-v2v: warning: /files/boot/grub2/device.map/hd0 references unknown
> > > > device "vda".  You may have to fix this entry manually after conversion.
> > > > virt-v2v: This guest has virtio drivers installed.
> > > > [  57.0] Mapping filesystem data to avoid copying unused and blank areas
> > > > [  59.0] Closing the overlay
> > > > [  59.6] Assigning disks to buses
> > > > [  59.6] Checking if the guest needs BIOS or UEFI to boot
> > > > [  59.6] Setting up the destination: -o rhv-upload -oc https://ovirt4410/ovirt-engine/api -os ovirt-data
> > > > [  79.3] Copying disk 1/1
> > > > █ 100% [****************************************]
> > > > [  89.9] Creating output metadata
> > > > [  94.0] Finishing off
> > > >
> > > > real         1m34.213s
> > > > user         0m6.585s
> > > > sys  0m11.880s
> > > >
> > > >
> > > > After:
> > > >
> > > > $ time ./run virt-v2v -i disk /var/tmp/fedora-35.qcow2 -o rhv-upload -oc https://ovirt4410/ovirt-engine/api -op /tmp/ovirt-passwd -oo rhv-direct -os ovirt-data -on test15 -of raw
> > > > [   0.0] Setting up the source: -i disk /var/tmp/fedora-35.qcow2
> > > > [   1.0] Opening the source
> > > > [   7.4] Inspecting the source
> > > > [  11.7] Checking for sufficient free disk space in the guest
> > > > [  11.7] Converting Fedora Linux 35 (Thirty Five) to run on KVM
> > > > virt-v2v: warning: /files/boot/grub2/device.map/hd0 references unknown
> > > > device "vda".  You may have to fix this entry manually after conversion.
> > > > virt-v2v: This guest has virtio drivers installed.
> > > > [  59.6] Mapping filesystem data to avoid copying unused and blank areas
> > > > [  61.5] Closing the overlay
> > > > [  62.2] Assigning disks to buses
> > > > [  62.2] Checking if the guest needs BIOS or UEFI to boot
> > > > [  62.2] Setting up the destination: -o rhv-upload -oc https://ovirt4410/ovirt-engine/api -os ovirt-data
> > > > [  81.6] Copying disk 1/1
> > > > █ 100% [****************************************]
> > > > [  91.3] Creating output metadata
> > > > [  96.0] Finishing off
> > > >
> > > > real         1m36.275s
> > > > user         0m4.700s
> > > > sys  0m14.070s
> > >
> > > My ACK on Nir's v2 patch basically means that I defer to you on its
> > > review -- I don't have anything against it, but I understand it's
> > > (perhaps a temporary) workaround until we find a more sustainable (and
> > > likely much more complex) solution.
> >
> > Sure, I don't mind taking this as a temporary solution.  The code
> > itself is perfectly fine.  The request size here is essentially an
> > optimization hint, it doesn't affect the architecture.
> >
> > An architectural problem that affects both nbdkit & nbdcopy is that
> > NBD commands drive the nbdkit backend and the nbdcopy loop.  If we
> > make the nbdcopy --request-size larger, NBD commands ask for more
> > data, nbdkit-vddk-plugin makes larger VixDiskLib_ReadAsynch requests,
> > which at some point breaks the VMware server.  (This is fairly easy to
> > solve in nbdkit-vddk-plugin or with a filter.)
> >
> > But nbdcopy needs to be reworked to make the input and output requests
> > separate, so that nbdcopy will coalesce and split blocks as it copies.
> > This is difficult.
> >
> > Another problem I'm finding (eg
> > https://bugzilla.redhat.com/show_bug.cgi?id=2039255#c9) is that
> > performance of new virt-v2v is extremely specific to input and output
> > mode, and hardware and network configurations.  For reasons that I
> > don't fully understand.
> 
> It would be interesting to test this patch in the same environment and see
> how it affects the results.
> 
> Do we see slow down only when using vddk? maybe it is related to the slow
> extent calls?

I was trying as far as possible to test the input and output sides
separately, so I've only tested input from VDDK -> local disk, and
local disk -> rhv-upload before.

Now I am testing end to end because of Ming Xie's reports, but it's
giving me very noisy results at the moment.  Still trying ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top