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

vdsm-devel mailing list

Reply via email to