----- Original Message -----
> From: "Ryan Harper" <ry...@us.ibm.com>
> To: "Dan Yasny" <dya...@redhat.com>
> Cc: "Ryan Harper" <ry...@us.ibm.com>, "Adam Litke" <a...@us.ibm.com>, "VDSM 
> Project Development"
> <vdsm-devel@lists.fedorahosted.org>
> Sent: Tuesday, 16 October, 2012 2:45:25 PM
> Subject: Re: [vdsm] [RFC]about the implement of text-based console
> 
> * 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.

Generally speaking, with ovirt-node based hypervisors you don't need ssh at 
all, and iirc by default it's off. For Fedora hosts you only need ssh during 
setup, afterwards it can also be disabled.

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

When you can supply a prepackaged distribution, with security as tight as 
possible, it's always appealing for the end user to just use it, instead of 
actually doing the tightening manually. 

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

Of course, if you want to keep it at the level it is today, I posted the 
solution to the wiki months ago[1], but if this is to be a product, and a 
product that looks like it was designed for humans, not engineers (C), we need 
to think ahead a bit, stick to making the ssh workaround work for now, and plan 
for something better in the future. 

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

Agreed, if your argument is for the speed of a solution delivery, then I'm all 
for the basic ssh.

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

Suffice it to say, I have seen a few of virtualized DCs where ssh can only be 
started on servers during a maintenance window, and after some ugly 
bureaucracy. 

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


[1] 
http://wiki.ovirt.org/wiki/Features/Serial_Console_in_CLI#Currently_operational_workaround

-- 



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

Reply via email to