Bug 491065

Summary:	[FEAT] QEMU: detect when ACPI power down command was received by the guest
Product:	Red Hat Enterprise Linux 6	Reporter:	Yaniv Kaul <ykaul>
Component:	qemu-kvm	Assignee:	Gleb Natapov <gleb>
Status:	CLOSED CANTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	jkt, knoel, ndevos, ovirt-maint, Rhev-m-bugs, tburke, virt-maint, ykaul
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Windows
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-07 14:39:21 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 Yaniv Kaul 2009-03-19 09:54:34 UTC

Description of problem:
<from Avi:>
We can detect that the guest read the register containing the power 
button status.  The register contains other random crap, so it won't be 
100% reliable.  Of course there's no guarantee the guest will be able to 
complete its shutdown sequence, but at least we know there's a good 
chance it started it.

This would allow us to know that the VM has responded to our request to shutdown and might be doing it (as opposed to stuck) and give it more time to shutdown. This is critical in cases Windows updates itself - it shuts itself down (closes all apps), then applies hotfixes - which may take few minutes. Killing it in the middle may be very harmful.

The detection should be output to the monitor, so the VDSM can make use of it and prolong the time it gives for a VM to shut down.


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

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 3 Dor Laor 2010-01-07 10:41:18 UTC

We should create an async monitor event for it

Comment 4 Gleb Natapov 2010-01-07 10:57:10 UTC

We can't detect what guest is going to do reliably and we denied features based on that before. Heuristics are bad. What our current timeout for shutdown? Are you sure that guest will eventually shutdown if we'll wait long enough? Can we increase shutdown timeout from the gui?

Comment 5 Avi Kivity 2010-01-07 11:07:18 UTC

Timeouts are bad.  When Windows updates it will sometimes defer copying files to its shutdown sequence.  If that happens shutdown can easily take many minutes.

If the guest doesn't shut down, let the user peek at it and see what's wrong.

Comment 6 Yaniv Kaul 2010-01-07 11:25:54 UTC

(In reply to comment #5)
> Timeouts are bad.  When Windows updates it will sometimes defer copying files
> to its shutdown sequence.  If that happens shutdown can easily take many
> minutes.

Indeed - can take up to half an hour, for several tens of updates (had this last night - it may even revert the updates on failure!)

> 
> If the guest doesn't shut down, let the user peek at it and see what's wrong.

Comment 7 Dor Laor 2010-01-07 14:31:13 UTC

So, shall we close it?

Comment 8 Gleb Natapov 2010-01-07 14:33:50 UTC

yes

Comment 9 Yaniv Kaul 2010-01-07 14:48:53 UTC

(In reply to comment #7)
> So, shall we close it?  

If you read my initial description - all I'm asking is detection - which I'm fine with not being reliable. The decision to act upon it is up to the user. See the description of the scenario.

Comment 10 Gleb Natapov 2010-01-07 14:58:32 UTC

Tell user that host is not going down by itself and ask him if he want to power-off or he wants to check what happens. The detection you are asking for is not meaningful in most of the cases.