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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel