RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1250715 - v2v: spaces need to be escaped as %20 in paths
Summary: v2v: spaces need to be escaped as %20 in paths
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2015-08-05 19:52 UTC by Alessandro
Modified: 2015-10-27 20:58 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-27 17:54:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1158526 0 unspecified CLOSED Use password file instead of process interaction 2021-02-22 00:41:40 UTC

Description Alessandro 2015-08-05 19:52:14 UTC
Description of problem:
[root@localhost ~]# virt-v2v -ic vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1 -os virtimages vmname --password-file /tmp/passwd
[   0.0] Opening the source -i libvirt -ic vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1 la-qa-auto02
libvirt: ESX Driver error : internal error: HTTP response code 500 for call to 'Login'. Fault: ServerFaultCode - Login failed due to a bad username or password.
virt-v2v: error: internal error: invalid argument: cannot open libvirt 
connection 
' vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1'

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

  virt-v2v -v -x [...]
  
  
Password file created as follows:
echo -n password > /tmp/password

same usarname and password for both vCenter Server and ESX host is used.

Version-Release number of selected component (if applicable):
1.28.1-1.48.el7.x86_64

How reproducible:


Steps to Reproduce:
1. Prepare a file including esx server password:
# echo -n password > /tmp/password 

2. Use virt-v2v convert a guest from esx server:
[root@localhost ~]# virt-v2v -ic vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1 -os virtimages vmname --password-file /tmp/passwd
[   0.0] Opening the source -i libvirt -ic vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1 la-qa-auto02
libvirt: ESX Driver error : internal error: HTTP response code 500 for call to 'Login'. Fault: ServerFaultCode - Login failed due to a bad username or password.
virt-v2v: error: internal error: invalid argument: cannot open libvirt 
connection 
' vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1'

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

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

Actual results:
Failed with error 
libvirt: ESX Driver error : internal error: HTTP response code 500 for call to 'Login'. Fault: ServerFaultCode - Login failed due to a bad username or password.

Expected results:
Conversion successfully and boot up with no error.

Additional info:

Comment 1 Richard W.M. Jones 2015-08-05 20:16:26 UTC
> ServerFaultCode - Login failed due to a bad username or password.

It looks like you've got the wrong username or password.  Try the
tests in the manual.

http://libguestfs.org/virt-v2v.1.html#vcenter:-test-libvirt-connection-to-vcenter

Also make sure you don't have $http_proxy or $https_proxy set.

Comment 2 Alessandro 2015-08-05 20:42:27 UTC
Richard,
thank you for your quick answer.

I am trying the tests to connect to my vCenter but I have an obstacle. My vCenter has an ESX Cluster name that contains a space in it, example:
vpx://root@vCenter/Datacenter/Name Cluster/ESX3.5/?no_verify=1

I of course get this error:
error: unknown command: 'Cluster/ESX3.5/?no_verify=1'

How do I go around this?

Plus, when I use the following command:

virt-v2v -ic vpx://root@vcenterserver/Datacenter/ESX3.5/?no_verify=1

Does this require me to use same usarname and password for both vCenter and ESX hosts?
What if I use two different accounts to login in vCenter and ESX?

Thanks!

Comment 3 Richard W.M. Jones 2015-08-06 07:28:45 UTC
First of all you need to test this using the commands
described here:

http://libguestfs.org/virt-v2v.1.html#vcenter:-test-libvirt-connection-to-vcenter

For the space, try replacing it with %20

You only need to authenticate with vCenter.  vCenter itself talks
to ESX and there is no separate authentication for that.

Comment 4 Alessandro 2015-08-06 15:52:21 UTC
Thank you Richard!

The %20 value solved my issue.

Result after applying the %20 value:
virt-v2v -ic vpx://root@vcenterserver/Cluste%20Name/ESX3.5/?no_verify=1 -os pool VMName

[root@localhost ~]# virt-v2v -ic vpx://root@vcenterserver/Cluste%20Name/ESX3.5/?no_verify=1 -os virtimages VMName
[   0.0] Opening the source -i libvirt -ic vpx://root@vcenterserver/Cluste%20Name/ESX3.5/?no_verify=1 -os virtimages VMName
Enter root's password for la-dev-vc.elitecorp.com: 
Enter host password for user 'root':
[  25.0] Creating an overlay to protect the source from being modified
[  26.0] Opening the overlay
[ 119.0] Initializing the target -o libvirt -os pool
[ 119.0] Inspecting the overlay

