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. Jerry _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
