From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Hardware watchdogs (patch for discussion only)
Date: Thu, 26 Feb 2009 17:50:25 +0000 [thread overview]
Message-ID: <20090226175025.GA10284@shareable.org> (raw)
In-Reply-To: <1235658682.5894.152.camel@ecrins.fosdick.home.net>
Steve Fosdick wrote:
> Perhaps we could have a second timer such that if, on asking the guest
> to shut down via ACPI, the guest does not respond within a certain time
> limit with an ACPI request to turn the power off we go for one of the
> other options below?
Good idea. ACPI is notoriously flaky, especially on a guest which has
already crashed its kernel...
> 1. Ensure continuity of service. When a guest OS gets stuck for some
> reason make sure it is re-started. This is probably the only use case
> on a real physical machine.
For real continuity of service you'd also want QEMU itself to have a
watchdog. Either a software watchdog internally (SIGALRM => kill/exec
self, or child process expecting regular pings over a pipe), or by
QEMU itself becoming a client of the host watchdog.
I say this because I've experienced KVM lock up several times.
> 2. Limit the resource consumption of a crashed guest when the host
> serves other guests. This probably only of concern for virtual
> machines, i.e. it is specific to the emulated watchdog and its
> interaction with qemu rather than being part of how a physical watchdog
> works.
Related to this is "omg the database guest has crashed - and frankly
we don't rtust the automatic recovery process - stop it for now and
we'll inspect for damage manually before starting it again".
> Do we want to offer the guest the option of a clean shutdown if it can
> still manage that and then reboot, i.e. the shutdown option but for use
> case 1?
>
> If so we need to be able to turn the APCI power off request into a reset
> instead. We already have the -no-reboot option to turn a reboot into a
> power off - this is the opposite.
Interesting idea.
> In fact, some people may find that option useful anyway even without the
> watchdog. In an environment where someone has privileged access to a
> guest but no direct access to the host OS he could shut down a guest
> accidentally when intending to reboot (or logoff). It may be useful to
> trap that and turn the shutdown into a reboot.
I've done that a few times. It's only minorly annoying in that you
lose the VNC connection and have to login and restart the VM.
Side notes: It would be nice to be able to change the
"shutdown-when-asked-to-reboot" (et al) option from the monitor. It
would also be nice to "pause-when-asked-to-shutdown/reboot", which is
useful during automatic OS installs - the host script changes the
media and/or hardware at each reboot.
-- Jamie
next prev parent reply other threads:[~2009-02-26 17:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-25 23:37 [Qemu-devel] Hardware watchdogs (patch for discussion only) Richard W.M. Jones
2009-02-26 10:51 ` Daniel P. Berrange
2009-02-26 13:55 ` Richard W.M. Jones
2009-02-26 19:30 ` Blue Swirl
2009-02-26 14:31 ` Steve Fosdick
2009-02-26 14:45 ` Richard W.M. Jones
2009-02-27 9:55 ` Steve Fosdick
2009-02-26 17:50 ` Jamie Lokier [this message]
2009-02-27 9:50 ` Steve Fosdick
2009-02-27 12:19 ` Paul Brook
2009-02-28 21:34 ` Jamie Lokier
2009-02-28 22:00 ` Andreas Färber
2009-02-28 22:11 ` Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090226175025.GA10284@shareable.org \
--to=jamie@shareable.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).