Thanks!

Comment 5 Richard W.M. Jones 2015-08-06 16:31:23 UTC
Documentation updated to note use of escape sequences in paths:

https://github.com/libguestfs/libguestfs/commit/068443843db8a08d2d4a3e0f4e393f7e223311ae

Comment 6 Alessandro 2015-10-22 21:33:11 UTC
Having the same issue on a different vCenter Server environment.
This vCenter Server hosts a vCloud Director solution and has the same problem with spaces in Datacenter Name but differently than the other environment it has some more logical folders that contain ESXi Clusters.
vCenter Server version is also different. This one is a 5.5 version instead of 2.5. Compatibility issue perhaps?
Following the command ran followed by error code returned.

[root@CENTOS7 ~]# virsh -c vpx://USERNAME@vCenterServerName/Data%20Center%20Name/Logical%20Folder/ESXiCluster/ESXiHostName/?no_verify=1 list --all
Enter USERNAME's password for vCenterServerName: 
error: failed to connect to the hypervisor
error: internal error: HTTP response code 500 for call to 'Login'. Fault: ServerFaultCode - Cannot complete login due to an incorrect user name or password.

Also, tried the same command by not specifying the Logical%20Folder in the path. Same problem occurs.

Privileges are level Administrator and SSH service on ESXi is on.

Any idea/guide on how to get an higher level of debug?

Many Thanks!!

Comment 7 Richard W.M. Jones 2015-10-23 07:56:06 UTC
Which version of libvirt is this?

Comment 8 Alessandro 2015-10-23 15:02:56 UTC
[root@CENTOS7 ~]# virsh --version=long
Virsh command line tool of libvirt 1.2.17
See web site at http://libvirt.org/

Compiled with support for:
 Hypervisors: QEMU/KVM LXC ESX Test
 Networking: Remote Network Bridging Interface netcf Nwfilter VirtualPort
 Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM RBD Gluster
 Miscellaneous: Daemon Nodedev SELinux Secrets Debug DTrace Readline Modular

Comment 9 Richard W.M. Jones 2015-10-23 15:34:34 UTC
Can you do:
    rpm -qf /usr/bin/virsh
We need to know if it's RHEL, Fedora, etc. and the precise package version.

This is obviously a bug in libvirt however since presumably libvirt
should be able to access any VCenter resource, whether or not the
name contains spaces.  So in addition to getting the precise version
number, do:

LIBVIRT_DEBUG=1 virsh -c 'vpx://[long URL ...]' list --all

and attach the complete output from that.  Also is the problem
with the folder name containing a space?

Comment 12 Alessandro 2015-10-23 22:45:51 UTC
Just to add a more detailed info regarding the vCenter Inventory structure, the view I have used to build the ESXi path is the "Hosts and Clusters".

So, when I refer to "Logical Folder" I refer to the yellow folder in the vCenter Inventory and not the blue kind.

I have also tried by running the command without the folder included in the path, like in the following example.

vpx://USERNAME@vCenterServerName/Data%20Center%20Name/ESXiCluster/ESXiHostName/?no_verify=1 list --all

Thanks!

Comment 14 Richard W.M. Jones 2015-10-27 08:49:20 UTC
VCenter is still saying its a problem with the username or password.  The
error is:

  Cannot complete login due to an incorrect user name or password.

I will see if I can reproduce this later on today.

Comment 15 zhoujunqin 2015-10-27 09:10:42 UTC
I cannot reproduce this issue with following package:
libvirt-1.2.17-13.el7.x86_64
libvirt-client-1.2.17-13.el7.x86_64
libguestfs-1.28.1-1.55.el7.x86_64
virt-v2v-1.28.1-1.55.el7.x86_64

steps:
1. My esx5.5 setting with some spaces in name:


  v2v-vcenter
     -> Datacenter(my is called "tzheng demo test")
        -> Folder(called "logical folder")
           -> Cluster(called "cluster test")
             -> vmware [ESXi node]

2. Run virsh command:
#  virsh -c vpx://root.4.103/tzheng%20demo%20test/logical%20folder/cluster%20test/10.66.106.63/?no_verify=1
Enter root's password for 10.66.4.103: 
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # 

