From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Felipe Franciosi <felipe@nutanix.com>
Cc: Aditya Ramesh <aramesh@nutanix.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: Thoughts on VM fence infrastructure
Date: Mon, 30 Sep 2019 17:03:16 +0100 [thread overview]
Message-ID: <20190930160316.GH2759@work-vm> (raw)
In-Reply-To: <C5374DA3-A1FC-4F1A-AA36-DC02D350F5A1@nutanix.com>
* Felipe Franciosi (felipe@nutanix.com) wrote:
> Hi David,
>
> > On Sep 30, 2019, at 3:29 PM, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
> >
> > * Felipe Franciosi (felipe@nutanix.com) wrote:
> >> Heyall,
> >>
> >> We have a use case where a host should self-fence (and all VMs should
> >> die) if it doesn't hear back from a heartbeat within a certain time
> >> period. Lots of ideas were floated around where libvirt could take
> >> care of killing VMs or a separate service could do it. The concern
> >> with those is that various failures could lead to _those_ services
> >> being unavailable and the fencing wouldn't be enforced as it should.
> >>
> >> Ultimately, it feels like Qemu should be responsible for this
> >> heartbeat and exit (or execute a custom callback) on timeout.
> >
> > It doesn't feel doing it inside qemu would be any safer; something
> > outside QEMU can forcibly emit a kill -9 and qemu *will* stop.
>
> The argument above is that we would have to rely on this external
> service being functional. Consider the case where the host is
> dysfunctional, with this service perhaps crashed and a corrupt
> filesystem preventing it from restarting. The VMs would never die.
Yeh that could fail.
> It feels like a Qemu timer-driven heartbeat check and calls abort() /
> exit() would be more reliable. Thoughts?
OK, yes; perhaps using a timer_create and telling it to send a fatal
signal is pretty solid; it would take the kernel to do that once it's
set.
IMHO the safer way is to kick the host off the network by reprogramming
switches; so even if the qemu is actually alive it can't get anywhere.
Dave
> Felipe
>
> >
> >> Does something already exist for this purpose which could be used?
> >> Would a generic Qemu-fencing infrastructure be something of interest?
> > Dave
> >
> >
> >> Cheers,
> >> F.
> >>
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-09-30 16:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 10:30 Thoughts on VM fence infrastructure Felipe Franciosi
2019-09-30 14:29 ` Dr. David Alan Gilbert
2019-09-30 15:46 ` Felipe Franciosi
2019-09-30 16:03 ` Dr. David Alan Gilbert [this message]
2019-09-30 16:59 ` Felipe Franciosi
2019-09-30 17:11 ` Dr. David Alan Gilbert
2019-09-30 17:33 ` Felipe Franciosi
2019-09-30 17:59 ` Dr. David Alan Gilbert
2019-09-30 19:23 ` Felipe Franciosi
2019-10-01 8:23 ` Dr. David Alan Gilbert
2019-10-01 9:56 ` Felipe Franciosi
2019-10-01 10:05 ` Dr. David Alan Gilbert
2019-10-01 10:31 ` Daniel P. Berrangé
2019-10-01 10:46 ` Felipe Franciosi
2019-10-01 11:10 ` Daniel P. Berrangé
2019-10-01 11:38 ` Felipe Franciosi
2019-10-01 10:49 ` Daniel P. Berrangé
2019-09-30 19:45 ` Rafael David Tinoco
2019-09-30 20:24 ` Felipe Franciosi
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=20190930160316.GH2759@work-vm \
--to=dgilbert@redhat.com \
--cc=aramesh@nutanix.com \
--cc=felipe@nutanix.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.