On 09/04/2012 03:14 PM, Dan Yasny wrote:
----- Original Message -----
From: "Xu He Jie" <x...@linux.vnet.ibm.com>
To: "Dan Kenigsberg" <dan...@redhat.com>
Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
Sent: Tuesday, 4 September, 2012 10:05:37 AM
Subject: Re: [vdsm] [RFC]about the implement of text-based console
On 09/03/2012 10:33 PM, Dan Kenigsberg wrote:
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.
I have considered using sshd and ssh tunnel. They
can't implement fixed port and share console. Current implement
we can do anything that what we want.
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.
This is interesting. My first thinking is it's easy implement at
client
side. I think we will implement ssh client in webbrowser. Engine will
know the vm was migrated. Engine can tell client reconnect console to
another host. I will try to think about is there any better idea.
If we implement this in a web client, we lose the use case of people without a
GUI, who really have to use the serial text consoles.
If we implement it at client, we have engine command line tools for
user, and we also can implement it in that tools.
If we really need a separate console for every VM, how about we keep a console
server as a VM in the system, and that console server will be running sshd,
with an open session to every VM. And in order to connect to a VMs serial
console, we will actually ssh to this console server VM as a certain console
user.
Thanks for your idea. But I think it's too heavy. The console server VM
will be another centralize management server for managing vm's console.
If we use this, we need think about when engine
setTicket for vm, how vdsm tell the console server VM the ticket, so
there need another communicate method between vm and all vdsm host. And
we need think about the guest os
that running at vm, it's a customize linux, or fully fedora. And we
can't use the text-based console when
vdsm running as standalone.
The way I see this is once a VM gets started, the console server will create a
user/passwd for that VM, and once someone opens an ssh session to the console
server as this user, it will automatically connect the ssh session to the
console on whatever host the target VM is running on. When the VM stops, the
user can be removed.
Regards,
Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
