On 09/04/2012 10:36 PM, Xu He Jie wrote:
On 09/04/2012 06:52 PM, Dan Kenigsberg wrote:
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:
Yes, using a fixed port for all consoles of all VMs seems like a
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
This means that a system administrator needs only to open one port
remote console access. If your initial implementation limits
console access to
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
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
one connection per VM would that simplify the code?
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
currently running the Vm.)
I did not take a close look at your implementation, and did not
this myself, but have you considered using sshd for this? I suppose
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
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
sharable console is like qemu vnc, you can open multiple connection,
but picture is same in all
connection. virsh limited only one user can open console, so I think
make it sharable is more
Hmm... for sshd, I think I missing something. It could be implemented
using sshd in the following way:
Add new system user for that vm on setVmTicket. And change that user's
login program to another program that can redirect console.
To share console among multiple connection, It need that a process
redirects the console to local unix socket, then we can copy console's
output to multiple connection.
This is just in my mind. I am going to give a try. Thanks for your
I gave a try for system sshd. That can works. But I think add user in
system for each vm is't good enough. So I have look in PAM, try to find
a way skip create real user in system, but it doesn't work. Even
we can create virtual user with PAM, we still can't tell sshd use which
user and which login program. That means sshd doesn't support that. And
I didn't find any other solution if I didn't miss something.
I think create user in system isn't good, there have security
implication too, and it will mess the system
configuration, we need be care for clean all the user of vm. So I think
again for implement console server by ourself. I want to ask is that
really unsafe? We just use ssh protocol as transfer protocol. It isn't a
sshd. It didn't access any system resource and shell. It only can
redirect the vm's console after setVmTicket.
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
vdsm-devel mailing list