qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Juraj Marcin <jmarcin@redhat.com>,
	qemu-devel@nongnu.org, Fabiano Rosas <farosas@suse.de>
Subject: Re: [PATCH] migration: Apply migration specific keep-alive defaults to inet socket
Date: Tue, 9 Sep 2025 17:58:49 -0400	[thread overview]
Message-ID: <aMCjGVUiM3MY-RM3@x1.local> (raw)
In-Reply-To: <aMBDIwKDxTVrBJBQ@redhat.com>

On Tue, Sep 09, 2025 at 04:09:23PM +0100, Daniel P. Berrangé wrote:
> On Tue, Sep 09, 2025 at 05:01:24PM +0200, Juraj Marcin wrote:
> > From: Juraj Marcin <jmarcin@redhat.com>
> > 
> > Usual system defaults for TCP keep-alive options are too long for
> > migration workload. On Linux, a TCP connection waits idle for 2 hours
> > before it starts checking if the connection is not broken.
> > 
> > Now when InetSocketAddress supports keep-alive options [1], this patch
> > applies migration specific defaults if they are not supplied by the user
> > or the management software. With these defaults, a migration TCP stream
> > waits idle for 1 minute and then sends 5 TCP keep-alive packets in 30
> > second interval before considering the connection as broken.
> > 
> > System defaults can be still used by explicitly setting these parameters
> > to 0.
> 
> IMHO this is not a good idea. This is a very short default, which
> may be fine for the scenario where your network conn is permanently
> dead, but it is going to cause undesirable failures when the network
> conn is only temporarily dead.
> 
> Optimizing defaults for temporary outages is much more preferrable
> as that maximises reliability of migration. In the case of permanent
> outages, it is already possible to tear down the connection without
> waiting for a keep-alive timeout, and liveliness checks can also be
> perform by the mgmt app at a higher level too. The TCP keepalives
> are just an eventual failsafe, and having those work on a long
> timeframe is OK.

For precopy it looks fine indeed, because migrate_cancel should always work
on src if src socket hanged, and even if dest QEMU socket hanged, it can
simply be killed if src QEMU can be gracefully cancelled and rolled back to
RUNNING, disregarding the socket status on dest QEMU.

For postcopy, we could still use migrate_pause to enforce src shutdown().
Initially I thought we have no way of doing that for dest QEMU, but I just
noticed two years ago I added that to dest QEMU for migrate_paused when
working on commit f8c543e808f20b..  So looks like that part is covered too,
so that if dest QEMU socket hanged we can also kick it out.

I'm not 100% sure though, on whether shutdown() would always be able to
successfully kick out the hanged socket while the keepalive is ticking.  Is
it guaranteed?

I also am not sure if that happens, whether libvirt would automatically do
that, or provide some way so the user can trigger that.  The goal IIUC here
is we shouldn't put user into a situation where the migration hanged but
without any way to either cancel or recover.  With the default values Juraj
provided here, it makes sure the hang won't happen more than a few minutes,
which sounds like a sane timeout value.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2025-09-09 22:01 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 [this message]
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é
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=aMCjGVUiM3MY-RM3@x1.local \
    --to=peterx@redhat.com \
    --cc=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=jmarcin@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 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).