Bug 1616385

Summary: virt-v2v Fails with IMS when Using AD Credentials for VMware Provider
Product: Red Hat CloudForms Management Engine Reporter: Chris Keller <ckeller>
Component: AutomateAssignee: Greg McCullough <gmccullo>
Status: CLOSED CURRENTRELEASE QA Contact: Kedar Kulkarni <kkulkarn>
Severity: high Docs Contact:
Priority: high    
Version: 5.9.3CC: bthurber, ckeller, fdupont, hkataria, lavenel, mkanoor, mpovolny, obarenbo, simaishi, smallamp, tfitzger
Target Milestone: GAKeywords: TestOnly, ZStream
Target Release: 5.10.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.10.0.12 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1623557 (view as bug list) Environment:
Last Closed: 2019-02-12 16:53:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1619668, 1623557    

Description Chris Keller 2018-08-15 18:50:56 UTC 
Description of problem:

When performing a VM migration from VMware to RHV using IMS, the migration fails when the VMware provider is configured with credentials that contain a backslash (i.e. AD credentials in the format DOMAIN\USER).


Version-Release number of selected component (if applicable):

5.9.3
Also has hotfix [1] applied, but should not be applicable to this bug.


How reproducible:

Every time. Replacing credentials with a local account in vCenter that does not contain a backslash resolves the issue.


Steps to Reproduce:

1. Follow BETA docs to setup IMS
2. Create migration plan and execute migration


Actual results:

Migration results in an error (sensitive customer information removed):

virt-v2v: error: could not parse '-ic 
vpx://ADDOMAIN\ADUSER/Path/to/hypervisor.local?no_verify=1'. 
 Original error message was: parse_uri: unable to parse URI
rm -rf '/var/tmp/null.5vuux2'


Expected results:

Successful VM migration.


Additional info:

virt-v2v documentation [2] states:

"If the username contains a backslash (eg. DOMAIN\USER) then you will need to URI-escape that character using %5c: DOMAIN%5cUSER (5c is the hexadecimal ASCII code for backslash.) Other punctuation may also have to be escaped."

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1614470
[2] - http://libguestfs.org/virt-v2v.1.html
Comment 2 Fabien Dupont 2018-08-20 06:24:48 UTC 
@Chris, we plan to use esx:// URIs and connect directly to the ESXi hosts because vCenter is a bottleneck. In your experience, have you seen customers using AD authentication for the hosts ? Also, do you think they would push back using root user anyway ?
Comment 3 Chris Keller 2018-08-20 16:13:47 UTC 
@Fabien, in my experience SSH is usually disabled on ESXi hosts and AD authentication is not enabled. However, it is easy to enable both of these and VMware has plenty of documentation to support. Most VMware administrators are receptive to enabling SSH but there is ALWAYS push back when we ask to use root.

Adding the ability to use a service account in AD for vCenter & ESXi along with documentation on required permissions would be very beneficial. I would also consider the use of a service account as a best practice because several security standards (e.g. DISA STIG, ISO-27001, NIST) mandate the use of unique accounts for auditing purposes.
Comment 4 Fabien Dupont 2018-08-20 16:29:10 UTC 
@Chris, we don't use SSH, simply connection to ESXi API. It is still using root user, as this is the only local account available.
Comment 5 Chris Keller 2018-08-20 17:15:33 UTC 
@Fabien, in that case it is easy to add AD authentication [1] to ESXi. I would assume adding AD authentication would cover the API as well, but am not sure.

[1] - https://kb.vmware.com/s/article/2075361
Comment 6 Fabien Dupont 2018-08-21 12:28:35 UTC 
Associated PR: https://github.com/ManageIQ/manageiq-content/pull/407
Comment 7 Fabien Dupont 2018-08-21 16:44:34 UTC 
PR merged. Moving to POST.
Comment 9 Kedar Kulkarni 2018-10-02 16:04:13 UTC 
With 5.10.0.17 I was able to get the migration to work when my ESXi host was authenticated using active directory, username of format ADDOMAIN\ADUSer
and migration was successful.