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: "Anthony Liguori" <aliguori@xxxxxxxxxx>, "Kurt Garloff" <garloff@xxxxxxx>
Subject: RE: [Xen-devel] [PATCH] xen-2.0: privileged port connections
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 23 Mar 2005 18:51:00 -0000
Cc: "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxxxx>, <ian.pratt@xxxxxxxxxxxx>
Delivery-date: Wed, 23 Mar 2005 19:02:34 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Thread-index: AcUv0hYDSwsjKeI6QoG/09tyAWhuVAABOHdg
Thread-topic: [Xen-devel] [PATCH] xen-2.0: privileged port connections
> Would a patch to change Xend to use pty's for consoles be 
> accepted?  xm 
> console can be invoked via ssh to support remote consoles..

I'm in favour of this in principle, but I think we need to think through
precisely how the pty approach would work. 

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?

Using something like 'screen' in dom0 might help, so at least upon
reconnecting the console window is 'refreshed' to show its previous

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.

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_idh83&alloc_id149&op=click
Xen-devel mailing list