Re: [Qemu-devel] [PATCH 2/7] qemu-char: Allow a chardev to reconnect if disconnected

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Mar 06, 2014 at 12:04:24PM -0600, Corey Minyard wrote:
> On 03/06/2014 01:43 AM, Michael S. Tsirkin wrote:
> >  
> > +@option{reconnect} specifies that if the client socket does not connect at
> > +startup, or if the client socket is closed for some reason (like the other
> > +end exited), wait the given number of seconds and attempt to reconnect.
> > +
> >  TCP and unix socket options are given below:
> >  
> >  @table @option
> > This looks useful but it bothers me that this
> > new option can't be used together with others:
> > server and nowait, which limits its usefulness
> > and would make it harder to extend in the future.
> >
> > - I think that specifying a time-out should be separate from the option to
> > retry.
> > E.g. it might be quite reasonable to retry connecting immediately.
> 
> Maybe, but that would basically disable qemu until the connection came
> back, because it would just be spinning trying to connect.

Why spin? queue the request in bh.

>  That doesn't
> seem like a good idea to me.
> 
> > - it seems to me that if we don't specify nowait, this
> > should stop the VM until reconnect.
> 
> That's an interesting thought.  Currently the option basically implies
> nowait.  It's probably easy to add this, but I'm not sure of the use
> case.

To avoid losing information that would have been sent there.

>  Anyone else have any opinions on this?
> 
> > - I think this can co-exist with server option.
> > E.g. if we detect that the other side closed the socket,
> > start listening again. Or even listen all the time
> > and accept if disconnected.
> 
> IIRC, that's what it does already, even without this patch.  If in
> server mode, I believe you can disconnect and then reconnect a socket
> and it works fine.  So I see no need for this function in server mode.
> 
> >
> > I'd like to suggest we generalize this a bit:
> >
> > When we detect a disconnect, three thinkable things to
> > do would be:
> >     - keep going as if nothing happened
> >         (default for all sockets except monitor)
> >     - exit qemu
> >         (default for monitor)
> >     - retry
> There's also
>     - stop the VM until the socket reconnects.
> 
> I'm not sure why you would want to single out monitor as special. 
> Especially if it is mux-ed into another connection.

it seems useful to make qemu exit when monitor
closes. many programs behave this way, this
makes sure if you lose connection,
the server does not hang around doing nothing.
combine with keepalive socket option,
you get a way to make qemu exit if it loses
networking, which just might help restore networking.

> >
> > When waiting for retry it seems reasonable to
> > either stop the VM or keep going (nowait option).
> >
> > When retrying, it seems reasonable to specify a
> > timeout to make it fail.
> 
> I just don't see why you would want to do this.  It means that the
> connection is gone until the VM starts back up again.

e.g. if socket is used for serial, you might want to stop
VM to avoid losing output.

> One thing I did think of was to add a monitor command to try to
> reconnect.  Then I could understand giving up, since you can get into
> the monitor and kick it back off.
> 
> Thanks,
> 
> -corey
> 

if qemu exits on timeout, then that's also useful
as a way of automatically cleaning up resources
if you lose connection to qemu.
which might help host recover from e.g. oom
situation, and become responsive again.


> > All of the above seem to apply to server
> > and client sockets, with or without nowait option.
> >
> > For clients only, it might be somewhat useful to
> > limit the network traffic caused by reconnects.
> >
> > Thanks,
> > MST
> >
> >> -- 
> >> 1.8.3.1