To reproduce the curl download from VMware:

(1) List guests in your vCenter server in the usual way:

$ virsh -c 'vpx://v2v-vcenter/Datacenter/avon.home.annexia.org?no_verify=1' list
--all
Enter username for v2v-vcenter [administrator]: root
Enter root's password for v2v-vcenter:
 Id    Name                           State
----------------------------------------------------
 14    VMware vCenter Server Appliance running
 -     Fedora 20                      shut off
 -     Windows 2003                   shut off

(2) Dump out the XML from one guest:

$ virsh -c 'vpx://v2v-vcenter/Datacenter/avon.home.annexia.org?no_verify=1'
dumpxml "Fedora 20"

and have a look for the disk which will be something like:

    <disk type='file' device='disk'>
      <source file='[datastore1] Fedora 20/Fedora 20.vmdk'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

(3) You then have to map the <source file='..'> attribute to the path
that VMware uses (virt-v2v normally does this internally).

That path maps to (including the literal spaces):

  https://root:vmware@v2v-vcenter.home.annexia.org/folder/Fedora 20/Fedora 20-fl
at.vmdk?dcPath=Datacenter&dsName=datastore1

  root                          username
  vmware                        password
  v2v-center.home.annexia.org   vCenter server
  /folder/Fedora 20/Fedora 20   path
  -flat.vmdk                    selects on-the-fly conversion to raw
  ?dcPath=...&dsName=...        select datacenter and datastore

(4) Construct a curl command.  You have to turn spaces into '%20':

  time curl -k --verbose -o /dev/null 'https://root:vmware@v2v-vcenter.home.anne
xia.org/folder/Fedora%2020/Fedora%2020-flat.vmdk?dcPath=Datacenter&dsName=datast
ore1'

For me, two machines back-to-back through a gigabit ethernet switch,
that gets 25 M bytes/sec, or about 1/4 of line speed.

To reproduce the very slow case (qemu-img convert):

qemu-img create \
  -b 'json: {
      "file.driver":"https",
      "file.url":"https://root:vmware@v2v-vcenter.home.annexia.org/folder/Fedora
%2020/Fedora%2020-flat.vmdk?dcPath=Datacenter&dsName=datastore1",
      "file.timeout":60,
      "file.sslverify":"off",
      "file.cookie":"vmware_soap_session=\"5229d1b5-79d8-8a0f-6584-a035cc30829d\
"" }' \
  -f qcow2 test1.qcow2

[You will have to fish out the cookie from the previous curl command
in step (4)]

  time qemu-img convert test1.qcow2 -O raw test2.qcow2 -p

To reproduce qemu block/curl over loopback (very fast):

(1) Test http (ie. non-encrypted).

(1a) Put a 10 GB sparse file onto a webserver.  I have the web server
and my client on the same machine, because I'm really interested in
just qemu's speed, not the speed of the network.

$ truncate -s 10G test10G.img

(1b) Create a qcow2 file backed by the "remote" http image:

$ qemu-img create -b http://localhost/~rjones/test10G.img -f qcow2 test1.qcow2
Formatting 'test1.qcow2', fmt=qcow2 size=10737418240
backing_file='http://localhost/~rjones/test10G.img' encryption=off
cluster_size=65536 lazy_refcounts=off

(1c) Time copying it:

$ time qemu-img convert test1.qcow2 -O raw test2.qcow2
real   0m29.835s
user   0m6.580s
sys    0m11.599s

(I repeated the test a few times, but the times were pretty stable).

Note that it writes a sparse test2.qcow2 file, so the test is pure
qemu, not involving local disk access.

(1d) Copying speed: 360 MBytes/sec

(2) Test https (ie. encrypted).

(2a) I installed mod_ssl and restarted Apache.

(2b) Create a qcow2 file backed by the https image:

$ qemu-img create -b 'json: { "file.driver": "https", "file.url":
"https://localhost/~rjones/test10G.img", "file.sslverify": "off" }' -f qcow2
test1.qcow2
Formatting 'test1.qcow2', fmt=qcow2 size=10737418240 backing_file='json: {
"file.driver": "https", "file.url": "https://localhost/~rjones/test10G.img",
"file.sslverify": "off" }' encryption=off cluster_size=65536 lazy_refcounts=off

