Re: [zones-discuss] Default RM controls for Containers?
Mads Toftum wrote: On Fri, May 11, 2007 at 01:44:42PM -0400, Jeff Victor wrote: I would choose 50%. For 3 zones, 75% doesn't accomplish enough. At 50%, they will (hopefully) investigate the performance issue and be happily surprised when they learn they've been using a default value... I'm not too keen to have defaults that could affect performance on systems running a normal load. As long as it only gets enabled when you ask for default RM, then I'm not too worried. Here we have a difficult non-technical decision to make. Which is 'better': 1) No out-of-the-box controls - the current situation. The unsuspecting zone creator will unwittingly allow DoS attacks by zones until it becomes clear that RM controls should be used, either through education or a negative experience. Possible solutions to this include A) One enable-RM knob which applies defaults that can be overridden B) Templates that have default RM controls C) Others 2) Out-of-the-box controls: all zones have default RM controls unless the creator overrides those controls. These values would be generous enough to prevent DoS attacks and the effects of very badly written software, but not affect most workloads, as Mads suggests. Templates could also be added to enable simple RM tuning. To me, (1) doesn't solve the problem that I think we need to solve. I am trying to protect the first-time and occasional zones creators. As Jerry said, RM is a requirement for zones. At the same time, I am trying to minimize any impact on normal workloads. By default zones provide an extremely robust security boundary to protect them from each other. Why do they not also provide some default minimum RM isolation, for the same reason? If we have consensus on the basic idea of out-of-the-box defaults, I think I have seen enough on this thread to draft specifics - modifications to the UI, what the defaults would be, etc. Are we ready for that yet? Further, if that concept gets far enough, I would like to implement the changes as an OpenSolaris community member. I would need some guidance on the process, but can handle the code work. -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Default RM controls for Containers?
Menno Lageman wrote: Another option for RM templates would be that the template is a pointer to a set of RM defaults instead of being used directly during zone creation. This way, changing RM settings of existing zones would simply entail changing the template in one place. Or, when moving a zone to another class of RM defaults, by changing the template reference in that zone (i.e. from SUNWsmall to SUNWmedium). Also, regardless of the model we use, any defaults should not be based on the hardware configuration of the system when the zone is first installed. After the zone is moved to a different system, defaults should be calculated when the zone boots. If default caps are in use, maybe the zone should re-calculate caps at boot time. Otherwise, caps chosen when the zone was first created could be very inappropriate, perhaps completely ineffective, after the zone is moved. This has the potential to surprise someone who doesn't expect re-calculation, but is better than incapacitating the entire concept of default caps. -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Default RM controls for Containers?
Jeff Victor wrote:
Here we have a difficult non-technical decision to make. Which is
'better':
1) No out-of-the-box controls - the current situation. The
unsuspecting zone creator will unwittingly allow DoS attacks by zones
until it becomes clear that RM controls should be used, either through
education or a negative experience. Possible solutions to this include
A) One enable-RM knob which applies defaults that can be overridden
B) Templates that have default RM controls
C) Others
2) Out-of-the-box controls: all zones have default RM controls unless
the creator overrides those controls. These values would be generous
enough to prevent DoS attacks and the effects of very badly written
software, but not affect most workloads, as Mads suggests. Templates
could also be added to enable simple RM tuning.
On the premise that we're trying to give the regular[1] Zones user a
good, default RM setup, I'd vote for option 2 ('safe' OOB controls).
Experienced users that have more insight into what good values for their
zones should be, can override these defaults if needed. Which of course
leads to the question what the default out-of-the-box values should be.
This might be the hardest part.
Menno
[1] someone who has no in-depth knowledge of/experience with Zones and
Resource Management and just needs a zone to run his applications in.
--
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] Default RM controls for Containers?
Menno Lageman wrote:
Jeff Victor wrote:
Here we have a difficult non-technical decision to make. Which is
'better':
1) No out-of-the-box controls - the current situation. The
unsuspecting zone creator will unwittingly allow DoS attacks by zones
until it becomes clear that RM controls should be used, either through
education or a negative experience. Possible solutions to this include
A) One enable-RM knob which applies defaults that can be overridden
B) Templates that have default RM controls
C) Others
2) Out-of-the-box controls: all zones have default RM controls unless
the creator overrides those controls. These values would be generous
enough to prevent DoS attacks and the effects of very badly written
software, but not affect most workloads, as Mads suggests. Templates
could also be added to enable simple RM tuning.
On the premise that we're trying to give the regular[1] Zones user a
good, default RM setup, I'd vote for option 2 ('safe' OOB controls).
Experienced users that have more insight into what good values for their
zones should be, can override these defaults if needed. Which of course
leads to the question what the default out-of-the-box values should be.
This might be the hardest part.
I think that an appropriate fraction of the resource which exists at zone-boot
time is a good start. Agreeing to a specific fraction will, undoubtedly,
involve a great deal of arm-wrestling among us... ;-)
Menno
[1] someone who has no in-depth knowledge of/experience with Zones and
Resource Management and just needs a zone to run his applications in.
--
Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com
OS AmbassadorSr. Technical Specialist
Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq
--
___
zones-discuss mailing list
zones-discuss@opensolaris.org
[zones-discuss] How to patches websphere 6 in solaris 10 zone
We have installed and created websphere 6 in solaris 10 zone using sun white paper How to Get strated with IBM Websphere Application Server on Solaris 10 and zones, however the document didn't address how to apply patches for websphere 6 in the zone environment. Can some one please address this issue, because without that, I don't think running websphere in a zone environment is a viable option This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
