qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Lukas Straub <lukasstraub2@web.de>, qemu-devel <qemu-devel@nongnu.org>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-block <qemu-block@nongnu.org>,
	"Juan Quintela" <quintela@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>
Subject: Re: [PATCH v11 1/7] Introduce yank feature
Date: Tue, 1 Dec 2020 15:05:03 -0600	[thread overview]
Message-ID: <69324063-cc5e-590c-a905-718ca606b5cf@redhat.com> (raw)
In-Reply-To: <c702eeae-300b-deee-5809-7ea6ed9ec8f1@redhat.com>

On 12/1/20 2:43 PM, Eric Blake wrote:
> On 11/15/20 5:36 AM, Lukas Straub wrote:
>> The yank feature allows to recover from hanging qemu by "yanking"
> 
> "allows to $verb" is not idiomatic English, better is "allows $subject
> to verb" or "allows ${verb}ing".  In this case, I suggest "The yank
> feature allows the recovery of a hung qemu by "yanking" at various parts".
> 
>> at various parts. Other qemu systems can register themselves and
>> multiple yank functions. Then all yank functions for selected
>> instances can be called by the 'yank' out-of-band qmp command.
>> Available instances can be queried by a 'query-yank' oob command.
>>
>> Signed-off-by: Lukas Straub <lukasstraub2@web.de>
>> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
>> Reviewed-by: Markus Armbruster <armbru@redhat.com>
>> ---
> 
>> +# @YankInstanceType:
>> +#
>> +# An enumeration of yank instance types. See @YankInstance for more
>> +# information.
>> +#
>> +# Since: 6.0
>> +##
>> +{ 'enum': 'YankInstanceType',
>> +  'data': [ 'block-node', 'chardev', 'migration' ] }
>> +
> 
>> +##
>> +# @YankInstance:
>> +#
>> +# A yank instance can be yanked with the @yank qmp command to recover from a
>> +# hanging QEMU.
>> +#
>> +# Currently implemented yank instances:
>> +#  - nbd block device:
>> +#    Yanking it will shut down the connection to the nbd server without
>> +#    attempting to reconnect.
> 
> Mismatch in documentation; I presume it gets cleaned up later in the
> series, in which case I can live with this patch as-is.

Oh, I see.  'block-node' refers to a block node being served over NBD.
So if you have multiple NBD devices, you choose which one or more nodes
are yanked, rather than blindly yanking all of them at once.  I just
found it odd that we mention 'nbd' here but not in the enum; on the
other hand, we may have more than just NBD networked devices where other
types of network-enabled block nodes (ceph, sheepdog, gluster...) might
also add yank support.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2020-12-01 21:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-15 11:35 [PATCH v11 0/7] Introduce 'yank' oob qmp command to recover from hanging qemu Lukas Straub
2020-11-15 11:36 ` [PATCH v11 1/7] Introduce yank feature Lukas Straub
2020-12-01 20:43   ` Eric Blake
2020-12-01 21:05     ` Eric Blake [this message]
2020-11-15 11:36 ` [PATCH v11 2/7] block/nbd.c: Add " Lukas Straub
2020-12-01 20:50   ` Eric Blake
2020-12-02 12:18   ` Vladimir Sementsov-Ogievskiy
2020-12-02 12:34     ` Lukas Straub
2020-11-15 11:36 ` [PATCH v11 3/7] chardev/char-socket.c: " Lukas Straub
2020-11-15 11:36 ` [PATCH v11 4/7] migration: " Lukas Straub
2020-11-15 11:36 ` [PATCH v11 5/7] io/channel-tls.c: make qio_channel_tls_shutdown thread-safe Lukas Straub
2020-11-15 11:36 ` [PATCH v11 6/7] io: Document qmp oob suitability of qio_channel_shutdown and io_shutdown Lukas Straub
2020-11-15 11:36 ` [PATCH v11 7/7] tests/test-char.c: Wait for the chardev to connect in char_socket_client_dupid_test Lukas Straub
2020-12-01 16:34 ` [PATCH v11 0/7] Introduce 'yank' oob qmp command to recover from hanging qemu Markus Armbruster

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=69324063-cc5e-590c-a905-718ca606b5cf@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=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).