This is a complicated story.

If you don't pass a username in the vpx:// URI, then:

(1) libvirt asks you for a username, defaulting to "administrator":

Enter username for 10.66.7.125 [administrator]: 
Enter administrator's password for 10.66.7.125: 

(2) virt-v2v calls curl which will use a default username, which I
believe is your Unix login name.

Unfortunately we cannot get at the result of (1) in order to pass
it to (2).

So the only way around this is to specify the username in the
URL, ie. use vpx://administrator@[...]

I have pushed a commit to 1.27.44 which will change the error message
so it tells you to put the username into the URL.  That, I think, is
the best I can do here.

Tested with:
virt-v2v-1.27.45-1.1.el7.x86_64
libguestfs-1.27.45-1.1.el7.x86_64

# virt-v2v -ic vpx://10.66.7.125/tzheng-test/10.66.71.84/?no_verify=1 esx5.1-clone-test -v -x
[   0.0] Opening the source -i libvirt -ic vpx://10.66.7.125/tzheng-test/10.66.71.84/?no_verify=1 esx5.1-clone-test
Enter username for 10.66.7.125 [administrator]: 
Enter administrator's password for 10.66.7.125: 
virt-v2v: error: access: No such file or directory: [esx5.1] 
esx5.0-clone-test/esx5.0-clone-test.vmdk

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]
libvirt xml is:
<domain type='vmware'>
  <name>esx5.1-clone-test</name>
  <uuid>4239f0bc-fcf3-223b-9512-c95e8e7ab744</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <cputune>
    <shares>1000</shares>
  </cputune>
  <os>
    <type arch='i686'>hvm</type>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <source file='[esx5.1] esx5.0-clone-test/esx5.0-clone-test.vmdk'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='scsi' index='0' model='vmpvscsi'/>
    <interface type='bridge'>
      <mac address='00:50:56:b9:26:3d'/>
      <source bridge='VM Network'/>
      <model type='vmxnet3'/>
    </interface>
    <video>
      <model type='vmvga' vram='8192'/>
    </video>
  </devices>
</domain>

(In reply to tingting zheng from comment #4)
> Tested with:
> virt-v2v-1.27.45-1.1.el7.x86_64
> libguestfs-1.27.45-1.1.el7.x86_64
> 
> # virt-v2v -ic vpx://10.66.7.125/tzheng-test/10.66.71.84/?no_verify=1
> esx5.1-clone-test -v -x
> [   0.0] Opening the source -i libvirt -ic
> vpx://10.66.7.125/tzheng-test/10.66.71.84/?no_verify=1 esx5.1-clone-test
> Enter username for 10.66.7.125 [administrator]: 
> Enter administrator's password for 10.66.7.125: 
> virt-v2v: error: access: No such file or directory: [esx5.1] 
> esx5.0-clone-test/esx5.0-clone-test.vmdk

Remote disk support is completely broken in 1.27.45.  See:

https://bugzilla.redhat.com/show_bug.cgi?id=1141654#c2

Tested with:
libguestfs-1.27.46-1.1.el7.x86_64
virt-v2v-1.27.46-1.1.el7.x86_64
libvirt-1.2.8-2.el7.x86_64

1.# virt-v2v -ic vpx://10.66.7.125/tzheng-test/10.66.71.84/?no_verify=1 dvs
[   0.0] Opening the source -i libvirt -ic vpx://10.66.7.125/tzheng-test/10.66.71.84/?no_verify=1 dvs
Enter username for 10.66.7.125 [administrator]: 
Enter administrator's password for 10.66.7.125: 
curl -s --insecure -I 'https://10.66.7.125/folder/dvs/dvs-flat.vmdk?dcPath=tzheng-test&dsName=datastore1' ||:
HTTP/1.1 401 Unauthorized
Date: Fri, 16 May 2014 12:14:05 GMT
Set-Cookie: vmware_soap_session="52a8ed97-6882-4809-2931-1b54adaee860"; Path=/; HttpOnly; 
Connection: close
WWW-Authenticate: Basic realm="VMware HTTP server"
Content-Length: 0

virt-v2v: error: esx: incorrect username or password.  You might need to 
specify the username in the URI like this: vpx://USERNAME@[etc]

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

Error info shows to tell me to put the username into the URL,then put username in URL try again:
2.# virt-v2v -ic vpx://administrator.7.125/tzheng-test/10.66.71.84/?no_verify=1 dvs
[   0.0] Opening the source -i libvirt -ic vpx://administrator.7.125/tzheng-test/10.66.71.84/?no_verify=1 dvs
Enter administrator's password for 10.66.7.125: 
Enter host password for user 'administrator':
[  52.0] Creating an overlay to protect the source from being modified
[  52.0] Opening the overlay
[  76.0] Initializing the target -o libvirt -os default
[  76.0] Inspecting the overlay
[ 156.0] Checking for sufficient free disk space in the guest
[ 156.0] Estimating space required on target for each disk
[ 156.0] Converting Red Hat Enterprise Linux Server release 6.4 (Santiago) to run on KVM
[ 776.0] Mapping filesystem data to avoid copying unused and blank areas
[ 782.0] Closing the overlay
[ 782.0] Copying disk 1/1 to /var/lib/libvirt/images/dvs-sda (raw)

In step 2,I need to input the password twice,is it a problem?

(In reply to tingting zheng from comment #6)
> In step 2,I need to input the password twice,is it a problem?

Yes, that's unfortunately necessary.  It is mentioned in the manual:

       Note that you may be asked for the vCenter password twice.  This
       happens once because libvirt needs it, and a second time because
       virt-v2v itself connects directly to the server.

(In reply to Richard W.M. Jones from comment #7)
> (In reply to tingting zheng from comment #6)
> > In step 2,I need to input the password twice,is it a problem?
> 
> Yes, that's unfortunately necessary.  It is mentioned in the manual:
> 
>        Note that you may be asked for the vCenter password twice.  This
>        happens once because libvirt needs it, and a second time because
>        virt-v2v itself connects directly to the server.

Yes,I saw it from virt-v2v manual,refer to comment 6 and comment 7,move the bug to VERIFIED.

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