Bob Netherton wrote:
I see where you are going with this Jeff, and there are some good ideas
behind all of this.   I have a great desire to rephrase your question
without the reference to zones - how well is Solaris itself
protected against the various forms of DoS attack ?   Do the controls
here suggest rational defaults for zones (ie, should we just inherit
the limits/protections from the Solaris parent) ?
Perhaps this is a case where the unintended consequences of
simplicity may have profound implications ?   Said another way -
I have customers running web servers, simple network daemons, and
Oracle in zones and I have no earthly idea how to suggest a
rational set of defaults, other than inheriting those of the
Solaris parent (which takes me back to my original thought fragment -
is this really a zones issue???).

There are certainly uses for resource management outside of zones but
RM is a requirement for zones.  The problem for people doing consolidation
is they want to create a predictable environment.  Before consolidation
the various stacks ran on separate systems so a problem on the stack
was contained to that machine.  When you are consolidating you want the
same predictable behavior for the overall system.  Without some form
of resource management a single zone can unpredictably consume all available
resources.  This is true for any virtualization scheme.  This is why, with
a few exceptions, you should always use FSS with zones.  This allows any
zone to use all of the available CPU resources if it has enough work to
do and no other zone is busy, but at the same time it ensures that each zone
will get its share of the CPU if it needs it.  Setting good values for some
of the other controls is trickier although I think Dan's idea of scaling
these based on the system makes it easier.  We might also want to think
about scaling based on the number of running zones.


zones-discuss mailing list

Reply via email to