Bug 1669240
Summary: | [v2v][OSP][RHV]Migrating over SSH transformation method with names containing spaces such as `rhel 7`, fails to migrate | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat CloudForms Management Engine | Reporter: | Kedar Kulkarni <kkulkarn> | ||||||
Component: | V2V | Assignee: | Fabien Dupont <fdupont> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Shveta <sshveta> | ||||||
Severity: | medium | Docs Contact: | Red Hat CloudForms Documentation <cloudforms-docs> | ||||||
Priority: | high | ||||||||
Version: | 5.10.0 | CC: | bthurber, dmetzger, fdupont, jprause, kkulkarn, maufart, pvauter, rjones, simaishi, sshveta, tgolembi, ytale | ||||||
Target Milestone: | GA | Keywords: | TestOnly, ZStream | ||||||
Target Release: | 5.11.z | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | v2v | ||||||||
Fixed In Version: | 5.11.0.1 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 1678385 (view as bug list) | Environment: | |||||||
Last Closed: | 2020-03-18 08:06:26 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | Bug | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | V2V | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 1727275 | ||||||||
Bug Blocks: | 910269, 1668816, 1678385 | ||||||||
Attachments: |
|
Created attachment 1523257 [details]
virt-v2v-logs
This applies to the VMs with Spaces in name as well. [ 4.9] Opening the source -i vmx ssh://root.58.30/vmfs/volumes/env-vcenter67-ims-iscsi-netapp-rdu-01b/rhel7 kk/rhel7 kk.vmx virt-v2v: error: remote vmx ‘ssh://root.58.30/vmfs/volumes/env-vcenter67-ims-iscsi-netapp-rdu-01b/rhel7 kk/rhel7 kk.vmx’ could not be parsed as a URI IMHO this is different issue from what we saw in bug 1661913. CFME will need to properly encode the unicode characters in URI. I wonder if this broken for RHV too or it just works differently there. This is broken for RHV as well. Exactly in same way. As Tomas said, this is a bug in whatever creates that URL. You have to pass a valid URL, eg. by %-escaping any characters. To quote from the manual: http://libguestfs.org/virt-v2v.1.html#vmx:-construct-the-ssh-uri | VMX: Construct the SSH URI | | When using the SSH input transport you must specify a remote ssh://... | URI pointing to the VMX file. A typical URI looks like: | | ssh://root.com/vmfs/volumes/datastore1/my%20guest/my%20guest.vmx | | Any space must be escaped with %20 and other non-ASCII characters may also need to be URI-escaped. For Unicode codepoints you must convert them to UTF-8 and percent encode the bytes. @Tomas, @Richard, should we also encode other options such as RHV Cluster name, RHV storage domain name and OpenStack project name ? (In reply to Fabien Dupont from comment #15) > @Tomas, @Richard, should we also encode other options such as RHV Cluster > name, RHV storage domain name and OpenStack project name ? No, only the URI. Other fields should stay in Unicode (and be encoded only by JSON writer). *** Bug 1669286 has been marked as a duplicate of this bug. *** (In reply to Fabien Dupont from comment #15) > @Tomas, @Richard, should we also encode other options such as RHV Cluster > name, RHV storage domain name and OpenStack project name ? As Tomas says. I would also say let's address other problems if they arise. However more testing is always helpful - I encourage everyone to create the weirdest named storage domains / OS projects etc etc :-) Verification blocked by infra ssh issue ... investigating it. Vm's with space and international chars in name are not displayed in VM list in migration plan . Is this expected ? Are you checking against RHV or OpenStack ? For RHV, it's normal because RHV doesn't support spaces or international chars for VM names. It's for RHV . Not able to verify for OSP because of https://bugzilla.redhat.com/show_bug.cgi?id=1727275 Checked on OSP , The plan does not filter (or makes the VM unselectable) the VM's with name containing space or international chars. Appliance : https://10.16.5.88 5.11.0.19.20190813184334_ed72c9f. Can we filter these VM's for OSP too just like RHV . We discussed on another BZ earlier that OSP does not support international chars https://bugzilla.redhat.com/show_bug.cgi?id=1678385#c18. Hence atleast VM's with international chars in name should be filtered out . Migration failing with space in VM name which is tracked here https://bugzilla.redhat.com/show_bug.cgi?id=1685948 The initial error was that international characters would make virt-v2v fail. OpenStack DOES SUPPORT international characters, so we don't filter out VMs with international characters in their name. The validation here is to run a migration of a VM with international characters in its name from VMware to OSP over SSH. Note virt-v2v has an ‘-on’ option which allows you to rename the VM during conversion. Tomas reminded us that there's a BZ about international characters in OSP: https://bugzilla.redhat.com/show_bug.cgi?id=1661913. It's fixed in RHOSP 15. In the current code, we don't check the provider version. We could propose another PR to adjust the validation rules for OSP. We don't have a RHOSP environment in our lab, so we'll depend only on QE for testing. Moving back to ON_DEV. Closing as it is implemented in CFME 5.11.4 and we won't backport to 5.10. |
Created attachment 1523256 [details] virt-v2v-wrapper-log Description of problem: Migrating to OSP over SSH transformation method with names containing international chars, such as `�Ää`, fails with : [ 3.5] Opening the source -i vmx ssh://root.58.29/vmfs/volumes/env-esxi67-ims-h01_localdisk/�Ää/�Ää.vmx virt-v2v: error: remote vmx ‘ssh://root.58.29/vmfs/volumes/env-esxi67-ims-h01_localdisk/�Ää/�Ää.vmx’ could not be parsed as a URI Version-Release number of selected component (if applicable): CFME - 5.10.0.32.20190115185124_c957ada ovirt-ansible-v2v-conversion-host-1.9.1-2.el7ev.noarch OSP - 14 (qe's baremetal) How reproducible: 100% Steps to Reproduce: 1. Migrate vm with SSH transformation method. Actual results: Vm name getting change Expected results: Should give original vm name