[ovirt-users] Thinking loud about VM's serial console access

[Alon Bar-Lev]

----- Original Message -----
> From: "Jiri Belka" <jbelka at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: users at ovirt.org
> Sent: Monday, October 20, 2014 3:56:12 PM
> Subject: Re: [ovirt-users] Thinking loud about VM's serial console access
> 
> On Mon, 20 Oct 2014 08:40:34 -0400 (EDT)
> Alon Bar-Lev <alonbl at redhat.com> wrote:
> 
> > 
> > 
> > ----- Original Message -----
> > > From: "Jiri Belka" <jbelka at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: users at ovirt.org
> > > Sent: Monday, October 20, 2014 2:40:01 PM
> > > Subject: Re: [ovirt-users] Thinking loud about VM's serial console access
> > > 
> > > On Sat, 18 Oct 2014 14:39:12 -0400 (EDT)
> > > Alon Bar-Lev <alonbl at redhat.com> wrote:
> > > 
> > > > 
> > > > Please read [1].
> > > > 
> > > > I am unsure about concurrent access, this should be done using ssh
> > > > bridge
> > > > and now low level solution.
> > > > 
> > > > Thanks,
> > > > Alon
> > > > 
> > > > [1] http://www.ovirt.org/Features/Serial_Console
> > > 
> > > How will it behave when:
> > > 
> > > - VM is being snapshotted?
> > > - VM is being migrated?
> > > - VM is suspended?
> > > - VM is being (cold)rebooted?
> > > 
> > > At least for last two I suppose the serial console session will be
> > > interrupted.
> > > 
> > > VMWare uses extended communication to inform virtual serial port
> > > concentrator about various action of a VM, thus "proxy" doesn't drop
> > > serial connections.
> > 
> > there is no reason why the proxy cannot retry for a while and reconnect to
> > the new instance.
> > however this will not be provided at first nor it is that important as
> > client can always implement reconnect at its side, and handle this just
> > like any other network failure.
> 
> OK, I'm reading this as you haven't tested it with these actions.

how can I test something that is not implemented?

> With real serial console one doesn't need to re-plug cable to get the
> console... Thus I'm not interested anymore in the topic.

once you tunnel serial over network protocol, every failure of network protocol applies to the tunnel. this is just like modem hangup or any other hardware failure. unless you wish to implement proprietary client side component instead of standard ssh utility, a component that retry to establish connection, this custom component can be provided regardless of the solution.

a software that assumes that a connection is always available will fail to provide service after failure, at any medium.

Alon