Bug 1685948

https://github.com/ManageIQ/manageiq/pull/18528

https://github.com/ManageIQ/manageiq/pull/18536

Moving to 5.10.6 because 5.10.5 focuses on conversion host management UI.

@Brett, waiting on review.

Vm's with space and international characters (�Ääú) in name are filtered out from RHEV.

Hi Fabien , Is this expected? 
Vm's (with space and international chars) are not displayed in VM list in migration plan

For RHV, it's normal because RHV doesn't support spaces or international chars for VM names. That's precisely the purpose of this BZ.
We don't make the VM unselectable, we simply filter them out.

Not able to verify the BZ 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

That's because they are supported in OpenStack. OpenStack doesn't support non-printable characters, and to be honest, I don't know how to create a VM with non-printable characters in its name.

Created attachment 1605905 [details]
wrapper log

Hi Fabien , 
Can you please check the attached logs .
Both space and international chars VM fails on OSP .

Created attachment 1605906 [details]
Migration log


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 .

What I said in https://bugzilla.redhat.com/show_bug.cgi?id=1678385#c18 is that the filter we had at that time filtered out international characters for both RHV and OSP.
OpenStack supports international characters, so this BZ implements a different filter for RHV and OSP VMs:

 - RHV doesn't support spaces and international characters (https://github.com/ManageIQ/manageiq/blob/master/app/models/transformation_mapping/vm_migration_validator.rb#L144-L147)
 - OSP doesn't support non-printable characters (https://github.com/ManageIQ/manageiq/blob/master/app/models/transformation_mapping/vm_migration_validator.rb#L149-L152)

If you look at the virt-v2v log, you can see that the error is not related to VM name: "virt-v2v: error: ‘-io vddk-libdir=/opt/vmware-vix-disklib-distrib’ does not point to a directory.".
I would guess that the conversion host is not properly configured.

Moving it back to ON_QA.

Created attachment 1606239 [details]
log for international chars vm with OSP

Ok created a plan (plan_international) with international chars VM (�Äã).
Plan failed with error : "56:be:64:5b', '--enable', u'\ufffd\xc4\xe3_port_0', '--security-group', u'224a6f1b-465e-458b-9170-a7216643f4f2'], environment: {} (virt-v2v-wrapper:1769)
2019-08-20 15:21:50,396:ERROR: Command exited with non-zero return code 1, output:
'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)"


Appliance : https://10.16.5.91
Plan: plan_international

Plan with space in VM name worked but got stuck at refresh inventory state which is tracked in separate BZ .
But I think we are good with this test case ( VM with space in name on OSP)

appliance : https://10.16.5.91/migration#/plan/2

Thanks @shveta. It seems that the command to arguments passed to virt-v2v were valid unicode characters. We can see them in virt-v2v log and virt-v2v succeeded.
As you wrote, in virt-v2v-wrapper log, the command to create the network port fails. @Tomas, do you think it's the way virt-v2v-wrapper uses the string ?

This is a bug in openstack see bug 1661913

Thanks Tomas.
So, maybe we should use the same validation rules for RHV and OSP. Do you know what the limitations are on CNV ?

Looks like they have same requirements as Kubernetes. I've been referred to DNS 1123 specification. I don't know if they have any easily readable regex somewhere in the code.

So it seems the rules in Kubernetes/CNV are:
- maximum length is 253 characters
- can only contain lower case characters, numebers and dashes: [a-z0-9-]
- cannot start/end with dash

Closing as this is already in CFME 5.11.4 and we don't plan to backport.