I've been given a possible theory as to how these two zones got into
this state (private response). If, for whatever reason, a pool is not
available, when a zone comes up/is brought up, the zone will be assigned
to the default pool/pset. It is usually accompanied with a "pool xxx
not available" type message.
This is highly likely the cause of the state, as customer's zones were
in default pool. Plus, when they rebooted their zone, this afternoon,
it was assigned to correct pool/pset. Customer did some pool type
reconfigs, yesterday, and we've asked them to recall if they got any of
these types of messages.
Alternatively, the customer could have tried to dynamically bound the
zone to a pool/pset, via the 'poolbind -p <poolname> -i zone <zonename>'
command.
Thanks for responses,
Jim
We're working with a customer who is using zones, along with Solaris
resource manager pools.
In short, they have two zones which are assigned to two non-default
pools. These two pools each have a processor set, one with one cpu
and another with two cpus. Somehow, these two zones started running
on the default processor set's processors. One of these zones was
rebooted, and that seems to have corrected its processor set mappings.
The have a maintenance window to reboot the other zone, but I wanted
to do a quick sanity check of any bugs anybody may know of. My
sunsolve searches doesn't seem to be turning up any hits on this.
Here is a summary of their zone to pool config, with generic names:
Pool Pset Zone
pool_pool1 pset1 (1 cpu) zone1
pool_pool2 pset2 (2 cpus) zone2
pool_default pset_default (5 cpus) all other zones
In this case, zone1 and zone2 were running on pset_default cpus.
Thanks!
Jim
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
