----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Ryan Harper" <ry...@us.ibm.com> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org> > Sent: Sunday, 21 October, 2012 11:17:24 AM > Subject: Re: [vdsm] [RFC]about the implement of text-based console > > On 10/19/2012 04:31 PM, Ryan Harper wrote: > > * Itamar Heim <ih...@redhat.com> [2012-10-18 14:17]: > >> On 10/18/2012 09:13 PM, Dave Allan wrote: > >>> On Thu, Oct 18, 2012 at 02:21:44AM +0200, Itamar Heim wrote: > >>>> On 10/15/2012 07:41 PM, Dave Allan wrote: > >>>>> On Fri, Oct 12, 2012 at 11:25:47AM -0500, Ryan Harper wrote: > >>>>>> * Adam Litke <a...@us.ibm.com> [2012-10-12 08:13]: > >>>>>>> On Fri, Oct 12, 2012 at 04:55:20PM +0800, Zhou Zheng Sheng > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> on 09/04/2012 22:19, Ryan Harper wrote: > >>>>>>>>> * Dan Kenigsberg <dan...@redhat.com> [2012-09-04 05:53]: > >>>>>>>>>> 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: > >>>>>>>>>>>>> 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. > >>>>>>>>>> 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 > >>>>>>>>>> "share console"? > >>>>>>>>>> > >>>>>>>>>>> Current implement > >>>>>>>>>>> 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 > >>>>>>>>>> application. > >>>>>>>>> Think of the security implications of having another remote > >>>>>>>>> shell > >>>>>>>>> access point to a host. I'd much rather trust sshd if we > >>>>>>>>> can make it > >>>>>>>>> work. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Dan. > >>>>>>>> > >>>>>>>> At first glance, the standard sshd on the host is stronger > >>>>>>>> and more > >>>>>>>> robust than a custom ssh server, but the risk using the host > >>>>>>>> sshd is > >>>>>>>> high. If we implement this feature via host ssd, when a > >>>>>>>> hacker > >>>>>>>> attacks the sshd successfully, he will get access to the > >>>>>>>> host shell. > >>>>>>>> After all, the custom ssh server is not for accessing host > >>>>>>>> shell, > >>>>>>>> but just for forwarding the data from the guest console (a > >>>>>>>> host > >>>>>>>> /dev/pts/X device). If we just use a custom ssh server, the > >>>>>>>> code in > >>>>>>>> this server only does 1. auth, 2. data forwarding, when the > >>>>>>>> hacker > >>>>>>>> attacks, he just gets access to that virtual machine. Notice > >>>>>>>> that > >>>>>>>> there is no code written about login to the host in the > >>>>>>>> custom ssh > >>>>>>>> server, and the custom ssh server can be protected under > >>>>>>>> selinux, > >>>>>>>> only allowing it to access /dev/pts/X. > >>>>>>>> > >>>>>>>> In fact using a custom VNC server in qemu is as risky as a > >>>>>>>> custom > >>>>>>>> ssh server in vdsm. If we accepts the former one, then I can > >>>>>>>> accepts > >>>>>>>> the latter one. The consideration is how robust of the > >>>>>>>> custom ssh > >>>>>>>> server, and the difficulty to maintain it. In He Jie's > >>>>>>>> current > >>>>>>>> patch, the ssh auth and transport library is an open-source > >>>>>>>> third-party project, unless the project is well maintained > >>>>>>>> and well > >>>>>>>> proven, using it can be risky. > >>>>>>>> > >>>>>>>> So my opinion is using neither the host sshd, nor a custom > >>>>>>>> ssh > >>>>>>>> server. Maybe we can apply the suggestion from Dan Yasny, > >>>>>>>> running a > >>>>>>>> standard sshd in a very small VM in every host, and forward > >>>>>>>> data > >>>>>>> >from this VM to other guest consoles. The ssh part is in the > >>>>>>> >VM, > >>>>>>>> then our work is just forwarding data from the VM via virto > >>>>>>>> serial > >>>>>>>> channels, to the guest via the pty. > >>>>>>> > >>>>>>> I really dislike the idea of a service VM for something as > >>>>>>> fundamental as a VM > >>>>>>> console. The logistics of maintaining such a VM are a > >>>>>>> nightmare: provisioning, > >>>>>>> deployment, software upgrades, HA, etc. > >>>>>>> > >>>>>>> Maybe we can start simple and provide console access locally > >>>>>>> only. What sort of > >>>>>>> functionality would the vdsm api need to provide to enable > >>>>>>> only local access to > >>>>>>> the console? Presumably, it would set up a connection and > >>>>>>> provide the user with > >>>>>>> a port/pty to use to connect locally. For now it would be > >>>>>>> "BYOSSH - bring your > >>>>>>> own SSH" as clients would need to access the hosts with > >>>>>>> something like: > >>>>>>> > >>>>>>> ssh -t <host> "<connect command>" > >>>>>>> > >>>>>>> The above command could be wrapped in a vdsm-tool command. > >>>>>> > >>>>>> I think we have a patch that does local-only here but using > >>>>>> virsh > >>>>>> > >>>>>> http://gerrit.ovirt.org/#/c/8041/ > >>>>>> > >>>>>> I'd prefer to let the user tunnel that output over ssh if they > >>>>>> need to. > >>>>> > >>>>> I haven't been following this thread all that closely, so > >>>>> perhaps this > >>>>> idea has already been mentioned, but would the libvirt ssh > >>>>> transport > >>>>> help with this situation, ie, > >>>>> > >>>>> virsh -c qemu+ssh://root@host/system console some_vm > >>>> > >>>> i hope this would work/be simple. some questions: > >>>> 1. can clients script with/over this method like they can with > >>>> ssh? > >>> > >>> The serial console API does not do things like > >>> > >>> $ ssh root@bar 'hostname' > >>> bar > >>> > >>> since it's just a stream containing the console i/o, but I'm not > >>> sure > >>> that answers your question. Can you give me an example of what > >>> kind > >>> of script you're thinking of? > >>> > >>>> 2. can we make it support tickets like we have for spice/vnc? > >>> > >>> The console API will use any authentication that the libvirtd on > >>> the > >>> target will accept, so it could authenticate the same credentials > >>> as > >>> vdsm. console does require a read-write connection to libvirt. > >>> > >>> There's example python code in the libvirt git tree: > >>> > >>> http://libvirt.org/git/?p=libvirt.git;a=blob;f=examples/python/consolecallback.py > >> > >> I don't think giving end-users direct read/write access to libvirt > >> is the way to go (even with libvirt having a permission model). > >> we don't manage users/credentials at that level, only tickets. > > > > I agree with the additional creditials, I'd prefer not to have to > > manage > > this. > > > >> the thing i like about the spice approach is it goes to qemu > >> process, via channels we already have with clients (spice). > > > > We already have a device that works without additional clients or > > channels, the pty on the host the VM runs. > > > > The only question left is how to provide remote access to this. In > > the > > short term, we don't need remoting to make use of it. Having vdsm > > invoke virsh console for a local vdsClient is sufficent to start > > with. > > > > For remoting, something we've been discussing is a > > console_read/console_write API call which would be something that a > > management application could consume and re-use some of those AJAX > > web-console widgets. > > I thought the interesting use case for serial console was ability to > script to it remotely, rather than a UI (which vnc/spice would give > you > anyway)?
Actually, the current production use cases (the ones I wrote the workaround for) are for a highly secure, no-GUI environment, where guest serial consoles are the only way to access a guest console. Scripting was never mentioned (though it might be another cool use case) > > > > > w.r.t permissions for console_read/console_write we could use the > > setTicket mechanism to enable access to those verbs. read/write > > API > > should also work well with VM migration. > > > > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > -- 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
