Bug 1666799 - [v2v] Canceling migration does not stop creating volume, instance, and network port on OSP or VMs on RHV
Summary: [v2v] Canceling migration does not stop creating volume, instance, and networ...
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: V2V
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.11.0
Assignee: Fabien Dupont
QA Contact: Yadnyawalk Tale
Red Hat CloudForms Documentation
Whiteboard: v2v
: 1718678 (view as bug list)
Depends On:
Blocks: 1668816 1672699 1720671
TreeView+ depends on / blocked
Reported: 2019-01-16 15:08 UTC by Yadnyawalk Tale
Modified: 2019-08-20 04:25 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1672699 1720671 (view as bug list)
Last Closed:
Category: Bug
Cloudforms Team: V2V
Target Upstream Version:
ytale: needinfo-

Attachments (Terms of Use)
automation.log (3.49 MB, text/plain)
2019-01-16 15:08 UTC, Yadnyawalk Tale
no flags Details
cfme_plan_details.png (62.38 KB, image/png)
2019-01-16 15:15 UTC, Yadnyawalk Tale
no flags Details

Description Yadnyawalk Tale 2019-01-16 15:08:24 UTC
Created attachment 1521072 [details]

Description of problem:
Cancel migration do not stop creating volume, instance and network port on OSP

OSP - 14 (qe's baremetal)
Conversion appliance - rhosp-v2v-appliance-14.0-20181214.1

How reproducible:

Steps to Reproduce:
1. Migrate vm and cancel in between (I did at ~28.47%)

Actual results:
CFME UI shows like it is canceled (gives fa fa-ban icon and bars stops on same %) but if you check virt-v2v wrapper log on conversion you will find migration still is in progress. 

Found process runs till it finishes the migration, it creates volume, instance and port in OSP.

Expected results:
Should stop migration on cancel trigger point itself.

Additional info:
Found failed migration behaves differently in this case, it clears things created by process after migration failure.

Comment 4 Yadnyawalk Tale 2019-01-16 15:15:56 UTC
Created attachment 1521075 [details]

Comment 8 Fabien Dupont 2019-01-18 14:04:35 UTC
I could reproduce the issue and from what I've seen, it should not work on RHV neither. Have you tested it ?

Comment 9 Fabien Dupont 2019-01-18 15:51:18 UTC

Comment 10 Yadnyawalk Tale 2019-01-18 17:13:33 UTC
Tested usecase with RHV and it does reproduce on This issue is not on though, since problematic code does not exists on build.
Thanks @fabien for confirmation.

Comment 11 Brett Thurber 2019-01-23 14:59:20 UTC
*** Bug 1668662 has been marked as a duplicate of this bug. ***

Comment 16 Sudhir Mallamprabhakara 2019-05-03 16:24:33 UTC
Appliance is available for debugging..

> Appliance :
> Plan : plan_BQypPt46jh

Thanks Shveta

- Sudhir

Comment 17 Sudhir Mallamprabhakara 2019-05-07 14:59:05 UTC
Moving this to 5.10.5 after consulting with Fabien

Comment 18 Fabien Dupont 2019-05-17 12:52:15 UTC
Please, try to reproduce when 5.10.5 build #1 is available.

Comment 25 Tomáš Golembiovský 2019-05-31 12:15:49 UTC
I checked the appliance logs and I found this:

evm.log:[----] W, [2019-05-31T05:24:32.862141 #16315:89ecd18]  WARN -- : MIQ(ServiceTemplateTransformationPlanTask#kill_virtv2v) Could not find PID for task using virtv2v wrapper: {"wrapper_log"=>"/var/log/vdsm/import/v2v-import-20190531T051849-33892-wrapper.log", "v2v_log"=>"/var/log/vdsm/import/v2v-import-20190531T051849-33892.log", "state_file"=>"/tmp/v2v-import-20190531T051849-33892.state", "throttling_file"=>"/tmp/v2v-import-20190531T051849-33892.throttle"}
evm.log:[----] W, [2019-05-31T05:25:13.707227 #16307:7549974]  WARN -- : MIQ(ServiceTemplateTransformationPlanTask#kill_virtv2v) Could not find PID for task using virtv2v wrapper: {"wrapper_log"=>"/var/log/vdsm/import/v2v-import-20190531T051849-33892-wrapper.log", "v2v_log"=>"/var/log/vdsm/import/v2v-import-20190531T051849-33892.log", "state_file"=>"/tmp/v2v-import-20190531T051849-33892.state", "throttling_file"=>"/tmp/v2v-import-20190531T051849-33892.throttle"}

This looks to me that you are passing wrong structure to the kill function. The 'pid' is in the state file.

(Thanks Daniel for the patch.)

Comment 26 Yadnyawalk Tale 2019-06-06 20:24:25 UTC
When we cancel migration we should either take updated % from backend/logs and then update UI bars according to that. In other words, UI and backend both should show same % on which migration stopped. 

After cancelling migration in UI, let say on 30%, at backend it goes for 10-20% extra sometimes (may be processing delay) and then in backend it shows 50%. Now if you see backend/logs is totally correct (50%) but in UI it is incorrect (30%).

One more reason we are thinking on this aspect is because this uncertain behavior is hard to automate, we should addressed this as well. Either we should stop backend quickly after migration got cancelled in UI (not sure how it is possible) or it should take % from backend and update it in UI as I mentioned.

Comment 29 Ilanit Stein 2019-06-11 13:52:06 UTC
*** Bug 1718678 has been marked as a duplicate of this bug. ***

Comment 30 Fabien Dupont 2019-06-11 15:26:09 UTC

Comment 31 Fabien Dupont 2019-06-14 09:36:39 UTC
Comment for QE: the fix only ensure that the virt-v2v process is killed.
We noticed that the disk transfer is not cancelled in our lab, but it might be due to issues with the RHV environment. If you observe the same behavior in the QE lab, please open a new BZ as the cause and solution will be different.

Comment 33 Shveta 2019-08-20 04:25:36 UTC
Fixed .
Working in

Note You need to log in before you can comment on or make changes to this bug.