On Fri, Feb 20, 2009 at 2:49 PM, Derek McEachern
<derekmceach...@gmail.com> wrote:
> Jeff,
> Sorry this has taken so long to get to but yes, if I enable the pools and
> pools/dynamic services it runs as expected.

Good. Until I can create v1.3.1, that is a good workaround. It is an
extra step, but doesn't hurt performance - or anything else.

> Has any work started on a 'real' zonestat yet?

I believe that design work has begun, but these things take time...

> On Tue, Feb 17, 2009 at 9:44 PM, Jeff Victor <jeff.j.vic...@gmail.com>
> wrote:
>> On Tue, Feb 17, 2009 at 4:09 PM, Derek McEachern
>> <derekmceach...@gmail.com> wrote:
>> > We are in the process of deploying applications into zones and I've been
>> > looking at how to monitor what each zone is up to regarding resource usage.
>> > I downloaded the zonestat.pl script to play around with and out of the
>> > box it didn't actually give me any zone specific information.
>> >
>> > After poking around the code it turns out it won't break out any zone
>> > level details unless resource pooling is enabled. We are deploying  our
>> > zones
>> > without resource restrictions.
>> This is a known problem with v1.3. I am working on v1.3.1 which will
>> fix that problem.
>> As a temporary workaround: does it work correctly if you enable pools
>> and don't configure any?
>> GZ# svcadm enable pools
>> GZ# svcadm enable pools/dynamic
>> > I hacked the script to get around this problem for now but is this a
>> > feature we can get added to the baseline?  Jeff, how are  changes handled 
>> > to
>> > this
>> > script since you appear to the owner?
>> To make a contribution to the OpenSolaris community, first you would
>> register as a contributor. The other option is to request a specific
>> change in behavior, and I will try to get to it promptly.
>> However, please understand (as the project web pages state) that this
>> is a prototype to help us learn what a 'real' zonestat should do. The
>> 'real' zonestat would be written in C or D for improved functionality
>> and considerably better performance. This Perl script consumes a great
>> deal of CPU cycles.
>> --JeffV

zones-discuss mailing list

Reply via email to