From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Xu He Jie" <xuhj(a)linux.vnet.ibm.com>
Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>
Sent: Monday, September 3, 2012 10:33:42 AM
Subject: Re: [vdsm] [RFC]about the implement of text-based console
On Thu, Aug 30, 2012 at 04:26:31PM -0500, Adam Litke wrote:
> On Thu, Aug 30, 2012 at 11:32:02AM +0800, Xu He Jie wrote:
> > Hi,
> >
> > I submited a patch for text-based console
> >
http://gerrit.ovirt.org/#/c/7165/
> >
> > the issue I want to discussing as below:
> > 1. fix port VS dynamic port
> >
> > Use fix port for all VM's console. connect console with 'ssh
> > vmUUID@ip -p port'.
> > Distinguishing VM by vmUUID.
> >
> >
> > The current implement was vdsm will allocated port for console
> > dynamically and spawn sub-process when VM creating.
> > In sub-process the main thread responsible for accept new
> > connection
> > and dispatch output of console to each connection.
> > When new connection is coming, main processing create new thread
> > for
> > each new connection. Dynamic port will allocated
> > port for each VM and use range port. It isn't good for firewall
> > rules.
> >
> >
> > so I got a suggestion that use fix port. and connect console
> > with
> > 'ssh vmuuid@hostip -p fixport'. this is simple for user.
> > We need one process for accept new connection from fix port and
> > when
> > new connection is coming, spawn sub-process for each vm.
> > But because the console only can open by one process, main
> > process
> > need responsible for dispatching console's output of all vms and
> > all
> > connection.
> > So the code will be a little complex then dynamic port.
> >
> > So this is dynamic port VS fix port and simple code VS complex
> > code.
>
> >From a usability point of view, I think the fixed port suggestion
> >is nicer.
> This means that a system administrator needs only to open one port
> to enable
> remote console access. If your initial implementation limits
> console access to
> one connection per VM would that simplify the code?
Yes, using a fixed port for all consoles of all VMs seems like a
cooler
idea. Besides the firewall issue, there's user experience: instead of
calling getVmStats to tell the vm port, and then use ssh, only one
ssh
call is needed. (Taking this one step further - it would make sense
to
add another layer on top, directing console clients to the specific
host
currently running the Vm.)
I did not take a close look at your implementation, and did not
research
this myself, but have you considered using sshd for this? I suppose
you
can configure sshd to collect the list of known "users" from
`getAllVmStats`, and force it to run a command that redirects VM's
console to the ssh client. It has a potential of being a more robust
implementation.
We need to consider what implications this might have for security on the node - for
example common criteria certification.
I"ll see if we can pull someone from Red Hat's security team into the discussion
who would understand the implications.
We may want to start thinking about migration. It would be great if
we
could have a smart console client that connects to the source and
destination consoles, and moves to the destination on-line, without
loosing a character.
Regards,
Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel