Bug 491065 - [FEAT] QEMU: detect when ACPI power down command was received by the guest
[FEAT] QEMU: detect when ACPI power down command was received by the guest
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.0
All Windows
low Severity medium
: rc
: ---
Assigned To: Gleb Natapov
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-19 05:54 EDT by Yaniv Kaul
Modified: 2013-07-03 21:15 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-07 09:39:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yaniv Kaul 2009-03-19 05:54:34 EDT
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 05:41:18 EST
We should create an async monitor event for it
Comment 4 Gleb Natapov 2010-01-07 05:57:10 EST
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 06:07:18 EST
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 06:25:54 EST
(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 09:31:13 EST
So, shall we close it?
Comment 8 Gleb Natapov 2010-01-07 09:33:50 EST
yes
Comment 9 Yaniv Kaul 2010-01-07 09:48:53 EST
(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 09:58:32 EST
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.

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