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 system controller on a complex server. Keep your applications out of the global zone!!!

Gary Winiger wrote:
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 not backported.

It would be confusing to deliver this change, and also deliver the "user.root"
project.  If we made root's default project "system", then the "user.root"
project should be removed.  "user.root" is kind of a bug anyhow, as SMF does
not run root services in "user.root".  Currently, only root processes spawned
by login/pam run in "user.root".

Perhaps this issue should be run as a seperate fasttrack?  I need to 
investigate the implementation impact.
	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 there is a compelling reason to deliver in phases, please discuss
The global zone will have no swap limit by default.  The default zone.max-swap
rctl delivered on the global zone is UINT64_MAX, which is essentially
unlimited.  Is that what you mean?

	My point(s) here is not so much how things get done, but that
	the global zone is in some ways special.  IIRC, before this
	project, the GZ doesn't have a swap limit.  After this project
	an administrator could set swap limit on the GZ.  Granted this
	is administrative action and they get what they deserve/ask for.
	However, it seemed to me that part of this case "should" (my
	judgement) include some way to override the limit in case 
	override is really desired.  As implied, perhaps by putting
	root into project 0 at login or as part of daemon/service start
	is a way to bypass the administrator's choice in the GZ for
	some processes.  What I didn't see as part of this case is
	the architecture to allow this bypass.  Perhaps I'm off base
	for thinking it's necessary to protect against inadvertantly
	not being able to administer the system from the GZ.

zones-discuss mailing list



Michael Barto
Software Architect

LogiQwest Circle
LogiQwest Inc.
16458 Bolsa Chica Street, # 15
Huntington Beach, CA  92649

Tel:  714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949

'tis a gift to be simple
This e-mail may contain LogiQwest proprietary information and should be treated as confidential.
zones-discuss mailing list

Reply via email to