Description of problem: Migration fails if source VMs ov VMWare side have names incompatible with k8s. Right now validation service just reminds about it, but user can miss it. In case of such migration will run - it will 100% fail with not obvious errors in log I would like to propose 2 possible ways of solving this: 1. Add a checkbox that will allow to replace incompatible symbols like spaces, underscores and capital letters to something that comply with k8s 2. Allow user to change target VM names during plan creation or editing.
The preference is to make the migration hands off and ask minimal info to the user. I have a strong preference for option 1, adding a report of the migration afterwards.
Miguel, I guess that both options can be implemented, one just as a checkbox, to do that automatically, second - just a button, pressing on which will list all such VMs and allow to edit names one by one. So user will decide which one of ways he wants to use. So we will not bother user with additional editing that he doesn't want to do and this will be flexible enough.
(In reply to Miguel Perez Colino from comment #1) > The preference is to make the migration hands off and ask minimal info to > the user. > I have a strong preference for option 1, adding a report of the migration > afterwards. +1 We're looking at taking it a step further and do it without adding a checkbox Such a checkbox should anyway be selected by default, it would make sense not to select it only when/if there's an option to override the name
After some discussion, it seems that the best approach is automatically changing the VM names without user input. Since the user will probably migrate a large amount of VMs at once it does not make sense to change their names one by one, also we would like to interfere as minimum as possible so doing this automatically for the user seems to be the best solution, in any case during the create plane stage the user will have warning message with the details so he can still change the VM names from his side prior creating and executing the plan. As a first step, we are just removing all the restricted chars and making the name valid, next step will be adding a unique name mapping system to make it simple for the user to keep track of the new VM names, also we will keep the old one as part of the VM properties so the user will have a reference in case of need. I've created some initial PRs for that: https://github.com/konveyor/forklift-controller/pull/448 https://github.com/konveyor/forklift-validation/pull/47
Verification Versions: MTV - 2.3.4 OpenShift - 4.11.14 Kubernetes version - v1.24.6+5157800 RHV - 4.4.10.6-0.1.el8ev vSphere Client version 6.5.0.13000 Checkpoints: 1. Check if there is a "Invalid VM Name" warning on the source VM with invalid name while selecting VMs. 2. Check if an invalid VM name could be automatically renamed, the invalid name could be: - a name that contains characters not in [lowercase alphanumeric, '-'] - a name that starts with a non-alphanumeric character - a name that ends with a non-alphanumeric character - a name that contains characters more than the maximum length 3. Check if an invalid VM name whose expected valid name already exists in the target namespace could be automatically renamed to a different name. 4. Check if multiple invalid VM names that have the same expected valid names could be automatically renamed to different names when they are in one migration plan. 5. Check if the original VM name is attached to the imported VM. Steps: In order to cover the above checkpoints, run the following steps: 1. Create VMs with name mtvrename-test-0 in both RHV and VMWare ENV, migrate the VM from RHV to namespace1, from VMWare to namespace2. 2. Create VMs with following names in both RHV and VMWare ENV: _mtv.Rename_Test-0- -->(its expected valid name is mtvrename-test-0) _mtv.Rename_Test-1- -->(its expected valid name is mtvrename-test-1) -mtv.Rename_Test-1_ -->(its expected valid name is mtvrename-test-1) mtvrename-test-1 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab ---> (64 characters, in RHV) aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbb ---> (70 characters, in VMWare) 3. Create a plan for migrating all the VMs in step2 from RHV to namespace1. 4. Create a plan for migrating all the VMs in step2 from VMware to namespace2. 5. Start migration, check if all invalid names could be automatically renamed without conflict, and all VMs could be migrated successfully. 6. Check if the original VM name is attached to the imported VM. Results: 1. There is the "Invalid VM Name" warning on the source VM with invalid name while selecting VMs, except for the long name that has 64 characters. 2. There is a warning saying "Target VM name does not comply with DNS1123 RFC, will be automatically changed" after the plan is created. The warning also appears on the plan item when the long name with 64 characters is selected in the plan, though there is no warning on the VM when selecting it. 3. For migrating VMs from RHV: 1) _mtv.Rename_Test-0 is changed to mtvrename-test-0-4eb9. This is expected as mtvrename-test-0 already exists in target namespace. 2) _mtv.Rename_Test-1- is changed to mtvrename-test-1-f868. This is expected as mtvrename-test-1 exists in the same plan. 3) -mtv.Rename_Test-1_ is changed to mtvrename-test-1-acd6. This is expected as mtvrename-test-1 exists in the same plan. 4) mtvrename-test-1 is not changed which is expected because it's a valid name. 5) aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab is changed to aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa which has 63 characters. 4. For migrating VMs from VMWare: 1) _mtv.Rename_Test-0- is changed to mtvrename-test-0-vm-2. This is expected as mtvrename-test-0 already exists in target namespace. 2) _mtv.Rename_Test-1- is failed to change because of error 'virtualmachines.kubevirt.io "mtvrename-test-1-vm-2" already exists' in Initialize migration step. This is not expected. 3) -mtv.Rename_Test-1_ is changed to mtvrename-test-1-vm-2. This is expected as mtvrename-test-1 exists in the same plan. 4) mtvrename-test-1 is not changed which is expected because it's a valid name. 5) aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbb is changed to aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa-vm-2 which has 68 characters. This is not expected, the source long name is changed, but the result is still a long name. 5. The VMs, except _mtv.Rename_Test-1- in VMWare, are all migrated successfully. The original VM names are displayed in the imported VM yamls. According to the tests, the bug fix works as expected in general, invalid VM name could be automatically changed, the original VM name could be displayed in the imported VM yaml. Move this bug to VERIFIED. For the exceptions in the tests, I'll open stories for tracking them.
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 (MTV 2.3.4 Images), 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/RHBA-2022:8576