Thinking outloud, Ihsan,

I haven't tried it, but I would expect a NGZ's *project.pool to not be able to bind to a pool, since the NGZ has no visibility into a pool (right now; don't know if this could or will be extended).


Regarding what you are trying to accomplish, what are you referring to as the OS needs of a NGZ? There are a number of services running in a zone, but they should not be heavy weight, and it might be worth disabling some of the services anyway. When a NGZ's application enters the kernel, what is a different issue, and I am not sure if it would be possible to force a CPU/pool transition at that point, or if it would be worth the extra [CPU] resource effort. For processing originating in the kernel (such as an incoming I/O transaction destined for such an NGZ) it may end up on any CPU. Network traffic might be different, depending on onto which CPU the connection's squeue gets bound.

But at a bigger picture, if you consider zones a consolidation of different systems, each system's OS processing was also done there. Although there is kernel sharing, general randomness would suggest that no one NGZ is penalized unheavily with other NGZs' kernel processing (although I imagine you can generate cases where one has considerably more kernel processing than others, for example incoming SSL decryption with the new kernel SSL proxy).

I imagine others more familiar with the pool relationship will state what can and can not be done.

Steffen

Ihsan Zaghmouth wrote On 09/15/06 08:39,:
Steffen,

Thanks for your contribution on this.

As you know, the project attribute, *project.pool, specifies the pool to which processes associated with the project entry should be bound.* project.pool=pool_name. pools are fixed resources and processes are uniquely identified Globaly or localy to GZ / LZ.

The idea is whether the Project (container) is in GZ or LZ, *processes *within the Project that belong to a specific *Uname/Uid* could be associated to a *specific pool of choice*
different, in my opinion, than the one GZ or LZ is associated to.

The main idea after all this, is to have pools for Applications in LZ(s) associated to different pools than the one that could serve GZ and LZ(s) OS needs. If we can achieve this isolation *down to the process leve*l, we have a better chance and flexibility in coaching our pool resources in this particular fashion, not mentioning what could be achieved with dynamic resource pooling and its flexibility in doing more.

Your thoughts ?

Thanks
Ihsan


Steffen Weiberle wrote:

Ihsan Zaghmouth wrote On 09/14/06 11:59,:

Hi again,

I am posting this message just in case it was missed or forgotten.
*Can we assign the Zone to a pool and the Zone's Project to another pool ?*


I don't believe so. The pools should not be visible in a zone, as they are a *system* resource, and messing with that could affect other zones.

Since projects are naming instance based, and each zone has its own instance, the global zone's view of projects would be different from a non-global zone, and therefor the global adminstrator would not be able to put process(es) associated with a zone's project into a pool only visible in global.

I don't know if global could move NGZs' processes from one pool to another.

Steffen


any thoughts ?

cheers
Ihsan

Ihsan Zaghmouth wrote:


Hi,

A general question regarding *Zones, Pools and Projects* within these Zones. I am aware of zone associations to pools and their psets. Many zones to 1 pool and not visa versa.

The question is, if we decide on 2 Pools, could we associate a *Zone* to pool_1 (set pool = "pool_1" in zonecfg or poolbind) and the *Project *within this *Zone *to the other pool via the *project.pool = "pool_2"* under FSS and is there any reservations for doing so ?

cheers
Ihsan


--
**

Ihsan Zaghmouth
Sr. SAP Solution Architect
SUN-SAP Business Applications Group

(832) 859-2818   (Cell)
(713) 784-2818   (Home)
(713) 784-2818   (Fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>


------------------------------------------------------------------------

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

--
**

Ihsan Zaghmouth
Sr. SAP Solution Architect
SUN-SAP Business Applications Group

(832) 859-2818   (Cell)
(713) 784-2818   (Home)
(713) 784-2818   (Fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>



------------------------------------------------------------------------

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org


--
**

        

Ihsan Zaghmouth
Sr. SAP Solution Architect
SUN-SAP Business Applications Group

(832) 859-2818   (Cell)
(713) 784-2818   (Home)
(713) 784-2818   (Fax)
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>



------------------------------------------------------------------------

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to