From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Lukas Straub <lukasstraub2@web.de>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
qemu-block <qemu-block@nongnu.org>,
"Juan Quintela" <quintela@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Max Reitz" <mreitz@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 0/5] Introduce 'yank' oob qmp command to recover from hanging qemu
Date: Tue, 12 May 2020 10:43:37 +0100 [thread overview]
Message-ID: <20200512094337.GK1191162@redhat.com> (raw)
In-Reply-To: <20200512113206.62836e44@luklap>
On Tue, May 12, 2020 at 11:32:06AM +0200, Lukas Straub wrote:
> On Mon, 11 May 2020 16:46:45 +0100
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > > ...
> > > That way if QEMU does get stuck, you can start by tearing down the
> > > least distruptive channel. eg try tearing down the migration connection
> > > first (which shouldn't negatively impact the guest), and only if that
> > > doesn't work then, move on to tear down the NBD connection (which risks
> > > data loss)
> >
> > I wonder if a different way would be to make all network connections
> > register with yank, but then make yank take a list of connections to
> > shutdown(2).
>
> Good Idea. We could name the connections (/yank callbacks) in the
> form "nbd:<node-name>", "chardev:<chardev-name>" and "migration"
> (and add "netdev:...", etc. in the future). Then make yank take a
> list of connection names as you suggest and silently ignore connections
> that don't exist. And maybe even add a 'query-yank' oob command returning
> a list of registered connections so the management application can do
> pattern matching if it wants.
Yes, that would make the yank command much more flexible in how it can
be used.
As an alternative to using formatted strings like this, it could be
modelled more explicitly in QAPI
{ 'struct': 'YankChannels',
'data': { 'chardev': [ 'string' ],
'nbd': ['string'],
'migration': bool } }
In this example, 'chardev' would accept a list of chardev IDs which
have it enabled, 'nbd' would accept a list of block node IDs which
have it enabled, and migration is a singleton on/off.
The benefit of this modelling is that you can introspect QEMU
to discover what classes of channels support being yanked by
this QEMU build, as well as what instances are configured to
be yanked. ie you can distinguish between a QEMU that doesn't
support yanking network devices, from a QEMU that does support
yanking network devices, but doesn't have it enabled for any
network device instances.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-05-12 9:44 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-11 11:14 [PATCH 0/5] Introduce 'yank' oob qmp command to recover from hanging qemu Lukas Straub
2020-05-11 11:14 ` [PATCH 1/5] Introduce yank feature Lukas Straub
2020-05-11 11:14 ` [PATCH 2/5] io/channel.c,io/channel-socket.c: Add " Lukas Straub
2020-05-11 11:51 ` Daniel P. Berrangé
2020-05-11 20:00 ` Lukas Straub
2020-05-12 8:52 ` Daniel P. Berrangé
2020-05-11 11:14 ` [PATCH 3/5] block/nbd.c: " Lukas Straub
2020-05-11 16:19 ` Dr. David Alan Gilbert
2020-05-11 17:05 ` Lukas Straub
2020-05-11 17:24 ` Dr. David Alan Gilbert
2020-05-12 8:54 ` Daniel P. Berrangé
2020-05-15 9:48 ` Lukas Straub
2020-05-15 10:04 ` Daniel P. Berrangé
2020-05-15 10:14 ` Lukas Straub
2020-05-15 10:26 ` Daniel P. Berrangé
2020-05-15 13:03 ` Lukas Straub
2020-05-15 13:45 ` Daniel P. Berrangé
2020-05-11 11:14 ` [PATCH 4/5] chardev/char-socket.c: " Lukas Straub
2020-05-12 8:56 ` Daniel P. Berrangé
2020-05-11 11:14 ` [PATCH 5/5] migration: " Lukas Straub
2020-05-11 11:49 ` [PATCH 0/5] Introduce 'yank' oob qmp command to recover from hanging qemu Daniel P. Berrangé
2020-05-11 12:07 ` Dr. David Alan Gilbert
2020-05-11 12:17 ` Daniel P. Berrangé
2020-05-11 15:46 ` Dr. David Alan Gilbert
2020-05-12 9:32 ` Lukas Straub
2020-05-12 9:43 ` Daniel P. Berrangé [this message]
2020-05-12 18:58 ` Dr. David Alan Gilbert
2020-05-13 8:41 ` Daniel P. Berrangé
2020-05-12 19:42 ` Lukas Straub
2020-05-13 10:32 ` Kevin Wolf
2020-05-13 10:53 ` Dr. David Alan Gilbert
2020-05-13 11:13 ` Kevin Wolf
2020-05-13 11:26 ` Daniel P. Berrangé
2020-05-13 11:58 ` Paolo Bonzini
2020-05-13 12:25 ` Dr. David Alan Gilbert
2020-05-13 12:32 ` Kevin Wolf
2020-05-13 12:18 ` Kevin Wolf
2020-05-13 12:56 ` Dr. David Alan Gilbert
2020-05-13 13:08 ` Daniel P. Berrangé
2020-05-13 13:48 ` Dr. David Alan Gilbert
2020-05-13 13:57 ` Eric Blake
2020-05-13 14:06 ` Kevin Wolf
2020-05-13 14:18 ` Eric Blake
2020-09-01 10:35 ` Markus Armbruster
2020-05-11 19:41 ` Lukas Straub
2020-05-11 18:12 ` Lukas Straub
2020-05-12 9:03 ` Daniel P. Berrangé
2020-05-12 9:06 ` Dr. David Alan Gilbert
2020-05-12 9:09 ` Dr. David Alan Gilbert
2020-05-13 19:12 ` Lukas Straub
2020-05-14 10:41 ` Kevin Wolf
2020-05-14 11:01 ` Dr. David Alan Gilbert
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=20200512094337.GK1191162@redhat.com \
--to=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kwolf@redhat.com \
--cc=lukasstraub2@web.de \
--cc=marcandre.lureau@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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).