From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] xen-2.0: privileged port connections Date: Wed, 23 Mar 2005 13:27:16 -0600 Message-ID: <4241C314.4030902@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ian Pratt Cc: Kurt Garloff , xen-devel , ian.pratt@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org 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