It used to be that running a NFS server was not supported in a non global zone.
Is this till the case?
If so are there any plans to support it?
What is the reason for not supporting NFS server in a non global zone?
Thanks
Paul.
--
Paul van den Bogaard Sun Mi
Lets say I have a T2000 with 16 threads.
I have the following:
pool_1 = dynamic pool with 50% utilization goal set
zone_a = 50/100 shares
proj_alpha = 50/100 shares
proj_beta = 50/100 shares
zone_b = 50 shares
pool_2 = dynamic pool with 50% utiliz
On 10/26/06, George Davis <[EMAIL PROTECTED]> wrote:
Zone/Container Gurus,
My customers' DBAs ask:
3. is it still true that you need to reboot a zone when adding a new disk?
I have not had to reboot to add a disk to a Solaris system in
many, many years. It all depends on whether the
It's being worked on:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4964859
IIRC, it is currently not supported because the kernel part of NFS
server does not understand the concept of zones...
Rayson
==
http://gridengine.sunsource.net/
http://www.gridengine.info/
On 10/27/06,
You may want to add more information like you are creating
psets for each pool and the pset.max and pset.min of each.
Because when I create a pset without specifying them and associate it with a
pool,
the size is zero.
Also a correction. You cannot specify 50/100 shares.
Shares are relative in
Rayson Ho wrote:
It's being worked on:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4964859
IIRC, it is currently not supported because the kernel part of NFS
server does not understand the concept of zones...
In order to help the NFS team understand the importance of this
issue
Amol A Chiplunkar wrote:
You may want to add more information like you are creating
psets for each pool and the pset.max and pset.min of each.
Because when I create a pset without specifying them and associate it with a pool,
the size is zero.
I thought when you were using a utilization goal i
You can also remove a LOFS mounted filesystem from a running zone with no
problem. I do it all the time.
To do it, logon to the global zone and umount the filesystem with:
umount
Phil
This message posted from opensolaris.org
___
zones-discuss mai
On Tue, Oct 24, 2006 at 01:41:32PM -0700, Erik Nordmark wrote:
> Edward Pilatowicz wrote:
> >- how about the opposite scenario. a user configures a zone with
> > without and an exclusive ip instance and sets up a bunch of network
> > configuration inside that zone that would normally only apply
A (large) customer recently asked me to implement a feature whereby they
could monitor zone activity via syslog. The motivation is that for this
customer, any zone state change not during maintenance windows is a cause
for alarm.
I prototyped this feature last night and I'd like to solicit your
> So here are my questions:
>
> - Do you think this is useful?
>
> - Do you think the log level (Info) is right? daemon.info is
> *not* logged by default, whereas notice is. (So basically: do
> you want these messages in /var/adm/messages by default, or not?)
>
>
On 10/27/06, Dan Price <[EMAIL PROTECTED]> wrote:
A (large) customer recently asked me to implement a feature whereby they
could monitor zone activity via syslog. The motivation is that for this
customer, any zone state change not during maintenance windows is a cause
for alarm.
I've had a si
On Fri 27 Oct 2006 at 09:11PM, Peter Memishian wrote:
>
> > So here are my questions:
> >
> > - Do you think this is useful?
> >
> > - Do you think the log level (Info) is right? daemon.info is
> > *not* logged by default, whereas notice is. (So basically: do
> > yo
> Such as?
No strong preference, but it should be something that can be versioned,
extensible, parsed unambiguously and easily, and unaffected by locale.
Maybe general purpose event channels?
--
meem
___
zones-discuss mailing list
zones-discuss@open
On Fri 27 Oct 2006 at 06:21PM, Dan Price wrote:
> >
> > Encouraging programmatic use of syslog seems a step in the wrong direction
> > to me. Surely we can provide a better mechanism to notify them of state
> > changes?
>
> Such as?
I guess my larger point is that I haven't seen us take steps i
> I think that some minimal syslogging is warranted (I've tried to keep it
> simple here) because we do know that customers have a degree of comfort
> with syslog, and because it fits readily into various existing 3rd party
> monitoring packages.
But it falls apart in the long run since the o
On 10/27/06, Dan Price <[EMAIL PROTECTED]> wrote:
As for GPEC, that's what our existing C api is based upon. Take a look at
zonecfg_notify_*() in libzonecfg. It's a real horror show but it does
solve the "get the state and then subscribe to future changes and don't
miss anything in between" pro
On Fri, 27 Oct 2006, Dan Price wrote:
A (large) customer recently asked me to implement a feature whereby they
could monitor zone activity via syslog. The motivation is that for this
customer, any zone state change not during maintenance windows is a cause
for alarm.
I prototyped this featur
On Fri, 27 Oct 2006, Mike Gerdts wrote:
On 10/27/06, Dan Price <[EMAIL PROTECTED]> wrote:
As for GPEC, that's what our existing C api is based upon. Take a look at
zonecfg_notify_*() in libzonecfg. It's a real horror show but it does
solve the "get the state and then subscribe to future chan
I just stood up this environment and used nspins to max out the allocations.
Host (8 CPU v890)
pool_1 Max=66K Min=1 Util_goal=50% Actual 5
zone_a 50 shares
proj_alpha 50 shares
proj_beta 50 shares
20 matches
Mail list logo
