Bug 1726939

Summary: Run the preflight check of migration task before waiting for a conversion host
Product: Red Hat CloudForms Management Engine Reporter: Fabien Dupont <fdupont>
Component: V2VAssignee: Fabien Dupont <fdupont>
Status: CLOSED EOL QA Contact: Shveta <sshveta>
Severity: high Docs Contact: Red Hat CloudForms Documentation <cloudforms-docs>
Priority: high    
Version: 5.10.6CC: bthurber, dmetzger, mguetta
Target Milestone: GAKeywords: TestOnly, ZStream
Target Release: 5.12.0Flags: mfeifer: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1767549 (view as bug list) Environment:
Last Closed: 2020-03-25 18:02:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: V2V Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1740510, 1767549    
Attachments:
Description Flags
Screen Record - bug verification none

Description Fabien Dupont 2019-07-04 06:42:29 UTC 
Description of problem:
When a migration plan is run, a ServiceTemplateTransformationPlanTask and an InfraConversionJob are created per VM in the plan. The InfraConversionJob is responsible for monitoring the process via a state machine.

With the current state machine, the first thing that happens is that a conversion host is assigned to the Task. Then, the task is 'starts' which means that it runs the ServiceTemplateTransformationPlanTask.preflight_check method.

This has two effects:

  1. We need a conversion host to run the checks. This means that in a large plan, it may happen really late because the number of conversion slots is limited.

  2. The UI doesn't report the correct total storage to migrate, because the virtv2v_disks array is only populated during preflight_check. This means that migrations waiting for a conversion host are not reported.

Version-Release number of selected component (if applicable): 5.10.6


How reproducible: Always


Steps to Reproduce:
1. Create a migration plan with 20 VMs
2. Limit the total concurrent migrations to 10
3. Start the migration plan

Actual results:
The total storage reported on the migration plan card corresponds to the storage of the 10 VMs currently migrating. As the other VMs start to migrate, the total storage will grow.

Expected results:
The total storage reported on the migration plan cards corresponds to the storage of the 20 VMs.
Comment 2 Fabien Dupont 2019-07-31 09:51:24 UTC 
This is going to be part of a broader rewrite of the state machine to integrate warm migration steps. Moving to 5.11.z.
Comment 3 Fabien Dupont 2019-08-14 09:41:01 UTC 
https://github.com/ManageIQ/manageiq/pull/19146
Comment 4 Fabien Dupont 2019-08-14 09:41:32 UTC 
*** Bug 1740661 has been marked as a duplicate of this bug. ***
Comment 5 Fabien Dupont 2019-08-19 21:09:10 UTC 
To test this BZ, one should create a migration plan with a VM that won't pass preflight check. One example is a VM supposed to migrate to OpenStack but powered off when the migration plan starts.
The VM migration should fail right away, without waiting for a conversion host. This can be verified in Rails console:

irb> task = Vm.find_by(:name => 'my_vm', :vendor => 'vmware')
irb> task = ServiceTemplateTransformationPlanTask.where(:source => vm).last
irb> task.status
=> "Error"
irb> task.conversion_host
=> nil
Comment 7 Maayan Hadasi 2019-12-08 10:36:38 UTC 
Verified this issue with CFME version: 5.11.1.1

While migrating 20 VMs, one conversion host, configured to max 10 VMs ->
first, CFME UI showed data size for 10 VMs, and after some seconds the data size was updated to the total size (see attached video)
Is it the expected behaviour?

Tried to reproduced the issue with one VM, as described in comment #5, without success.
Our tries were: 
1. VM without network -> passed. (by design)
2. VM with storage that doesn't match to the storage mapping (tested by rest api) -> didn't get the described error:
irb> vm = Vm.find_by(:name => 'v2v_migration_vm_0', :vendor => 'vmware')
irb> task = ServiceTemplateTransformationPlanTask.where(:source => vm).last
irb> task.status
=> "Ok"

How to verify this by one migration to RHV?
Comment 8 Maayan Hadasi 2019-12-08 10:38:42 UTC 
Created attachment 1643009 [details]
Screen Record - bug verification
Comment 9 Fabien Dupont 2019-12-09 09:02:24 UTC 
One possibility is to verify that with RHV:
  1. Create an infrastructure mapping with a RHV provider
  2. Create a migration plan with the previously created infrastructure mapping
  3. Modify the infrastructure mapping to remove the cluster mapping
  4. Run the migration plan

To remove the cluster mapping from the infrastructure mapping via Rails console:

irb> mapping = TransformationMapping.find_by(:name => "My Mapping")
irb> mapping.transformation_mapping_items.select { |i| i.source_type == 'EmsCluster' }.each { |i| i.destroy }