(2c) Time copying it:

$ time qemu-img convert test1.qcow2 -O raw test2.qcow2
real   0m49.386s
user   0m23.221s
sys    0m15.362s

(2d) Copying speed: 217 MBytes/sec

The slow speed is actually more like 600 K Bytes/sec once I remembered to
turn off my http proxy.  However it's still much too slow.

Created attachment 945325 [details]
log.txt

Log with curl debugging enabled during a copy.

There some odd things, like the fact that it requests multiple
overlapping ranges from the server.

1412862216.919256018 E: Range: bytes=0-2359295
1412862217.226955599 E: < Content-Range: bytes 0-2359295/17179869184
1412862217.968930662 E: Range: bytes=2097152-4456447
1412862218.420325479 E: < Content-Range: bytes 2097152-4456447/17179869184
1412862219.198377569 E: Range: bytes=4194304-6553599
1412862219.629430877 E: < Content-Range: bytes 4194304-6553599/17179869184
1412862220.390077086 E: Range: bytes=6291456-8650751
1412862220.927107323 E: < Content-Range: bytes 6291456-8650751/17179869184
1412862221.683293921 E: Range: bytes=8388608-10747903
1412862221.935254111 E: < Content-Range: bytes 8388608-10747903/17179869184
1412862222.763005606 E: Range: bytes=10485760-12845055
1412862223.067524402 E: < Content-Range: bytes 10485760-12845055/17179869184
1412862223.834612981 E: Range: bytes=12582912-14942207
1412862224.228208632 E: < Content-Range: bytes 12582912-14942207/17179869184

It opens 3 https connections, and does not appear to be reconnecting,
which is all good.

The general problem seems to be that the vCenter server is simply slow
at handling range requests.

So we fixed this by increasing the readahead window.  This lets
us achieve ~ 22 M Bytes/second, which is close enough to the straight
download speed supported by vCenter (about 25 M Bytes/sec).

Upstream fix:

https://github.com/libguestfs/libguestfs/commit/88a381b2a065e0447281eb3ca7a215b3855c98b0

Included in virt-v2v >= 1.27.62.

Unfortunately fixing this has caused a regression (bug 1153589).

For the resolution see:
https://bugzilla.redhat.com/show_bug.cgi?id=1153589#c8

(In reply to Richard W.M. Jones from comment #9)
> For the resolution see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1153589#c8

That was incomplete.  Further fixes are needed:

https://bugzilla.redhat.com/show_bug.cgi?id=1153589#c14

Try to verify with package:
virt-v2v-1.28.1-1.5.el7.x86_64
libguestfs-1.28.1-1.5.el7.x86_64

steps:
Env: esx5.5 with vcenter5.5
# virt-v2v -ic vpx://root.111.25/tzheng-demo/10.66.106.63/?no_verify=1 test-rhel6 
[   0.0] Opening the source -i libvirt -ic vpx://root.111.25/tzheng-demo/10.66.106.63/?no_verify=1 test-rhel6
Enter root's password for 10.66.111.25: 
Enter host password for user 'root':
[  33.0] Creating an overlay to protect the source from being modified
[  34.0] Opening the overlay
[  42.0] Initializing the target -o libvirt -os default
[  42.0] Inspecting the overlay
[  90.0] Checking for sufficient free disk space in the guest
[  90.0] Estimating space required on target for each disk
[  90.0] Converting Red Hat Enterprise Linux Server release 6.4 (Santiago) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 432.0] Mapping filesystem data to avoid copying unused and blank areas
[ 433.0] Closing the overlay
[ 433.0] Copying disk 1/1 to /var/lib/libvirt/images/test-rhel6-sda (raw)
    (100.00/100%)
[ 558.0] Creating output metadata
Pool default refreshed

Domain test-rhel6 defined from /tmp/v2vlibvirt8cf4b5.xml

[ 559.0] Finishing off

Result: Conversion finished successfully and speed is ok, guest can boot up successfully.
So move this bug from ON_QA to VERIFIED.

Try to verify again as bug described:
libguestfs-1.28.1-1.6.el7.x86_64
virt-v2v-1.28.1-1.6.el7.x86_64

