On Tue, Oct 30, 2007 at 02:33:45PM -0400, Daniel Risacher wrote:
> Thanks for the thoughtful replies.
>
> I agree with the other posters that an administation best practice
> would be to run as few services as possible in the host, but
> I think that this is advice that is orthogonal to how a virtual
> server environment should work.
why do you think so?
> In my particular situation, I had an existing server that has a lot of
> services running, and wanted to add the Zimbra Collaboration Suite,
> which is packaged with its own mail server, web server, etc., etc.
> Many of the Zimbra services come pre-configured to talk to each other
> via the localhost address, and overlap with the existing services that
> I was already running on the host. I followed instructions on the web
> to make this work (with some success), but was left feeling like this
> was the sort of de-confliction that a virtualization solution should
> have been helping me avoid.
>
> I think Daniel Hokka Zakrisson's reply below summarizes things well by
> saying:
>
> It just goes against the general Linux-VServer paradigm. As far as
> possible, we do isolation by limiting the guest to a subset of the
> host's resources. As such, limiting the host's ability to use the IP
> addresses it wants is just not something that fits in.
>
> The paradigm that I was expecting was that when resources are
> dedicated to the guest - they stop being the "hosts" resources, except
> as a pass-through. I.e. an IP address that belongs to a guest, belongs
> to the GUEST, and never the host - at least from the application's
> perspective.
>
> This is not a criticism of VServer - just that my expectations were
> different. In hindsight, I think OpenVZ might have been a better
> choice for my situation.
maybe ... maybe not ...
[stuff zapped]
> > > How I think it SHOULD work
> > > --------------------------
> > >
> > > I start from the general assumption that a virtual machine
~~~~~~~~~~~~~~~~
if you were looking for a virtual machine, why didn't
you choose Xen or QEMU or Virtualbox for example?
> > > should seem like an isolated, independent machine as much as
> > > possible.
this is definitely the goal if all you care about
is running (possibly broken) apps in their known
environment, because e.g. you do not have the source
code available or do not want to bother ...
> > > It seems to be a desirable goal to minimize the amount
> > > of application-level configuration tomfoolery that is
> > > required.
yes, but there are different and more important
goal, like: minimize the overhead, reduce the
resource consumption, simplify administration
and much more ...
> > > Based on this...
> >
> > You only have to configure the host, which shouldn't really be running
> > any services in the first place.
> >
> > > * Bind attempts to IPADDR_ANY should not fail based on
> > > something happening in a different security context.
this is true, and correct, and also what Linux-VServer
is doing: binds in any context, which doesn't share IPs
with another context, will be completely isolated and
unaffected. note: the host is not a security context
> > > I.e. Bind attempts to
> > > IPADDR_ANY from the host should be able to succeed, even if a guest
> > > is already listening on that port, and likewise bind attempts to
> > > IPADDR_ANY from a guest should be able to succeed, even if the host
> > > is already listening to IPADDR_ANY
which would lead to quite confusing behaviour once
a connection arrives at the host/guest, because it
would be pure luck which socket will be chosen ...
> > So when someone connects to it, where should they be directed? You can't
> > have multiple listeners on the same IP:port pairs, when the contexts
> > overlap.
>
> If they connect to an IP that belongs to a guest, then to the guest.
> If they connect to an IP that belongs to the host, then to the host.
as we already clarified, all IPs are host IPs, the
guest shares a subset
> > * Processes listening on IPADDR_ANY should receive connections to any
> > > IP address that are set up for that virtual machine (be it the host
> > > or a guest).
> > The host does not have a context. How would you expect that to work?
> I think this is my problem. I expected that it would.
note that you can easily wrap your host only apps
into a chbind to limit them to the addresses you
consider 'host only' and thus use the isolation
mechanisms to do the work for you
best,
Herbert
> > Questions
> > > ---------
> > > So, given the above discussion, here are my questions:
> > >
> > > Do I mis-understand or mis-state how VServer functions today?
> > >
> > > Is my proposed alternative functionality "better", or is there some
> > > reason why today's behaviour is "better"?
> >
> > It just goes against the general Linux-VServer paradigm. As far as
> > possible, we do isolation by limiting the guest to a subset of the
> > host's resources. As such, limiting the host's ability to use the IP
> > addresses it wants is just not something that fits in.
> >
> > > How could we implement a more robust version of network isolation?
> > > Has any work been done in this area previously?
> >
> > I don't get what robust means in this context.
> >
> > > How do the other virtualization environments handle this sort of
> > > thing?
> >
> > OpenVZ and the containers people use virtualized network stacks for the
> > guests, which I consider to be too much overhead (both performance and
> > configuration wise).
> >
> > > Thanks for the consideration,
> > > Dan Risacher
> >
> > --
> > Daniel Hokka Zakrisson
> >
Received on Wed Oct 31 13:53:50 2007