[Libguestfs] Performance regression in -o rhv-upload questions

[Richard W.M. Jones]

Hi Nir,

With my version 2 patch, it now takes about the same time to do a
conversion as it did with old virt-v2v.

However one thing I noticed is that we lose about 16 seconds between
creating the disk and creating the transfer.  Notice the timestamps
here:

  00:00:41 python3 '/tmp/v2v.fvLq7Z/rhv-upload-transfer.py' '/tmp/v2v.fvLq7Z/params4.json'
  00:00:41 cannot read /etc/vdsm/vdsm.id, using any host: [Errno 2] No such file or directory: '/etc/vdsm/vdsm.id'
* 00:00:41 disk.id = 'eb30f110-75bb-4a6b-9f21-272392abeb60'
* 00:00:57 transfer.id = 'cde22cf4-7ab7-4e2c-86c8-b6d704987e4a'
  00:00:58 transfer output parsed as: {
  00:00:58   "": {
  00:00:58     "is_ovirt_host": false,
  00:00:58     "destination_url": "https://ovirt4410-host.home.annexia.org:54322/images/3c29aafb-1a90-4c6b-9372-117bdbea288e",
  00:00:58     "transfer_id": "cde22cf4-7ab7-4e2c-86c8-b6d704987e4a"
  00:00:58   }
  00:00:58 }

That corresponds to the two functions create_disk and create_transfer
being called here:

  https://github.com/libguestfs/virt-v2v/blob/18b11018d2c5411693d120add445031758eee5ce/output/rhv-upload-transfer.py#L275

I added some further debug messages and it turns out to be in this
loop, waiting about 16 seconds for the disk to move into the "OK" state:

  https://github.com/libguestfs/virt-v2v/blob/18b11018d2c5411693d120add445031758eee5ce/output/rhv-upload-transfer.py#L132

Why does it take so long and is there something we can do to make it
quicker?

This is 100% reproducible for me.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW