Re: [PATCH] xen-2.0: privileged port connections

[Anthony Liguori <aliguori@us.ibm.com>]

Ian Pratt wrote:

>There are a couple of other issues that we should consider at the same
>time. I've heard a couple of users complain that they find our model of
>exporting serial consoles confusing: when they quit a console session
>and reconnect they find that they are still logged in. Worse, if they
>were running vi when they quit the session they get very confused when
>connecting back in. I guess if you're not used to a serial console then
>you would find the behaviour confusing. Should we be doing some more
>complex terminal emulation?
>  
>
Perhaps we could export the console via a pty and then create a screen 
session by executing the equivalent of "screen vm-console domid".

Clients can then connect to it by executing screen -x (instead of 
connecting directly to the pty) and our client could translate C-] to 
C-a C-d to detach from the screen.  Any reconnects will perserve the 
screen of the previous session.

This way, we can still have minimalistic toolchains that provide serial 
style consoles.

>The other issue we need to consider is VM migration. Ideally, it should
>be completely transparent to someone with a console connection open
>(just like it is to someone with an ssh connection open). There are two
>ways to do this, either have a console server machine for all the nodes
>in a cluster, or hide the disconnect/reconnect in the client terminal
>program. If we are using a 'standard' program on the client side (e.g.
>ssh in an xterm), then the former is preferable. If for some reason we
>choose to use a custom program (e.g. son-of-xencons) then we could
>reasonably hide the relocation.
>  
>
One solution would be to do console-forwarding underneath the pty.

If you're migrating from system A to system B and you are using ptys, 
your daemon that's exposing the pty on A simply connects to system B via 
TCP and forwards any data from system B's pty to system A's pty.  This 
forwarding chains nicely (albiet naively) if the vm hops across multiple 
machines in a cluster without closing a console.  You could also be 
smarter and have system B signal system A to reconnect to system C if 
the vm is migrated from system B to system C.

Of course, the naive chaining allows your hopping to cross networks such 
that if system A and B are on one network, and B and C are on a 
different network, it all still works.

A cluster-aware toolchain could forward any new console requests 
directly to system B and the forwarded console would disappear once any 
clients still connected to A disconnect.

This is just one idea.  There may be a better way.

Regards,
Anthony Liguori

>I'd like to see a decent discussion of how best to do consoles before
>changing the status quo. 
>
>Thanks,
>Ian 
>
>
> 
>
>  
>



-------------------------------------------------------
This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) & Windows Mobile(tm) platforms, applications & content.  Register
by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click