| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] xen-2.0: privileged port connections
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
|
|
|
| |
|
Home