Bug 738273

Summary:	RFE: Add a way to relate STOP event (emit during shutdown) with SHUTDOWN
Product:	Red Hat Enterprise Linux 6	Reporter:	Marian Krcmarik <mkrcmari>
Component:	qemu-kvm	Assignee:	Luiz Capitulino <lcapitulino>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.2	CC:	acathrow, juzhang, mkenneth, syeghiay, tburke, virt-maint
Target Milestone:	rc	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-16 18:17:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.