From: David Ahern <dsahern@gmail.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] PATCH: enabling TCP keepalives - v3
Date: Fri, 01 May 2009 06:49:33 -0600 [thread overview]
Message-ID: <49FAEFDD.2070002@gmail.com> (raw)
In-Reply-To: <20090501113204.GA10763@amd.home.annexia.org>
Richard W.M. Jones wrote:
> On Thu, Apr 30, 2009 at 01:40:42PM -0600, David Ahern wrote:
>> Did not see a response to the last version.
>>
>> This patch enables TCP keepalives on VNC connections and TCP-based char
>> devices.
>>
>> Default parameters have keep alive probes sent after 60-seconds of idle
>> time. Probes are sent every 12 seconds with the connection resetting
>> after 5 failed probes (ie., connection is closed if no response received
>> in 60-seconds).
>
> IMHO this should be optional, and firmly default to _OFF_. Brief
> network outages shouldn't result in connections failing all over the
> place. In addition, does this negatively impact migration?
It's not a matter of connections failing; it's a matter of cleaning them
up for a variety of reasons. Besides the VPN example which motivated
this patch (i.e, VPN connection drops and when re-established you get a
differnt IP), there are a lot of networks with very aggressive firewalls
(e.g., 60-minute timers). Without some sort of keepalive mechanisms
those firewalls will close the holes and the connections will hang.
I'll take a look at adding yet another command line option to enable
this. sshd for example, does not specify individual timer and count
values, only on/off. So for char devices, how about something like:
-serial tcp:<ip>:<port>[,server][,nowait][,tcpkeep]
-vnc display[,tcpkeep]
If timer and counters are to be configurable, I could do something like
tcpkeep=i,j,k, where i is the idle time, j is the interval for sending
probes and k is the count of missed probes.
I have not run, and not setup to run, migration tests. Will migrations
work as expected if the network were to stall for 2 minutes? The current
patch would only drop the connection after 2 minutes of no response.
david
>
> Rich.
>
next prev parent reply other threads:[~2009-05-01 12:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-30 19:40 [Qemu-devel] PATCH: enabling TCP keepalives - v3 David Ahern
2009-05-01 11:32 ` Richard W.M. Jones
2009-05-01 12:23 ` Jamie Lokier
2009-05-01 12:49 ` David Ahern [this message]
2009-05-01 15:23 ` Daniel P. Berrange
2009-05-01 15:47 ` David Ahern
2009-05-01 17:21 ` Richard W.M. Jones
2009-05-05 1:31 ` Jamie Lokier
2009-05-05 2:59 ` David Ahern
2009-05-01 15:52 ` Avi Kivity
2009-05-01 16:11 ` John Haxby
2009-05-05 1:35 ` Jamie Lokier
2009-05-01 14:43 ` Anthony Liguori
2009-05-01 14:47 ` David Ahern
2009-05-01 14:51 ` Anthony Liguori
2009-05-01 15:16 ` Paul Brook
2009-05-01 15:57 ` Anthony Liguori
2009-05-01 16:04 ` Paul Brook
2009-05-01 16:11 ` David Ahern
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=49FAEFDD.2070002@gmail.com \
--to=dsahern@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@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 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.