Description of problem: on cloud38 when we choose a VM type "template" as part of warm migration plan ( since template VMs are also available from the choosing VMs section while creating a new plan ) this combination leads to VM template exit on error: Error while attempting warm import: warm import retry limit reached oot@f02-h07-000-r640:~$ oc describe plan/test -nopenshift-rhmtv Name: test Namespace: openshift-rhmtv Labels: <none> Annotations: <none> API Version: forklift.konveyor.io/v1alpha1 Kind: Plan Vms: Id: vm-1130 Id: vm-1134 Id: vm-1143 Warm: true Status: Conditions: Category: Required Last Transition Time: 2021-05-04T06:35:18Z Message: The migration plan is ready. Status: True Type: Ready Category: Advisory Durable: true Last Transition Time: 2021-05-04T06:35:39Z Message: The plan is EXECUTING. Status: True Type: Executing Migration: History: Conditions: Category: Advisory Durable: true Last Transition Time: 2021-05-04T06:35:39Z Message: The plan is EXECUTING. Status: True Type: Executing Started: 2021-05-04T06:35:39Z Vms: Completed: 2021-05-04T06:36:26Z Conditions: Category: Advisory Durable: true Last Transition Time: 2021-05-04T06:36:26Z Message: The VM migration has FAILED. Status: True Type: Failed Error: Phase: ImportCreated Reasons: Error while attempting warm import: warm import retry limit reached Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning VMAlreadyExists 31m (x2 over 32m) plan Target VM already exists. Normal Ready 31m plan The migration plan is ready. from Fabien Dupont : On the VMware side, if I'm not mistaken, a template is a normal VM with a flag in its configuration that says it's a template, but the VMX and disks are standard. I guess (and we need to verify) that warm migration fails because VMware will not create a snapshot on a template. Then, we have 3 options: 1. Filter out templates from the list of selectable VMs in the plan wizard, i.e. we discard the problem for now. 2. Make warm migration unselectable if a template is part of the VM selection. 3. Transparently switch to cold migration for templates. My next question would be: What is the use case behind migrating a template? Usually, when creating a VM from a template, the user is asked a few questions to customize the template. For example, the network will need to change because the template didn't include network config. If we think that we don't fully groomed the template story, I would suggest implementing #1 until we know more. Otherwise, I would be in favor of #3. Regarding the error message, we shouldn't meet it anymore with any of these options, since we would never try to warm migrate a template. Version-Release number of selected component (if applicable): MTV: 2.0.0.21 CNV: 2.6.2
Created attachment 1779670 [details] template
We have decided to make templates unselectable in the VM selection step, by excluding them from the list of VMs. This requires adding the template attribute to the inventory. The field in VMware is VM.config.template and it's a boolean. Then, we need to ensure the Plan controller marks the Plan as not ready if any of the VM is a template. This will ensure a consistent behavior of the API. Finally, we need to update the Plan wizard to discard the VMs flagged as templates when building the VM list.
The fix is in build 2.0.0-10 / iib:73160. The plan is still ready, but the templates are marked failed with an error messages at run time.
Verified on build 2.0.0-12 / iib:73572. VMware Templates are no longer listed in the VMs in the migration plan creation dialog in the UI.
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.0.0 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/RHEA-2021:2381