Result: spaces were escaped as %20 in paths successfully and i can login with right username and password.

And i also tried with only spaces contains in Datacenter path, it's always successfully.

So Alessandro, please help have a look of my step, is there any difference with yours, thanks.

Comment 16 Richard W.M. Jones 2015-10-27 12:58:15 UTC
I wasn't able to reproduce this either:

$ virsh -c 'vpx://root.annexia.org/My%20Folder/My%20Datacenter/vmware.home.annexia.org?no_verify=1' list --all
Enter root's password for v2v-vcenter.home.annexia.org: 
 Id    Name                           State
----------------------------------------------------
[etc]

I still think you've probably just got the username or password wrong.

Comment 17 Alessandro 2015-10-27 14:31:22 UTC
Hello Richard,
Thank you for your quick response on this.
I am sure 100% that my username and password are correct. I can access our vCenter environment using both vSphere Client and RDP on the Windows OS that hosts the vCenter Server application.

The only thing I can think of is that when I access our vCenter I have to use a Domain Account, so DOMAIN\USERNAME. 
With the other environment I am able to access without specifying be DOMAIN instead but still using a Domain account.

I've tried by writing DOMAIN\USERNAME@vCenterServerName when using both virsh and virt-v2v but the tool sees it as DOMAINUSERNAME and of course it fails.

I have tried to look for a specific syntax to use when using domain accounts but I couldn't find it. Is there anything I'm missing?

Thank you!

Comment 18 Richard W.M. Jones 2015-10-27 14:36:09 UTC
I'm not able to test anything using Windows domains.  You need to
be careful about quoting the -c parameter to protect it from the
shell, ie. always do:

  virsh -c 'vpx://.....' list --all

That's almost certainly the reason why the \ was "ignored", because
the shell ate it before virsh/libvirt even saw it.

Comment 19 Alessandro 2015-10-27 14:38:57 UTC
So even though you cannot test this do you think that could be the reason why I'm not able to access? Should I use a local user on the Windows machine instead?

Comment 20 Richard W.M. Jones 2015-10-27 14:41:48 UTC
As with all bugs, try to reduce the number of variables until you get
down to a single variable that causes the test to pass/fail when changed.
In this case, I would suggest trying a local user, and seeing if
you can replicate Junqin or my results (comment 15, comment 16).

Comment 21 Alessandro 2015-10-27 14:48:08 UTC
Ok will do. 
Could I also try by quoting the whole command?
Like the following?

virsh -c 'vpx://DOMAIN\USERNAME@vCenterServerName/Data%20Center%20Name/Logical%20Folder/Cluster%20Name/ESXiName?no_verify=1' list --all

I will give you an update as soon as possible.

Thanks!

Comment 22 Alessandro 2015-10-27 17:22:46 UTC
I have just tested the command by escaping the "\" with \\ and this is the result:

[root@CENTOS7 ~]# virsh -c vpx://DOMAIN\\USERNAME@vCenterServerName/Data%20Center%20Name/Logical%20Folder/Cluster/ESXiName/?no_verify=1 list --all
error: failed to connect to the hypervisor
error: internal error: Unable to parse URI vpx://DOMAIN\USERNAME@vCenterServerName//Data%20Center%20Name/Logical%20Folder/Cluster/ESXiName/?no_verify=1

The URI looks right but we still have the issue.

Before I go ahead and request a local account, any idea on this?

Thanks!

Comment 23 Richard W.M. Jones 2015-10-27 17:35:58 UTC
You have to escape \ as %5c.  See the manual:
http://libguestfs.org/virt-v2v.1.html#vcenter:-uri

Comment 24 Alessandro 2015-10-27 17:44:43 UTC
Richard,
I tried that but I have mistaken and used C instead of c.
This solved my issue!

Following the results:
[root@CENTOS7 ~]# virsh -c vpx://DOMAIN%5cUSERNAME@vCenterServerName//Data%20Center%20Name/Logical%20Folder/Cluster/ESXiName/?no_verify=1 list --all
Enter DOMAIN\USERNAME's password for vCenterServerName: 
 Id    Name                           State
----------------------------------------------------
 [etc]
 
[root@CENTOS7 ~]# 

Thank you all for your help!

Comment 25 Richard W.M. Jones 2015-10-27 17:54:28 UTC
Closing per comment 24.


Note You need to log in before you can comment on or make changes to this bug.