Bug 738273 - RFE: Add a way to relate STOP event (emit during shutdown) with SHUTDOWN
Summary: RFE: Add a way to relate STOP event (emit during shutdown) with SHUTDOWN
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.2
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Luiz Capitulino
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-14 12:51 UTC by Marian Krcmarik
Modified: 2013-01-10 00:19 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-16 18:17:53 UTC


Attachments (Terms of Use)

Description Marian Krcmarik 2011-09-14 12:51:53 UTC
Description of problem:
It would be nice to relate STOP event which is emited during shutdown with the SHUTDOWN event so that libvirt can say that the paused state is related to the shutdown and does not propagate the paused state to higher level applications. Now once user does a shutdown he/she can see (for example in RHEVM portals) that the VM is being shutdown -> paused -> not running (which is displayed for some time in User portal (web application) of RHEVM).

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

How reproducible:
Always

Steps to Reproduce:
1. Start the guest from some management application (RHEVM, virt-manager)
2. Shutdown the guest.

  
Actual results:
Management applications display shutting down -> paused guest -> not running guest

Expected results:
without the paused state

Additional info:

Comment 2 Dor Laor 2011-09-15 13:58:01 UTC

*** This bug has been marked as a duplicate of bug 738487 ***

Comment 3 Marian Krcmarik 2011-09-16 14:45:23 UTC
Hi Dor,

I do believe This is different thing, basically I would like if STOP event sent by qemu during shutdown with -no-shutdown option is related to the SHUTDOWN. The reason is that users of high level management applications (especially UP of RHEVM) can see after shutting done of a VM that machine is in paused state because libvirt puts VM into paused state after getting STOP event which is mostly the right thing but during shutdown it's confusing for users. Once libvirt knows that STOP event is due to shutdown libvirt will not propagate it to higher level application.
Luiz mentioned that most of the work is done and this requires only small changes.
I am reopening the bug. 
Thanks.

Comment 4 Luiz Capitulino 2011-09-19 18:08:41 UTC
This is an RFE being targeted for 6.3.

Comment 6 Luiz Capitulino 2012-07-16 18:17:53 UTC
The STOP event mentioned in the description will only happen if the -no-shutdown flag is in use. In this case, there will be a SHUTDOWN event before that. This means that that STOP event is superfluous and can be ignored by libvirt.

We could probably drop that STOP event with -no-shutdown from qemu, because it doesn't seem to report anything useful. If libvirt guys wants it, let me know.

But anyway, this shouldn't be an issue for 6.4 and hence I'm closing this as NOTABUG.

Comment 7 Marian Krcmarik 2012-07-16 18:25:37 UTC
(In reply to comment #6)
> The STOP event mentioned in the description will only happen if the
> -no-shutdown flag is in use. In this case, there will be a SHUTDOWN event
> before that. This means that that STOP event is superfluous and can be
> ignored by libvirt.
> 
> We could probably drop that STOP event with -no-shutdown from qemu, because
> it doesn't seem to report anything useful. If libvirt guys wants it, let me
> know.
> 
> But anyway, this shouldn't be an issue for 6.4 and hence I'm closing this as
> NOTABUG.

Well What I tried to avoid was following: 
"The reason is that users of high level management applications (especially UP of RHEVM) can see after shutting done of a VM that machine is in paused state because libvirt puts VM into paused state after getting STOP event which is mostly the right thing but during shutdown it's confusing for users."
Never mind.


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