Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1356767 - Special characters in VMware cluster and data center name should be handled correctly
Summary: Special characters in VMware cluster and data center name should be handled c...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.6.7
Hardware: All
OS: Linux
high
medium
Target Milestone: ovirt-4.1.0-alpha
: ---
Assignee: Sharon Gratch
QA Contact: Nisim Simsolo
URL:
Whiteboard:
: 1366027 1375707 (view as bug list)
Depends On: 1373863 1416112
Blocks: 1377271
TreeView+ depends on / blocked
 
Reported: 2016-07-15 02:26 UTC by nijin ashok
Modified: 2021-08-30 11:57 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
This update fixes an issue where V2V fails for a VMware external provider which contains special characters in a data center, cluster, or folder name. The characters are now encoded on the V2V engine side before sending them to the VDSM. 1) This solution encodes the VMware data center and VMware cluster parts of the uri. For example, in the URI vpx://user@vcenter/<DATACENTER>/<CLUSTER>/esxi?no_verify=1 the <DATACENTER> and <CLUSTER> parts are encoded, including folders if they exist. Other parts of the URI are left decoded. 2) The UI will display the data center and cluster as was originally typed by the user. 3. The encoding is done on the frontend and should be also done while using REST APIs for VMware V2V. The following special chars are yet not supported: "%", "/", "\", "&", "+", "=", "?"
Clone Of:
: 1377271 (view as bug list)
Environment:
Last Closed: 2017-04-25 00:56:15 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-43187 0 None None None 2021-08-30 11:57:35 UTC
Red Hat Knowledge Base (Solution) 2604231 0 None None None 2016-09-06 08:22:47 UTC
Red Hat Product Errata RHEA-2017:0997 0 normal SHIPPED_LIVE Red Hat Virtualization Manager (ovirt-engine) 4.1 GA 2017-04-18 20:11:26 UTC
oVirt gerrit 63464 0 'None' 'MERGED' 'webadmin: v2v VMware handle special chars in uri' 2019-11-14 09:01:22 UTC
oVirt gerrit 63484 0 'None' 'MERGED' 'webadmin: v2v VMware handle special chars in uri' 2019-11-14 09:01:22 UTC

Description nijin ashok 2016-07-15 02:26:59 UTC 
Description of problem:

VMware allows space in cluster and data center name. For virt-v2v, spaces need to be escaped as %20 in paths . 

RHEV allows adding the Data Center and cluster name with spaces while adding VMware external provider but spaces are not converted to %20 when passing this to virt-v2v.

We can workaround this by adding %20 instead of space from the UI. However if the customer adds a name with space , I think RHEV should automatically convert it into correct URI by replacing space with %20  instead of passing it directly to virt-v2v with incorrect format .


Version-Release number of selected component (if applicable):
rhevm-3.6.7.5-0.1.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. Add a VMware external provider which contains space in Data Center/cluster name


2. This will fails with error

error connection to hypervisor: 'internal error: Unable to parse URI


Actual results:

RHEV is not handling space in cluster/data center name correctly while adding VMware external provider

Expected results:

RHEV should convert the space to correct format for virt-v2v

