On 09/04/2012 09:21 AM, Shu Ming wrote:
User privilege is controled by engine. if the user has privilege, engine
will setticket for it.
于 2012-8-31 5:26, Adam Litke 写道:
On Thu, Aug 30, 2012 at 11:32:02AM +0800, Xu He Jie wrote:
From a usability point of view, I think the fixed port suggestion is
This means that a system administrator needs only to open one port to
remote console access. If your initial implementation limits console
I submited a patch for text-based console
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
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.
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
And setTicket was per vm.
vdsm-devel mailing list