This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xen-2.0: privileged port connections
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Wed, 23 Mar 2005 13:27:16 -0600
Cc: Kurt Garloff <garloff@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxxx>, ian.pratt@xxxxxxxxxxxx
Delivery-date: Wed, 23 Mar 2005 19:37:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3822@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: IBM
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E3822@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
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.

Anthony Liguori

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

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