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:
(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?
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.
(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.
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 :-/
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
We need to make sure that we support all special characters which are supported in vmware
*** Bug 1366027 has been marked as a duplicate of this bug. ***
Please see Bug 1373863 - libvirt, virt-v2v fail to handle few of the encoded special characters.
*** Bug 1375707 has been marked as a duplicate of this bug. ***
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
Please specify which characters work and which do not. The current expectation is that " " (space) actually does work
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: "%", "/", "\", "&", "+", "=", "?"
(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?
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