Re: [vdsm] [RFC]about the implement of text-based console

2012-09-03 Thread Dan Kenigsberg
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


Re: [vdsm] [RFC]about the implement of text-based console

2012-09-03 Thread Shu Ming

于 2012-8-31 5:26, Adam Litke 写道:

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?


Another thing we want to take care is the security.  Enabling one port 
will make all
console output accessable to the user.  We should take care about this 
to ensure that
one common user can not see the console of other vms belonging to 
another user.







--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shum...@cn.ibm.com or 
shum...@linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC


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