From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: Juraj Marcin <jmarcin@redhat.com>,
qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>,
Jiri Denemark <jdenemar@redhat.com>
Subject: Re: [PATCH] migration: Apply migration specific keep-alive defaults to inet socket
Date: Thu, 18 Sep 2025 16:52:29 +0100 [thread overview]
Message-ID: <aMwqvbFzGlsX23C7@redhat.com> (raw)
In-Reply-To: <aMwg-ROjbDL_z_EM@x1.local>
On Thu, Sep 18, 2025 at 11:10:49AM -0400, Peter Xu wrote:
> On Thu, Sep 18, 2025 at 03:45:21PM +0100, Daniel P. Berrangé wrote:
> > There needs to be a way to initiate post-copy recovery regardless
> > of whether we've hit a keepalive timeout. Especially if we can
> > see one QEMU in postcopy-paused, but not the other side, it
> > doesn't appear to make sense to block the recovery process.
> >
> > The virDomainJobCancel command can do a migrate-cancel on the
> > src, but it didn't look like we could do the same on the dst.
> > Unless I've overlooked something, Libvirt needs to gain a way
> > to explicitly force both sides into the postcopy-paused state,
> > and thus be able to immediately initiate recovery.
>
> Right, if libvirt can do that then problem should have been solved too.
>
> > I'm fine with turning on keepalives on the socket, but IMHO the
> > out of the box behaviour should be to honour the kernel default
> > tunables unless the admin decides they want different behaviour.
> > I'm not seeing a rational for why the kernel defaults should be
> > forceably overridden in QEMU out of the box.
>
> IMHO the rational here is that the socket here is in a special state and
> for special purpose. So we're not trying to change anything globally for
> qemu (without knowing what the socket is), but only this specific type of
> socket that is used for either precopy or postcopy live migrations.
>
> It's special because it's always safe to have a more aggresive
> disconnection, and might be preferred versus very lengthy hangs (if
> assuming libvirt doesn't yet have way to stop the hang), especially for a
> postcopy phase.
I've already described up-thread that it is not guaranteed safe to
have aggressive disconnection. It is often safe, but there is
definitely non-negligible risk in prematurely terminating a migration
connection.
With 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:[~2025-09-18 15:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 15:01 [PATCH] migration: Apply migration specific keep-alive defaults to inet socket Juraj Marcin
2025-09-09 15:09 ` Daniel P. Berrangé
2025-09-09 21:58 ` Peter Xu
2025-09-10 7:10 ` Daniel P. Berrangé
2025-09-10 16:36 ` Peter Xu
2025-09-12 10:20 ` Daniel P. Berrangé
2025-09-12 15:02 ` Peter Xu
2025-09-15 18:23 ` Daniel P. Berrangé
2025-09-15 20:05 ` Peter Xu
2025-09-18 14:16 ` Juraj Marcin
2025-09-18 14:45 ` Daniel P. Berrangé
2025-09-18 15:10 ` Peter Xu
2025-09-18 15:52 ` Daniel P. Berrangé [this message]
2025-09-19 11:59 ` Jiří Denemark
2025-09-19 12:00 ` Daniel P. Berrangé
2025-09-19 12:10 ` Jiří Denemark
2025-09-19 12:04 ` Jiří Denemark
2025-09-10 12:05 ` Juraj Marcin
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=aMwqvbFzGlsX23C7@redhat.com \
--to=berrange@redhat.com \
--cc=farosas@suse.de \
--cc=jdenemar@redhat.com \
--cc=jmarcin@redhat.com \
--cc=peterx@redhat.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.