Bug 1596143
Summary: | [v2v] vm name with punycode international characters fails while migration | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat CloudForms Management Engine | Reporter: | Yadnyawalk Tale <ytale> | ||||||
Component: | UI - OPS | Assignee: | Brett Thurber <bthurber> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Yadnyawalk Tale <ytale> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 5.9.0 | CC: | cpelland, hkataria, kkulkarn, lavenel, mpovolny, obarenbo, rjones, simaishi, smallamp, tgolembi, ytale | ||||||
Target Milestone: | GA | ||||||||
Target Release: | 5.10.0 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | v2v | ||||||||
Fixed In Version: | 5.10.0.11 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2019-02-07 23:03:14 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: | |||||||||
Attachments: |
|
Description
Yadnyawalk Tale
2018-06-28 10:12:59 UTC
Please attach migration.log Created attachment 1455376 [details]
migration.log
Found in 5.9.3.3 What's interesting is that virt-v2v is up and running. It appears that the wrapper is reading the logs from virt-v2v and the wrapper hits the parse error noted by KK. Does the wrapper or Python expect that the output of virt-v2v (especially debugging output) is always going to contain valid UTF-8? I'm afraid that's not a valid assumption. Debug messages will print all kinds of internal strings, and some of these won't be well-formed UTF-8 (or necessarily any encoding). This has been fixed in wrapper and will be available in next build Fixed in wrapper. Build: ovirt-ansible-v2v-conversion-host-1.6.0-1.el7ev @Ytale can you verify with 4.2.6 preview? Created attachment 1474668 [details] success_5.9.4.3.png @Brett, checked on 4.6.2's appliance (assuming comment #11 as a typo). Used vm name `ytale-v2v-طدЩыǪἀ-джум-简体中文-日本語-pê-añ-ça` with following requirements. cfme: 5.9.4.3.20180808144238_a20955a vcenter: 6.5 rhvm: 4.2.5.2-0.1.el7ev wrapper: ovirt-ansible-v2v-conversion-host-1.5.0-1.el7ev.noarch Able to to migrate vm successfully. (In reply to Yadnyawalk Tale from comment #12) > wrapper: ovirt-ansible-v2v-conversion-host-1.5.0-1.el7ev.noarch > > Able to to migrate vm successfully. This is rather intersting. Fixed wrapper is in version 1.6.0. Ok, I realized why it did work. There are two different potential issues at play here. 1) the VM name contains special characters 2) the disk path of the disk in VM contains special characters Normally, the disk paths are based on VM name so the two issues may seamingly become one issues. But they are really two different problems. To my knowledge 1) was never a problem with the wrapper, but the 2) caused the migration to fail in wrapper. Also, 2) has that fix in 1.6.0 and is tracked by bug 1581739. I'm not sure whether this particular bug should be about 1) or 2) or both... you decide. Fixed! Vm name with internationalization characters (punycodes) works well with patch. Verified with: Wrapper - ovirt-ansible-v2v-conversion-host-1.6.3-1.el7ev CFME - 5.10.0.17.20180927011235_1b5cf54 vSphere - 6.7.0 RHV - 4.2.6.4-0.1.el7ev This issue was intentionally opened for punycode thing and not for special characters. I did checked special characters thing while checking punycode and it failed. More info related to special char will be on https://github.com/ManageIQ/manageiq-v2v/issues/477 https://bugzilla.redhat.com/show_bug.cgi?id=1598088 Thanks! Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:0212 |