Description of problem: We know that some VM names are invalid in RHV and OpenStack. For example, RHV doesn't allow space and punctuation, and OpenStack doesn't allow special characters. The goal is to identify VMs in source provider whose name will not be allowed by the destination provider and make them unselectable in the UI.
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.