[Libguestfs] [Qemu-block] v2v: -o rhv-upload: Long time spent zeroing the disk

[Richard W.M. Jones]

On Tue, Apr 10, 2018 at 09:52:40AM -0500, Eric Blake wrote:
> Didn't Rich already try to do that?
> 
> +def emulate_zero(h, count, offset):
> +    # qemu-img convert starts by trying to zero/trim the whole device.
> +    # Since we've just created a new disk it's safe to ignore these
> +    # requests as long as they are smaller than the highest write seen.
> +    # After that we must emulate them with writes.
> +    if offset+count < h['highestwrite']:
> 
> Or is the problem that emulate_zero() is only being called if:
> 
> +    # Unlike the trim and flush calls, there is no 'can_zero' method
> +    # so nbdkit could call this even if the server doesn't support
> +    # zeroing.  If this is the case we must emulate.
> +    if not h['can_zero']:
> +        emulate_zero(h, count, offset)
> +        return
> 
> rather than doing the 'highestwrite' check unconditionally even when
> oVirt supports zero requests?

Exactly.

I'm not sure it's always safe to call emulate_zero, as I'm not sure
that we always know that the remote oVirt device starts off empty.

Well in one case it's definitely not true: when we created the disk
with disk_format = types.DiskFormat.COW (qcow2).  However I have
currently disabled conversion to qcow2 in this plugin for other
reasons.  (And I think that imageio shouldn't in any case be exposing
the qcow2 format like this -- the APIs are operating at the wrong
level.  The format should be hidden by the imageio APIs and it should
expose only read/write operations on a logically raw device.)

Rich.

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