----- Original Message -----
> From: "Dan Kenigsberg" <dan...@redhat.com>
> To: "Xu He Jie" <x...@linux.vnet.ibm.com>
> Cc: "VDSM Project Development" <vdsm-devel@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@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to