(1) List guests in your vCenter server in the usual way:
# virsh -c vpx://root.111.25/tzheng-demo/10.66.106.63/?no_verify=1  list --all
Enter root's password for 10.66.111.25: 
 Id    Name                           State
----------------------------------------------------
 35    vcenter5.5                     running
 42    atomic-rhel-internal-1027      running
 -     atomic-vmware                  shut off
 -     test-rhel6                     shut off
 -     test-win2008                   shut off
 -     test-win2008r2                 shut off
 -     test-win7-x86_64               shut off

(2) Dump out the XML from one guest:
...
    <disk type='file' device='disk'>
      <source file='[datastore1] test-rhel6/test-rhel6.vmdk'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
...
(3)Construct a curl command.
# time curl -k --verbose -o /dev/sdb1  'https://root:'VCENTER2014redhat'@10.66.111.25/folder/test-rhel6/test-rhel6-flat.vmdk?dcPath=tzheng-demo&dsName=datastore1' 
* About to connect() to 10.66.111.25 port 443 (#0)
*   Trying 10.66.111.25...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 10.66.111.25 (10.66.111.25) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
* 	subject: OID.1.2.840.113549.1.9.2="1403757657,d2d56f0e,564d7761726520496e632e",CN=unused,E=ssl-certificates,OU=VMware vCenter Server Certificate,O="VMware, Inc.",L=Palo Alto,ST=California,C=US
* 	start date: Jun 25 04:40:57 2014 GMT
* 	expire date: Jun 23 04:40:58 2024 GMT
* 	common name: unused
* 	issuer: E=ssl-certificates,CN=unused CA 3a186651,O="VMware, Inc.",L=Palo Alto,ST=California,C=US
* Server auth using Basic with user 'root'
> GET /folder/test-rhel6/test-rhel6-flat.vmdk?dcPath=tzheng-demo&dsName=datastore1 HTTP/1.1
> Authorization: Basic cm9vdDpWQ0VOVEVSMjAxNHJlZGhhdA==
> User-Agent: curl/7.29.0
> Host: 10.66.111.25
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Oct 2014 07:23:39 GMT
< Set-Cookie: vmware_soap_session="52f011aa-c4ce-5b34-edbd-a55cd28e213d"; Path=/; HttpOnly; Secure; 
< Accept-Ranges: bytes
< Connection: Keep-Alive
< Content-Type: application/octet-stream
< Content-Length: 8589934592
< 
{ [data not shown]
100 8192M  100 8192M    0     0  22.1M      0  0:06:09  0:06:09 --:--:-- 19.2M
* Connection #0 to host 10.66.111.25 left intact

real	6m9.395s
user	1m35.823s
sys	0m16.795s

The average download speed is around 20M/bps, and i think it's also depends on the internet condition.

so rjones, please help me have a look, by the way, the conversion speed on your said is ok now, thanks.

What is the aim of the test in comment 13?

My local VMware vCenter was able to deliver about 25 M Bytes/sec download
when using curl directly, connected back-to-back to another machine through
gigabit ethernet.

(In reply to Richard W.M. Jones from comment #14)
> What is the aim of the test in comment 13?
> 
Thanks for you quick reply.
After commit Comment 12, I want to use you way to test to make sure the problem is fixed, so do Comment 13 things, do you think it's enough to verify this bug with Comment 12, thanks.

I've just tested conversion of a esx windows guest,in the log the speed shows as:
virtual copying rate: 435.8 M bits/sec
real copying rate: 155.6 M bits/sec
sda: estimate 16106127360 (15.0G) versus actual 5750861824 (5.4G): 180.1%

(In reply to tingting zheng from comment #16)
> I've just tested conversion of a esx windows guest,in the log the speed
> shows as:
> virtual copying rate: 435.8 M bits/sec
> real copying rate: 155.6 M bits/sec

This is about 19 M bytes/sec which is objectively horrible, but it's
roughly what we expect from VMware (I used to see 20-22 M bytes/sec,
before the hard disk failed in my ESXi hypervisor).

> sda: estimate 16106127360 (15.0G) versus actual 5750861824 (5.4G): 180.1%

This estimate is not great either, but the estimates only matter
for RHEV conversions, and even there they only matter so that RHEV
can provision enough space before the conversion starts.  As long
as estimate >= actual, we're good.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0303.html