* Dan Kenigsberg <dan...@redhat.com> [2012-09-04 05:53]:
> On Tue, Sep 04, 2012 at 03:05:37PM +0800, Xu He Jie wrote:
> > On 09/03/2012 10:33 PM, Dan Kenigsberg wrote:
> > >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.
> > I have considered using sshd and ssh tunnel. They
> > can't implement fixed port and share console.
> 
> Would you elaborate on that? Usually sshd listens to a fixed port 22,
> and allows multiple users to have independet shells. What do you mean by
> "share console"?
> 
> > Current implement
> > we can do anything that what we want.
> 
> Yes, it is completely under our control, but there are down sides, too:
> we have to maintain another process, and another entry point, instead of
> configuring a universally-used, well maintained and debugged
> application.

Think of the security implications of having another remote shell
access point to a host.  I'd much rather trust sshd if we can make it
work.


> 
> Dan.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to