Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1367023 - Power-off takes too long
Summary: Power-off takes too long
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.1.0-beta
: 4.1.0.2
Assignee: Arik
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-15 09:39 UTC by Arik
Modified: 2017-03-16 14:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-16 14:48:19 UTC
oVirt Team: Virt
rule-engine: ovirt-4.1+
mgoldboi: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 69030 master MERGED core: do not ignore down event on destroy vm 2016-12-29 13:30:41 UTC
oVirt gerrit 69150 master MERGED core: improve auditing of vm that goes down 2016-12-27 12:34:03 UTC
oVirt gerrit 69310 ovirt-engine-4.1 MERGED core: improve auditing of vm that goes down 2017-01-01 13:07:41 UTC
oVirt gerrit 69311 ovirt-engine-4.1 MERGED core: do not ignore down event on destroy vm 2017-01-01 13:07:33 UTC
oVirt gerrit 69364 master MERGED core: remove async operation for powered off vm 2017-01-01 11:40:26 UTC
oVirt gerrit 69371 ovirt-engine-4.1 MERGED core: remove async operation for powered off vm 2017-01-01 13:07:37 UTC

Description Arik 2016-08-15 09:39:31 UTC
Description of problem:
Power-off should be almost immediate.
Indeed, when calling the 'destroy' verb we immediately get an event as a result but it is ignored because before calling the 'destroy' verb we acquire a monitoring lock. So after this event is ignored, we wait for the next polling cycle that could be in 15sec in the worst case.

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


How reproducible:
depends on timing, but high reproduction rate

Steps to Reproduce:
1. Power off a running VM
2.
3.

Actual results:
The VM status is switched to powering-down (which is also wrong because the VM is not powering down) and it takes several seconds until the next polling cycle that detects the VM is not reported from VDSM and thus destroyed.

Expected results:
The VM should switch to down very quick as a result of the event we get from VDSM.

Additional info:

Comment 1 Tomas Jelinek 2016-08-16 08:18:07 UTC
targeting to 4.0.4 since it may have high usability impact.

Comment 2 meital avital 2017-03-09 09:35:48 UTC
Verified on version: 4.1.1.3-0.1.el7


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