From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Lukas Straub" <lukasstraub2@web.de>,
"Daniel P. Berrangé" <berrange@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>
Subject: Re: [PATCH 0/5] Introduce 'yank' oob qmp command to recover from hanging qemu
Date: Wed, 13 May 2020 13:25:54 +0100 [thread overview]
Message-ID: <20200513122554.GH3225@work-vm> (raw)
In-Reply-To: <31bb69c3-5149-70cf-7527-54680b1e3f6b@redhat.com>
* Paolo Bonzini (pbonzini@redhat.com) wrote:
> On 13/05/20 13:26, Daniel P. Berrangé wrote:
> > Are you referring to the in-kernel NFS client hangs here ? AFAIK, it is
> > impossible to do anything to get out of those hangs from userspace, because
> > the thread is stuck in an uninterruptable sleep in kernel space.
> >
> > If using the in-QEMU NFS client, then there is a network connection that
> > can be yanked just like the NBD client.
>
> But it's a bad idea to yank it (and also the NBD client) because you're
> not sure which wites have made it to the server (and to the medium) and
> which haven't.
No, that's OK - if you look at the COLO case, and some other cases,
you've got a dead storage device but your redundant pair might be OK;
so it's OK to yank it.
Other similar storage cases are trying to migrate a VM that has one dead
disk, even if you know and accept it's dead and unresponding, you often
can't kill it off if the device is hung.
> Effectively, the in-QEMU NFS client and NBD client are always operating
> in "soft" mode, but we should always treat that as a bug (which cannot
> be fixed) and not a feature for read-write images.
Dave
>
> Paolo
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-05-13 12:27 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é
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 [this message]
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=20200513122554.GH3225@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@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).