* Dan Yasny <dya...@redhat.com> [2012-10-15 23:42]:
> 

Hi Dan,

> 
> > > 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
> > > 
> > > On the other hand, maintaining this on multiple hypervisors means
> > > they
> > > should all be up to date, compliant and configured. Not to mention
> > > the
> > > security implications of maintaining an extra access point on lots
> > > of
> > > machines vs a single virtual appliance VM. Bandwidth can be an
> > > issue,
> > > but I doubt serial console traffic can be that heavy especially
> > > since it's there for admin access and not routine work
> > 
> > So, we're replacing a single daemon with a complete operating system
> > ?
> 
> a daemon on all hosts vs a single VM. It looks to me like a single
> access point for consoles can provide less of an attack surface.

All of the hosts already run ssh, you're not turning that off, so the
surface is the same.

> Especially when the virtual appliance comes pre-secured.

I don't even know what that means.  There isn't any magic just because
we call it a virtual appliance.

> 
> > which somehow we'll ensure the service VM is connected and running on
> > all of the networks between the various clusters and datacenters
> > within
> > oVirt so that it can provide a single point of failure to the console
> > of
> > each VM?
> 
> Well, I don't see an SPOF here - a VM can be set up HA, right?
> Moreover, since it doesn't really need to be powerful to push text
> consoles through, you can have one per DC or even cluster, if you have
> too complex a network, a single appliance with minimal amount of RAM
> and a single cpu should not be a problem.
> 
> Thinking about it, not every cluster even requires a serial console
> appliance normally, you'd probably use it in clusters of Linux server
> VMs, but not deploy it with VDI and windows VMs I suppose

All of this is still too much for just tunneling a connection to virsh.
We can get remote console text from the VMs *today*.  No need to make a
"virtual appliance", no need to deploy it, no need to figure out how
many we need.  No need to figure out how to distribute the VM or
dynamically build it.  No need for a new features to have it
implemented.

This is a solved problem, we just need to connect to the existing
solutions.


> > > Am I missing a point here?
> > 
> > Keep it simple.  We can re-use existing services that are already
> > present on all of the hosts:  virsh and ssh for remoting.  By
> > re-using
> > existing services, there is no additional exposure.
> 
> I have always assumed opening ssh on all the hosts is something lots
> of organizations frown upon. I mean I'm all for using sshd if we can't
> come up with something more elegant - it's a known and tested

What I don't want to do is wait around for the best possible solution.
Since we have these tools today, I'd like to use them (virsh + ssh).
Over time, if we develope this more elegant design, we can transition to
that.

> technology, but I have seen enough business demands that ssh be closed
> by default. And remote libvirt access is also something to be very
> careful with

If we were the last users of ssh on hosts, then I'd agree with you.  But
I don't see that being the case.  

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