Bug 1356767
| Summary: | Special characters in VMware cluster and data center name should be handled correctly | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | nijin ashok <nashok> | |
| Component: | ovirt-engine | Assignee: | Sharon Gratch <sgratch> | |
| Status: | CLOSED ERRATA | QA Contact: | Nisim Simsolo <nsimsolo> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | 3.6.7 | CC: | berrange, bgraveno, dornelas, gklein, jhunsaker, lsurette, mgoldboi, michal.skrivanek, nsimsolo, rbalakri, Rhev-m-bugs, rjones, srevivo, tjelinek, ykaul | |
| Target Milestone: | ovirt-4.1.0-alpha | Keywords: | ZStream | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| 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:
"%", "/", "\", "&", "+", "=", "?"
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1377271 (view as bug list) | Environment: | ||
| Last Closed: | 2017-04-25 00:56:15 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1373863, 1416112 | |||
| Bug Blocks: | 1377271 | |||
|
Description
nijin ashok
2016-07-15 02:26:59 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? 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 |