----- 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"
> 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
> 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
> We can get remote console text from the VMs *today*. No need to make
> "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
> This is a solved problem, we just need to connect to the existing
Of course, if you want to keep it at the level it is today, I posted the
solution to the wiki months ago, 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
> 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
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.
> 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
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
Red Hat Israel
+972 9769 2280
vdsm-devel mailing list