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

We now have true zeroing support in oVirt imageio, thanks for that. However a problem is that ‘qemu-img convert’ issues zero requests for the whole disk before starting the transfer. It does this using 32 MB requests which take approx. 1 second each to execute on the oVirt side. Two problems therefore: (1) Zeroing the disk can take a long time (eg. 40 GB is approx. 20 minutes). Furthermore there is no progress indication while this is happening. Nothing bad happens: because it is making frequent requests there is no timeout. (2) I suspect that because we don't have trim support that this is actually causing the disk to get fully allocated on the target. The NBD requests are sent with may_trim=1 so we could turn these into trim requests, but obviously cannot do that while there is no trim support. Note that this is (sort of) a regression over previous versions of the ‘-o rhv-upload’ patch since the old code ignored some zero requests. I'm not sure what to do about this. Possibly we could fix the progress bar issue in qemu. It's also possible we could do something in nbdkit such as having is signal back that "stuff is being done" and turn that into some indication in virt-v2v. Anyway it's something to be aware of, in case you try out the forthcoming virt-v2v rhvpreview and it appears to sit at 0/100% "doing nothing" for a long time. 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