Bug 1963285

Summary: Migration analysis is stuck
Product: Migration Toolkit for Virtualization Reporter: Nandini Chandra <nachandr>
Component: GeneralAssignee: Jeff Ortel <jortel>
Status: CLOSED ERRATA QA Contact: Ilanit Stein <istein>
Severity: medium Docs Contact: Avital Pinnick <apinnick>
Priority: unspecified    
Version: 2.0.0CC: apinnick, fdupont, istein, jortel
Target Milestone: ---   
Target Release: 2.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-10 17:12:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screen shot of migration analysis of VMs none

Description Nandini Chandra 2021-05-21 23:34:21 UTC
Created attachment 1785703 [details]
screen shot of migration analysis of VMs

Description of problem:
------------------------
Migration analysis is stuck in the backend. So, the "analysing" state spins indefinitely for all VMs during VM selection.The VMs have been analyzed since  provider addition, but at some point the validation service got stuck in the backend. See attached screen shot.


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


How reproducible:
-----------------
Unsure


Steps to Reproduce:
-------------------
1.Add VMware provider
2.Create a migration plan by selecting VMs for migration.
3.Observe that the "analysing" state spins indefinitely for all VMs during VM selection.

Actual results:
---------------
Validation service is stuck, because of which migration analysis is stuck.


Expected results:
-----------------
Validation service and migration analysis should work like expected 


Additional info:
----------------
1)The VShphere provider added to MTV had ~4k VMs. I'm unsure if the issue is related to the number of VMs on VSphere.

Comment 1 Nandini Chandra 2021-05-21 23:44:29 UTC
Whenever the inventory data for a VM is updated, the revision number increments, and the revisionValidated indicates which revision was last analyzed. The API data shows that the 'revision' property(4) is greater than the 'revisionValidated' property(2). Hence, the VM has not been analyzed since the last two VM inventory data updates. Note that "revisionValidated" is 2 which means that the VM has been analyzed twice.

{"id":"vm-857","parent":{"kind":"Folder","id":"group-v3"},"revision":4,"name":"rhel7-template12","selfLink":"providers/vsphere/0bd3c50d-e98b-440c-be62-bcaaa676b84a/vms/vm-857","policyVersion":4,"revisionValidated":2,"uuid":"42030d5f-9120-291c-ba0a-35b65b8a56ca","firmware":"bios","powerState":"poweredOff","connectionState":"connected","snapshot":

Comment 2 Fabien Dupont 2021-05-27 10:40:11 UTC
Please verify with build 2.0.0-20 / iib:77891

Comment 3 Ilanit Stein 2021-05-31 15:45:47 UTC
Verified based on a test done on MTV 2.0.0-23 / iib:78256

Comment 6 errata-xmlrpc 2021-06-10 17:12:05 UTC
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