On Mon, Oct 15, 2012 at 03:21:23PM +0200, David Jaša wrote:
> Adam Litke píše v Po 15. 10. 2012 v 08:07 -0500:
> > On Mon, Oct 15, 2012 at 04:40:00AM -0400, Dan Yasny wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Adam Litke" <a...@us.ibm.com>
> > > > To: "Zhou Zheng Sheng" <zhshz...@linux.vnet.ibm.com>
> > > > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
> > > > Sent: Friday, 12 October, 2012 3:10:57 PM
> > > > Subject: Re: [vdsm] [RFC]about the implement of text-based console
> > > > 
> > > > 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.
> > > 
> > > Why? It really sounds like an easy path to me - provisioning of a virtual
> > > appliance is supposed to be simple, upgrades not necessary - same as with
> > > ovirt-node, just a bit of config files preserved and the rest simply 
> > > replaced,
> > > and HA is taken care of by the platform
> > 
> > How do you get the VM image to the hypervisor in the first place?  Is this 
> > an
> > extra step at install time that the admin must follow?  You say that the VM 
> > is
> > simple and will not need to be upgraded but I don't completely believe you.
> > Inevitably, we will need to upgrade that VM (to fix a bug someone finds, or 
> > sync
> > it up with the latest vdsm/engine code, or fix a security flaw).  How will 
> > we
> > conduct that upgrade?  How do we handle a host going in and out of 
> > Maintenance
> > mode?
> > 
> 
> IMO you could generate such VM from host system similarly to how
> libvirt-sandbox works. 
> 
> Also CCing Dan who is author of libvirt-sandbox

In fact you do not even generate a VM image at all. The key idea behind 
virt-sandbox
is that you do *not* want the extra overhead of maintaining extra OS 
installations,
precisely because of the upgrade pain described above.

Thus, the way virt-sandbox works is that the VM boots using host's filesystem 
as the
guest root filesystem (in readonly mode). You then tell virt-sandbox to 
over-mount a
private writable filesystem in certain desired places. So for running SSH 
daemon in
a "service VM" you could do something like

 # mkdir -p /var/lib/vdsm/sshd-service/$VMUUID/etc/ssh
 # cp ...some template sshd_config... 
/var/lib/vdsm/sshd-service/$VMUUID/etc/ssh/sshd_config
 # virt-sandbox --host-bind /etc/ssh=/var/lib/vdsm/sshd-service/$VMUUID/etc/ssh 
/usr/bin/sshd


So the only extra thing you are maintaining here is the SSH daemon config.
Depending on how paranoid you are you do not even need to use KVM for your
service VMs - you can tell virt-sandbox to make use of LXC which gives you
even lower overheads. You still get a sVirt confined VM, but you share the
same kernel.

When you upgrade SSH on the host OS, all you need todo is restart the
service VMs & they'll be running the new code.

IMHO the kind of scenario you are describing here is quite a good fit for
the virt-sandbox concept - you get the security benefits of virtualization
without the management pain of extra OS installs.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to