All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:29:54 +0100	[thread overview]
Message-ID: <20190930142954.GA2801@work-vm> (raw)
In-Reply-To: <42837590-2563-412B-ADED-57B8A10A8E68@nutanix.com>

* 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.

> 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


  reply	other threads:[~2019-09-30 14:32 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 [this message]
2019-09-30 15:46   ` Felipe Franciosi
2019-09-30 16:03     ` Dr. David Alan Gilbert
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=20190930142954.GA2801@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.