* 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.

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.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to