VMware Cloud Community
charlin
Contributor
Contributor

domain\user fomat in ovftool.exe command cause string misinterpretation

Hi VMWare experts,

I am having problem with automation script because the string passed in the ovftool command uses credential vsphere.local\userXYZ instead of just userXYZ.  

It appears that the backsplash in the 'vsphere.local\user' cause the command line to be misinterpreted, so the automation script that calls ovftool to deploy VMs kept failing.  It erred with "cURL error of ‘couldn’t resolve hostname" even though there is nothing wrong with any hosts or hostname resolution on the network.

On a Win-based vCenter I was able to reconfigure it so that instead of requiring login user format of 'vsphere.local\userXYZ', it will now accept user = 'userXYZ'. 

With that change, ovftool.exe command string is now progress correctly and VMs are deployed.   I could do that on Window-based vCenter, but I could not set up vApp vCenter to use just 'userXYZ'.

The string segment in the long ovftool.exe command line looked like this …

This works:

"vi://userXYZ:password@tm-vcenter55/DC2-SJ/host/Topology/csg-sj-esxi112.cisco.com"

This does not work:

"vi://vsphere.local\userXYZ:password@lin-vcenter55/DC2-SJ/host/Topology/csg-sj-esxi111.cisco.com"

Is there anyway to configure vCenter Virtual Appliance to use log in format of user = userXYZ instead of user = vsphere.local\userXYZ?   Or is there some way of reformatting the string so that OS can interpret it correctly even with backsplash '\' is used in the string?

Thank you

Charles

The complete ovftool.exe command is shown below:

"C:\Program Files\VMware\VMware OVF Tool\ovftool.exe" --acceptAllEulas --skipManifestCheck --diskMode=thin --name=linsys2-vm1 --deploymentOption

=vm_typeA --datastore=EMC-LUN1 --net:"Network Adapter 1"="VLAN 410 - 172.27.14.0/24" --net:"Network Adapter 2"="VLAN 410 - 172.27.14.0/24" --vmFold

er=   --prop:cisco_hostname.Proj=linsys2-vm1 --prop:cisco_ip_0.Proj=172.27.14.135 --prop:cisco_dnsDomain.Proj=cisco.com --prop:cisco_netmask_0.Proj=255.255.255.0 --prop:cisco_gateway_0.Proj=172.27.14.1 --prop:cisco_dns1_0.Proj=172.27.200.199 --prop:cisco_dns2_0.Proj=173.36.131.10 --prop:cisco_language.Proj=English v:\ova\projectX_1.0.0.ova "vi://vsphere.local\userXYZ:password@lin-vcenter55/DC2-SJ/host/Topology/csg-sj-esxi111.cisco.com"

Opening OVA source: v:\ova\projectX_1.0.0.ova

The manifest does not validate

Error: cURL error: Couldn't resolve host name

Completed with errors

Installation Done!

Tags (2)
0 Kudos
1 Reply
mhay
Contributor
Contributor

In case you are still needing this (and to document another workaround) I had to find a way around this as well and I did not have any access to mess with the user accounts.

What I did was to use this form for the user name - uName@domain.com this worked.  See example Below

PS C:\Program Files\VMware\VMware OVF Tool> .\ovftool.exe --X:logFile=deploy.log --X:logLevel=verbose --disableVerification --noSSLVerify -ds=dataStore -n=vmName C:\packer-vmware-iso.ovf vi://<IPAddress>/DataCenter/host/esxhost.domain.com

Opening OVF source: C:\packer-vmware-iso.ovf

The manifest validates

Enter login information for target vi://<IPAddress>/

Username: uName@domain.com

Password: ***********

Opening VI target: vi://uName%40domain.com@<IPAddress>:443/DataCenter/host/esxhost.domain.com

Deploying to VI: vi://uName%40domain.com@<IPAddress>:443/DataCenter/host/esxhost.domain.com

Transfer Completed

Completed successfully

Note the '%40' chars in the lines following the authentication.  This led me to realize that the '@' char in the user name needed to be encoded.  Then I could pass the user name and pwd in the command like this:

PS C:\Program Files\VMware\VMware OVF Tool> .\ovftool.exe --X:logFile=deploy.log --X:logLevel=verbose --disableVerification --noSSLVerify -ds=dataStore -n=vmName C:\packer-vmware-iso.ovf vi://uName%40domain.com:PWD<IPAddress>/DataCenter/host/esxhost.domain.com

BOOM.  This worked.  Finally.