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 email@example.com https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel