Created attachment 1455230 [details] punycode_automation.log Description of problem: This is extended version of BZ1588555, I tried to migrate vm with vmname `ytale-v2v-ubuntu-nfs-punycode-джум-ññ` and it failed to migrate. Version-Release number of selected component (if applicable): master.20180625230012_9b5c751 How reproducible: 100% Steps to Reproduce: 1. Try to migrate vm with punycode characters in their name (Infra mapping was normal, for datastores I used nfs at source and nfs at target, I don't think it is matter of datastore) Actual results: Error while migrating vm Expected results: VM name with punycode characters should also be get migrated Additional info: Automation.log attached.
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