From: "Itamar Heim" <iheim(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
Cc: "Xu He Jie" <xuhj(a)linux.vnet.ibm.com>, "VDSM Project
Development" <vdsm-devel(a)lists.fedorahosted.org>
Sent: Tuesday, 4 September, 2012 10:39:18 AM
Subject: Re: [vdsm] [RFC]about the implement of text-based console
On 09/04/2012 10:14 AM, Dan Yasny wrote:
>
>
> ----- Original Message -----
>> From: "Xu He Jie" <xuhj(a)linux.vnet.ibm.com>
>> To: "Dan Kenigsberg" <danken(a)redhat.com>
>> Cc: "VDSM Project Development"
<vdsm-devel(a)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 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.
>
> 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.
i'm less concerned by single or multiple ports, since we already do
multiple ports for vnc/spice.
the main question to me is can we easily frontend the serial of the
VM
by an ssh server authenticating based on the SetVmTicket flow (which
qemu doesn't support).
We can connect directly to libvirt instead of qemu here. a remote call for `virsh console`
with a VM name should work. We don't want to expose that to anyone directly, but if we
use a console server, it can have access to connect to virsh console, and the user will go
in to the console server by ssh
That would be great, but...