Bug 435204 - RFE: QEMU: Ability to shutdown a guest with 'quit' on the monitor, instead of SIGTERM
RFE: QEMU: Ability to shutdown a guest with 'quit' on the monitor, instead of...
Status: CLOSED CURRENTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks: libvirtTodoHV
  Show dependency treegraph
 
Reported: 2008-02-27 17:12 EST by Daniel Berrange
Modified: 2014-04-01 03:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-01 03:42:42 EDT
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 Daniel Berrange 2008-02-27 17:12:02 EST
Description of problem:
When a VM needs to be shutdown the QEMU driver sends it a SIGTERM to request
that it exit.

Unfortunately, it then does a non-blocking waitpid() and if that doesn't reap
the child immediately sends it SIGKILL. This does not leave the QEMU proess
sufficient time to cleanly shutdown. 

The QEMU driver should give it a couple of seconds to shutdown before invoking
the SIGKILL big hammer.

One example of the problems seen when doing SIGKILL is that Xenner cannot
cleanup its TAP devices.

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


How reproducible:


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


Expected results:


Additional info:
Comment 1 Bug Zapper 2008-05-14 01:40:36 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Mark McLoughlin 2009-01-21 04:21:57 EST
Still an issue:

static void qemudShutdownVMDaemon(virConnectPtr conn ATTRIBUTE_UNUSED,
                                  struct qemud_driver *driver, virDomainObjPtr vm) {
..
    if (virKillProcess(vm->pid, 0) == 0 &&
        virKillProcess(vm->pid, SIGTERM) < 0)
        qemudLog(QEMUD_ERROR, _("Failed to send SIGTERM to %s (%d): %s\n"),
                 vm->def->name, vm->pid, strerror(errno));
..
    /* shut it off for sure */
    virKillProcess(vm->pid, SIGKILL);
..
}
Comment 3 Bug Zapper 2009-06-09 05:27:59 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Mark McLoughlin 2009-09-15 07:21:05 EDT
Still looks like it's an issue in libvirt-0.7.1
Comment 5 Bug Zapper 2009-11-16 03:02:12 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2010-11-04 08:01:32 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Michal Privoznik 2014-04-01 03:42:42 EDT
This bug has been resolved for a while now:

commit 72f8a7f19753506ed957b78ad800c0f3892c9304
Author:     Laine Stump <laine@laine.org>
AuthorDate: Fri Jan 27 13:28:23 2012 -0500
Commit:     Laine Stump <laine@laine.org>
CommitDate: Fri Feb 3 14:21:17 2012 -0500

    qemu: new GRACEFUL flag for virDomainDestroy w/ QEMU support
    
    When libvirt's virDomainDestroy API is shutting down the qemu process,
    it first sends SIGTERM, then waits for 1.6 seconds and, if it sees the
    process still there, sends a SIGKILL.
    
    There have been reports that this behavior can lead to data loss
    because the guest running in qemu doesn't have time to flush its disk
    cache buffers before it's unceremoniously whacked.
    
    This patch maintains that default behavior, but provides a new flag
    VIR_DOMAIN_DESTROY_GRACEFUL to alter the behavior. If this flag is set
    in the call to virDomainDestroyFlags, SIGKILL will never be sent to
    the qemu process; instead, if the timeout is reached and the qemu
    process still exists, virDomainDestroy will return an error.
    
    Once this patch is in, the recommended method for applications to call
    virDomainDestroyFlags will be with VIR_DOMAIN_DESTROY_GRACEFUL
    included. If that fails, then the application can decide if and when
    to call virDomainDestroyFlags again without
    VIR_DOMAIN_DESTROY_GRACEFUL (to force the issue with SIGKILL).
    
    (Note that this does not address the issue of existing applications
    that have not yet been modified to use VIR_DOMAIN_DESTROY_GRACEFUL.
    That is a separate patch.)

And it's part of the v0.9.10 release.

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