On Tue, Oct 31, 2006 at 03:28:31PM -0800, Dan Price wrote:
> On Tue 31 Oct 2006 at 03:24PM, Steve Lawrence wrote:
> > It seems reasonable to amend this case to say:
> >
> > 1.
> > Any process with priv_sys_resource running in the global zone's
> > system project (project 0) will not su
I am working on a new spec. I have an unanswered question from the
discussion:
> > The "SIZE" column will also be changed to "SWAP" for prstat
> > options a, T, and J, for users, tasks, and projects.
>
> The reason for not changing this column in the default output would be
> helpful.
I
At the request of the project team, I've put this case into waiting need spec.
When the spec is updated, it will be sent out and the timer reset.
Gary..
___
zones-discuss mailing list
zones-discuss@opensolaris.org
On Mon, Nov 06, 2006 at 12:40:00PM +, Darren J Moffat wrote:
> Steve Lawrence wrote:
> >On Fri, Nov 03, 2006 at 09:36:45AM +, Darren J Moffat wrote:
> >>Steve Lawrence wrote:
> >>>Given a lack of supportive feedback, I'm going to revoke the proposed
> >>>amendment
> >>>below. To mitigate
Steve Lawrence wrote:
On Fri, Nov 03, 2006 at 09:36:45AM +, Darren J Moffat wrote:
Steve Lawrence wrote:
Given a lack of supportive feedback, I'm going to revoke the proposed
amendment
below. To mitigate a zone admin setting a problematic swap limit on the
global
zone, we will enhance zo
On Fri, Nov 03, 2006 at 09:36:45AM +, Darren J Moffat wrote:
> Steve Lawrence wrote:
> >Given a lack of supportive feedback, I'm going to revoke the proposed
> >amendment
> >below. To mitigate a zone admin setting a problematic swap limit on the
> >global
> >zone, we will enhance zonecfg to:
Steve Lawrence wrote:
Given a lack of supportive feedback, I'm going to revoke the proposed amendment
below. To mitigate a zone admin setting a problematic swap limit on the global
zone, we will enhance zonecfg to:
1. Print a warning when setting swap (and lwp) limits on the global
Given a lack of supportive feedback, I'm going to revoke the proposed amendment
below. To mitigate a zone admin setting a problematic swap limit on the global
zone, we will enhance zonecfg to:
1. Print a warning when setting swap (and lwp) limits on the global
zone. Since the
I'm not sure it is within the domain of this case to to tell admins what they
should and shouldn't use the global zone for.
In any event, we are making it easy for admins to manage swap limits for zones
via zonecfg.
On Tue, Oct 31, 2006 at 05:58:24PM -0800, Michael Barto wrote:
> After all thus j
Steve Lawrence wrote:
Would it be reasonable to propose special treatment of the global project 0
for all project and zone rctls? Once could argue that capping system
daemons
can only lead some sort of undesireable system failure.
This would of course exempt all global zone system daemons fro
On Wed, Nov 01, 2006 at 11:31:57AM +, Darren J Moffat wrote:
> Steve Lawrence wrote:
> >On Tue, Oct 31, 2006 at 12:02:58PM -0800, Gary Winiger wrote:
> >>>This is how we treat cpu-shares. project 0 in the global zone has
> >>>"infinite"
> >>>shares.
> >>>
> >>>This will not help root logins di
> >Would it be reasonable to propose special treatment of the global project 0
> >for all project and zone rctls? Once could argue that capping system
> >daemons
> >can only lead some sort of undesireable system failure.
> >
> >This would of course exempt all global zone system daemons from resou
Steve Lawrence wrote:
On Tue, Oct 31, 2006 at 12:02:58PM -0800, Gary Winiger wrote:
This is how we treat cpu-shares. project 0 in the global zone has "infinite"
shares.
This will not help root logins directly, but could by setting:
usermod -K project=system root
Or perhaps del
Steve Lawrence wrote:
On Tue, Oct 31, 2006 at 10:59:23AM -0800, Gary Winiger wrote:
DETAIL:
1. "zone.max-swap" resource control.
Limits swap consumed by user process address space mappings and
tmpfs mounts within a zone.
zone.max-swap will be configurable on both the global zo
After all thus juggling, let make it simple for the system admin and
use some sort of fair share process to assignment and manage the swap
for all the zones. Personally I think that the global zone should use
minimum resources and be considered in the IT management processes to
be only like a s
On Tue 31 Oct 2006 at 04:10PM, Steve Lawrence wrote:
> On Tue, Oct 31, 2006 at 03:28:31PM -0800, Dan Price wrote:
> > On Tue 31 Oct 2006 at 03:24PM, Steve Lawrence wrote:
> > > It seems reasonable to amend this case to say:
> > >
> > > 1.
> > > Any process with priv_sys_resource running in the
On Tue, Oct 31, 2006 at 03:28:31PM -0800, Dan Price wrote:
> On Tue 31 Oct 2006 at 03:24PM, Steve Lawrence wrote:
> > It seems reasonable to amend this case to say:
> >
> > 1.
> > Any process with priv_sys_resource running in the global zone's
> > system project (project 0) will not su
On Tue 31 Oct 2006 at 03:24PM, Steve Lawrence wrote:
> It seems reasonable to amend this case to say:
>
> 1.
> Any process with priv_sys_resource running in the global zone's
> system project (project 0) will not subject to project.* or zone.*
> resource controls. System d
> > > I'm looking for this case to define how to preserve the current
> > > model of "unlimited" unless one asks for a limit model in the
> > > global zone. I believe it is important from a system integrity and
> > > maintenance perspective. Other's may have different opinions.
> > > If
> > > This will not help root logins directly, but could by setting:
> > >
> > > usermod -K project=system root
> >
> > Or perhaps deliver root's entry this way to start with.
>
> Would that be a reasonable change to make via patch? Perhaps this change
> could be delivered to nevada, but
On Tue, Oct 31, 2006 at 12:02:58PM -0800, Gary Winiger wrote:
> > This is how we treat cpu-shares. project 0 in the global zone has "infinite"
> > shares.
> >
> > This will not help root logins directly, but could by setting:
> >
> > usermod -K project=system root
>
> Or perhaps delive
> This is how we treat cpu-shares. project 0 in the global zone has "infinite"
> shares.
>
> This will not help root logins directly, but could by setting:
>
> usermod -K project=system root
Or perhaps deliver root's entry this way to start with.
> Would it be reasonable to propos
On Tue, Oct 31, 2006 at 10:59:23AM -0800, Gary Winiger wrote:
> > DETAIL:
> >
> > 1. "zone.max-swap" resource control.
> >
> > Limits swap consumed by user process address space mappings and
> > tmpfs mounts within a zone.
>
> > zone.max-swap will be configurable on both the glo
> DETAIL:
>
> 1. "zone.max-swap" resource control.
>
> Limits swap consumed by user process address space mappings and
> tmpfs mounts within a zone.
> zone.max-swap will be configurable on both the global zone, and
> non-global zones. The affect on processes in a zone reac
24 matches
Mail list logo