Additional info:
Comment 1 Michal Skrivanek 2016-07-15 06:11:47 UTC 
(In reply to nijin ashok from comment #0)
> Description of problem:
> 
> VMware allows space in cluster and data center name. For virt-v2v, spaces
> need to be escaped as %20 in paths . 

that would be best addressed in virt-v2v, not RHEV.
Richard, are there any special reasons not to escape spaces in virt-v2v code instead?
Comment 2 Richard W.M. Jones 2016-07-15 09:36:45 UTC 
virt-v2v takes the URI from the command line and passes it straight
to libvirt.

Although we do also parse the URI (using libxml2's xmlParseURI), we
only do that to find out if it's a vpx:// or other URI so we know
which input driver to pass it to.

So there's no good place for this, but I wouldn't be happy for virt-v2v
to start second-guessing the user.  To give another example, virsh doesn't
interpret the input URI (-c option), it also just passes the string
directly to libvirt.

Having said that, IMO the rules for quoting URLs for libvirt's ESX
driver are very under specified.
Comment 3 Michal Skrivanek 2016-07-15 10:54:54 UTC 
(In reply to Richard W.M. Jones from comment #2)
> virt-v2v takes the URI from the command line and passes it straight
> to libvirt.
> Although we do also parse the URI (using libxml2's xmlParseURI), we
> only do that to find out if it's a vpx:// or other URI so we know
> which input driver to pass it to.
> 
> So there's no good place for this, but I wouldn't be happy for virt-v2v
> to start second-guessing the user.  To give another example, virsh doesn't
> interpret the input URI (-c option), it also just passes the string
> directly to libvirt.
> 
> Having said that, IMO the rules for quoting URLs for libvirt's ESX
> driver are very under specified.

IMHO if the whole chain of passing URIs through the various components can't be fixed properly, still the complexity of encoding should be hidden from end users. Now whether you consider virt-v2v command line as the one supposedly designed for end users, or whether we say it's the RHEV UI is arbitrary. Ultimately from RHEV POV it doesn't matter. 
Up to you as a maintainer of libguestfs if you want to tackle it there or not. We can try to push a change to either.
Comment 4 Richard W.M. Jones 2016-07-15 11:00:38 UTC 
Dan - any thoughts?

From the virt-v2v POV I don't even know what escaping or URL
munging we would do.  However I don't think Michal knows either
from the RHEV level :-/
Comment 5 Daniel Berrangé 2016-07-15 11:10:15 UTC 
From the libvirt POV we expect a correctly escaped URI. I don't think that libvirt should be trying to munge the URL passed in the from user to escape spaces before parsing it.  IOW, I think it is RHEVs job to pass a correct URI to virt-v2v, and if users are invoking virt-v2v manually its their responsibility to provide a correctly escaped URI
Comment 7 Tomas Jelinek 2016-07-27 08:09:45 UTC 
We need to make sure that we support all special characters which are supported in vmware
Comment 8 Michal Skrivanek 2016-08-11 06:56:10 UTC 
*** Bug 1366027 has been marked as a duplicate of this bug. ***
Comment 9 Sharon Gratch 2016-09-07 10:16:27 UTC 
Please see Bug 1373863 - libvirt, virt-v2v fail to handle few of the encoded special characters.
Comment 11 Michal Skrivanek 2016-10-12 14:22:21 UTC 
*** Bug 1375707 has been marked as a duplicate of this bug. ***
Comment 13 Nisim Simsolo 2017-03-29 11:26:46 UTC 
Not fixed, depends on bug https://bugzilla.redhat.com/show_bug.cgi?id=1373863
Trying to load VMs when on of these characters (%, /, \,   &, +, =, ?) are in DC, folder or cluster failed with the next vdsm.log error: 
2017-03-28 13:07:23,508+0300 ERROR (jsonrpc/0) [root] error connecting to hypervisor: "internal error: Could not find compute resource specified in '/Folder1/Folder2/Compute3/Folder4/\\/Cluster5/10.35.72.10'" (v2v:183)

spaxe (%20) is working.

Builds verification:
ovirt-engine-4.1.1.6-0.1.el7
vdsm-4.19.10-1.el7ev.x86_64
libvirt-client-2.0.0-10.el7_3.5.x86_64
sanlock-3.4.0-1.el7.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64
virt-v2v-1.32.7-3.el7_3.2.x86_64
Comment 14 Michal Skrivanek 2017-03-29 12:02:30 UTC 
Please specify which characters work and which do not. The current expectation is that " " (space) actually does work
Comment 15 Nisim Simsolo 2017-03-29 14:02:43 UTC 
The next characters work for DC, Folder, Cluster and VM name:
"!", "@". "#", "$", "^", "*", "(", ")", "_", "-", "`", "~", "[", "]", ":", """, "'", ":", ".", "<", ">", ",", " " 
The characters that do not work when one of them included in DC, Folder or Cluster name are:
"%", "/", "\", "&", "+", "=", "?"
Comment 16 Sharon Gratch 2017-03-29 15:32:20 UTC 
(In reply to Nisim Simsolo from comment #15)
> The characters that do not work when one of them included in DC, Folder or
> Cluster name are:
> "%", "/", "\", "&", "+", "=", "?"

Those are the characters failed due to https://bugzilla.redhat.com/show_bug.cgi?id=1373863 (libvirt/v2v issue).

So is it ok if we'll remove depended BZ 1373863 bug from here, 
mark this bug as "VERIFIED" with those chars documented as a limitation for 4.1
and open a new bug targeted to 4.2 that depends on https://bugzilla.redhat.com/show_bug.cgi?id=1373863 instead?
Comment 17 Michal Skrivanek 2017-03-29 16:42:02 UTC 
that's what we agreed on in bug scrub. Space is the only common one and that one works, more complete fix is coming in libvirt
Note You need to log in before you can comment on or make changes to this bug.