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 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

Reply via email to