----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Dan Yasny" <dya...@redhat.com> > Cc: "Xu He Jie" <x...@linux.vnet.ibm.com>, "VDSM Project Development" > <vdsm-devel@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" <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 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 > (well, unless qemu adds builtin ssh support to the serial port) That would be great, but... > -- Regards, Dan Yasny Red Hat Israel +972 9769 2280 _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
