Bug 444273 - RFE: shut down guests with machine
RFE: shut down guests with machine
Status: CLOSED NEXTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Veillard
:
: 437204 537270 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-26 07:05 EDT by Pierre Ossman
Modified: 2010-10-08 13:57 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-25 11:10:03 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)
init script for libvirtd (3.09 KB, application/x-shellscript)
2009-02-02 16:43 EST, syntron
no flags Details
sysconfig file for libvirtd (585 bytes, message/news)
2009-02-02 16:44 EST, syntron
no flags Details
init script for libvirtdomains (3.12 KB, application/x-shellscript)
2009-02-02 16:44 EST, syntron
no flags Details
sysconfig file for libvirtdomains (711 bytes, message/news)
2009-02-02 16:45 EST, syntron
no flags Details

  None (edit)
Description Pierre Ossman 2008-04-26 07:05:05 EDT
One nice feature I'm lacking with the current libvirt package (which otherwise
is a pure delight :)) is the ability to have guests come up and down with the
host. Or rather, come down as the autostart feature is already in place.

Basically, I'd like a init.d script that triggers a "shutdown" on all guests
when the host is going down and waits for them to terminate. A timeout and a
forceful kill is probably also needed though.

The best way is likely with a separate script, as you'd like to restart libvirtd
without killing all your guests.
Comment 1 Pierre Ossman 2008-04-26 07:27:08 EDT
It seems the killing is the current behaviour. :/

So in the light of that, I'd like a tweak from the current forced kill, to a
clean shutdown on service libvirtd stop.
Comment 2 Daniel Berrange 2008-04-26 10:16:21 EDT
Clean shutdown is not viable because this requires co-operation from the guest
OS. There is no guarentee the guest will honour this request to shutdown even
when operating normally, if the guest is operating abnormally it may not even
see the event, and it may hang during shutdown with no way for libvirt to
determine if it is still in process of shutting down, or has hung. 

Killing, or suspending VMs (save to disk) are the only viable options.
Comment 3 Pierre Ossman 2008-04-27 04:17:14 EDT
I agree, which is why I suggest the script _tries_ to shut them down cleanly,
but then gets violent after a certain timeout. Basically the same behaviour as
the SIGTERM/SIGKILL portion at the end of the system shutdown.
Comment 4 Daniel Berrange 2008-04-27 11:59:19 EDT
No, this is the behaviour that used to be present in Xen. It was removed because
it frequently shot domains which were in fact still shutting down cleanly,
simply taking a long time. There is no safe way todo timeouts on shutdown.
Suspending to disk the only guarenteed safe option.
Comment 5 Paul W. Frields 2008-08-10 16:44:51 EDT
Triage here.  Suggest CLOSED {WONTFIX,CANTFIX} then?
Comment 6 Daniel Berrange 2009-01-22 08:09:19 EST
*** Bug 437204 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Berrange 2009-01-22 08:09:56 EST
Leave open. This still needs to be addressed in some way
Comment 8 syntron 2009-02-02 16:43:21 EST
I extended the init script for opensuse. It tries to shutdown all qemu / kvm domains and after a timeout all domains are killed (libvirtd.init and the sysconfig file libvirtd.sysconfig).

Furthermore I also tested the possibility to save / restore domains. This works sometimes and sometimes not. At the moment I have it down that:
- it works if I do stop / start without a reboot in between
- using it for saving / restoring domains restore only returns an error
(libvirtdomains.init and the sysconfig file libvirtdomains.sysconfig)

I hope that the scripts are usefull. I'm not an expert using bash so there will be a lot of things which can be done better ...
Comment 9 syntron 2009-02-02 16:43:59 EST
Created attachment 330683 [details]
init script for libvirtd
Comment 10 syntron 2009-02-02 16:44:21 EST
Created attachment 330684 [details]
sysconfig file for libvirtd
Comment 11 syntron 2009-02-02 16:44:44 EST
Created attachment 330685 [details]
init script for libvirtdomains
Comment 12 syntron 2009-02-02 16:45:11 EST
Created attachment 330686 [details]
sysconfig file for libvirtdomains
Comment 13 syntron 2009-02-02 16:47:59 EST
(In reply to comment #8)
> - using it for saving / restoring domains restore only returns an error

some more info:

if a domains is saved on shutdown it is _not_ restored on boot. even if I try to do it manually it is not restored. But doing a save / restory cycle using a running system all is OK.
Comment 14 Mark McLoughlin 2009-02-03 02:39:46 EST
Moving to Virtualization Tools product

See also:

  http://www.redhat.com/archives/libvir-list/2009-January/msg00193.html
Comment 16 Mark McLoughlin 2009-11-19 09:08:36 EST
*** Bug 537270 has been marked as a duplicate of this bug. ***
Comment 17 Daniel Berrange 2010-02-22 08:28:48 EST
FYI this thread describes the API enhancements required in libvirt in order to safely / reliably support managed shutdown at host halt

http://www.redhat.com/archives/libvir-list/2009-March/msg00205.html
Comment 18 Daniel Berrange 2010-05-25 11:10:03 EDT
The APIs described have now been implemented & an corresponding initscript for auto-shutdown/save is now available

commit 66823690e46944f17e195b1f82c5eee527ddee20
Author: Jiri Denemark <jdenemar@redhat.com>
Date:   Fri May 14 15:37:55 2010 +0200

    Init script for handling guests on shutdown/boot
Comment 19 Henrik Nordström 2010-05-25 14:36:30 EDT
Excellent!

I'll look forward to test this. From which package versions will it be available?
Comment 20 Cole Robinson 2010-05-25 14:56:13 EDT
The next libvirt release will probably be 0.8.2

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