Re: [zones-discuss] S10 U3 Live Upgrade with zones

2007-10-03 Thread Richard Weatherley
Hi Enda

What is the ETA for 119255 (> -42) that addresses the problems with deferred 
activation patching for ZFS and VxFS when trying to install 120012-14?

Thanks.
 
 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] S10 U3 Live Upgrade with zones

2007-10-03 Thread Enda O'Connor ( Sun Micro Systems Ireland)
Richard Weatherley wrote:
> Hi Enda
> 
> What is the ETA for 119255 (> -42) that addresses the problems with deferred 
> activation patching for ZFS and VxFS when trying to install 120012-14?
> 
> Thanks.
>  
>  
> This message posted from opensolaris.org
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
Hi
I will try and get some preliminary dates ( it will not in 43 is all I 
can say )
I have added some people how are working on resolving these issues ( 
well it one issue really )

Enda
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] bug? zone wont create device files during boot

2007-10-03 Thread Dan Price
On Tue 02 Oct 2007 at 07:35AM, Konstantin Gremliza wrote:
> 
> 
> Someone earlier stated that this was also broken in SXDE-- as far as
> I know that is *not* the case.  One of the reasons this has been a
> troublesome area is that in Nevada the /dev zones implementation is
> radically different from S10, due to the existence of the "devnames"
> project in Nevada.  Hence the S10 and Nevada code is pretty in this
> area.
> 
> -dp
> 
> 
> Before I posted this to [zone-discuss] I tried again on SXDE 09/07, and the
> same problem occured.
> Adding a device match will not create any device files in ZONEPATH/dev.

Konstantin, we'll go back and retest SXDE 9/07, although at present we
don't have a bug for this problem open against SXDE.  As I said, the
code is basically completely different in that area between SXDE and
S10, so it would have to be a new and different bug.

My desktop is a SPARC box running build 72 (which AFAIK is SXDE 9/07)
and I don't see this there; this is an example of adding, then
removing a pseudo device in a basic test:
  
  # uname -a 
  SunOS snowdog 5.11 snv_72 sun4u sparc SUNW,A70
  # ls -l /aux/foo/root/dev/lockstat
  /aux/foo/root/dev/lockstat: No such file or directory
  # zonecfg -z foo 'add device; set match=/dev/lockstat; end'
  # zoneadm -z foo reboot
  # ls -l /aux/foo/root/dev/lockstat
  crw-r--r--   1 root sys   89,  0 Oct  3 02:55 
/aux/foo/root/dev/lockstat
  # zonecfg -z foo 'remove device match=/dev/lockstat'
  # zoneadm -z foo reboot
  # ls -l /aux/foo/root/dev/lockstat
  /aux/foo/root/dev/lockstat: No such file or directory

(Please note that I'm not advising that anyone add /dev/lockstat to
their zone; I simply used it as a test case).

Perhaps you could post your SXDE test case?

-dp

- 
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] S10 U3 Live Upgrade with zones

2007-10-03 Thread Enda O'Connor ( Sun Micro Systems Ireland)
Enda O'Connor ( Sun Micro Systems Ireland) wrote:
> Richard Weatherley wrote:
>> Hi Enda
>>
>> What is the ETA for 119255 (> -42) that addresses the problems with deferred 
>> activation patching for ZFS and VxFS when trying to install 120012-14?
>>
>> Thanks.
>>  
>>  
>> This message posted from opensolaris.org
>> ___
>> zones-discuss mailing list
>> zones-discuss@opensolaris.org
> Hi
> I will try and get some preliminary dates ( it will not in 43 is all I 
> can say )
> I have added some people how are working on resolving these issues ( 
> well it one issue really )
> 
> Enda
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
Hi
Also meant to say, sorry for the hassle incurred here, but we are 
working towards getting a fix for this out soon.


Enda
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] bug? zone wont create device files during boot

2007-10-03 Thread Enda O'Connor ( Sun Micro Systems Ireland)
Dan Price wrote:
> On Tue 02 Oct 2007 at 07:35AM, Konstantin Gremliza wrote:
>>
>> Someone earlier stated that this was also broken in SXDE-- as far as
>> I know that is *not* the case.  One of the reasons this has been a
>> troublesome area is that in Nevada the /dev zones implementation is
>> radically different from S10, due to the existence of the "devnames"
>> project in Nevada.  Hence the S10 and Nevada code is pretty in this
>> area.
>>
>> -dp
>>
>>
>> Before I posted this to [zone-discuss] I tried again on SXDE 09/07, and the
>> same problem occured.
>> Adding a device match will not create any device files in ZONEPATH/dev.
> 
> Konstantin, we'll go back and retest SXDE 9/07, although at present we
> don't have a bug for this problem open against SXDE.  As I said, the
> code is basically completely different in that area between SXDE and
> S10, so it would have to be a new and different bug.
> 
> My desktop is a SPARC box running build 72 (which AFAIK is SXDE 9/07)
> and I don't see this there; this is an example of adding, then
> removing a pseudo device in a basic test:
>   
>   # uname -a 
>   SunOS snowdog 5.11 snv_72 sun4u sparc SUNW,A70
>   # ls -l /aux/foo/root/dev/lockstat
>   /aux/foo/root/dev/lockstat: No such file or directory
>   # zonecfg -z foo 'add device; set match=/dev/lockstat; end'
>   # zoneadm -z foo reboot
>   # ls -l /aux/foo/root/dev/lockstat
>   crw-r--r--   1 root sys   89,  0 Oct  3 02:55 
> /aux/foo/root/dev/lockstat
>   # zonecfg -z foo 'remove device match=/dev/lockstat'
>   # zoneadm -z foo reboot
>   # ls -l /aux/foo/root/dev/lockstat
>   /aux/foo/root/dev/lockstat: No such file or directory
> 
> (Please note that I'm not advising that anyone add /dev/lockstat to
> their zone; I simply used it as a test case).
> 
> Perhaps you could post your SXDE test case?
> 
> -dp
> 
> - 
> Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - 
> blogs.sun.com/dp
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org

Hi
I tried build 74,
add device
set match=/dev/dsk/c0t0d0s7
end
add device
set match=/dev/rdsk/c0t0d0s7
end

rebooted zone and device is there ( verified it wasn't before hand )
We need the user case that fails.

Enda
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] bug? zone wont create device files during boot

2007-10-03 Thread Jerry Jelinek
Enda O'Connor ( Sun Micro Systems Ireland) wrote:
> I tried build 74,
> add device
> set match=/dev/dsk/c0t0d0s7
> end
> add device
> set match=/dev/rdsk/c0t0d0s7
> end
> 
> rebooted zone and device is there ( verified it wasn't before hand )
> We need the user case that fails.

Enda,

I thought the original email used a wildcard match like this:

set match=/dev/*dsk/c1t15d0s*

I just tried that on build 74 and it worked fine though, so I agree
that we need more info.

Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] bug? zone wont create device files during boot

2007-10-03 Thread Enda O'Connor ( Sun Micro Systems Ireland)
Jerry Jelinek wrote:
> Enda O'Connor ( Sun Micro Systems Ireland) wrote:
>> I tried build 74,
>> add device
>> set match=/dev/dsk/c0t0d0s7
>> end
>> add device
>> set match=/dev/rdsk/c0t0d0s7
>> end
>>
>> rebooted zone and device is there ( verified it wasn't before hand )
>> We need the user case that fails.
> 
> Enda,
> 
> I thought the original email used a wildcard match like this:
> 
> set match=/dev/*dsk/c1t15d0s*
> 
> I just tried that on build 74 and it worked fine though, so I agree
> that we need more info.
> 
> Jerry
Hi Jerry
hadn't spotted the wildcard :-)
but it does appear to work non the less.

Enda
___
zones-discuss mailing list
zones-discuss@opensolaris.org


[zones-discuss] Making Tun/Tap Driver Visible in a Non-Global Zone

2007-10-03 Thread Jim Doble
I have installed the Tun/Tap driver (which is essentially a virtual 
point-to-point interface driver) in the global zone, and I want to make the 
corresponding interface visible in a non global zone.

When I run "ifconfig -a" in the global zone, I see the following:

lo0: flags=2001000849 mtu 8232 
index 1 inet 127.0.0.1 netmask ff00
lo0:1: flags=2001000849 mtu 8232 
index 1 zone rgZone inet 127.0.0.1 netmask ff00
eri0: flags=1000843 mtu 1500 index 2 inet 
10.254.1.103 netmask ff00 broadcast 10.254.1.255 ether 0:3:ba:9:59:2d
eri0:1: flags=1000843 mtu 1500 index 2 
zone rgZone inet 10.254.1.105 netmask ff00 broadcast 10.254.1.255
tun0: flags=10008d1 mtu 1500 index 
7 inet 192.168.48.1 --> 192.168.48.2 netmask  ether 0

Note the tun0 interface that I would like to make available to the non-global 
zone. When I run "ifconfig -a" in the non-global zone, I see the following:

lo0:1: flags=2001000849 mtu 8232 
index 1 inet 127.0.0.1 netmask ff00
eri0:1: flags=1000843 mtu 1500 index 2 
inet 10.254.1.105 netmask ff00 broadcast 10.254.1.255

Note that there is no tun0:1. When I run "netstat -rn" on my non-global zone, I 
see the following:

Routing Table: IPv4
  Destination   Gateway   Flags  Ref   Use   Interface
  - - -- -
10.1.1.0 192.168.48.2 UG1  0
10.254.1.0   10.254.1.105 U 1 90 eri0:1
224.0.0.010.254.1.105 U 1  0 eri0:1
default  10.254.1.1   UG1125
127.0.0.1127.0.0.1UH4203 lo0:1

Note the route from 10.1.1.0 to 192.168.48.2, which is associated with my tun0 
device. Unfortunately, the non-global zone does not have a route for the 
address 192.168.48.2. If I run "netstat -rn" from a global zone, I see the 
following:

Routing Table: IPv4
  Destination   Gateway   Flags  Ref   Use   Interface
  - - -- -
192.168.48.2 192.168.48.1 UH1  0 tun0
10.1.1.0 192.168.48.2 UG1  0
10.254.1.0   10.254.1.103 U 1204 eri0
224.0.0.010.254.1.103 U 1  0 eri0
default  10.254.1.1   UG1125
127.0.0.1127.0.0.1UH   30431 lo0

In this case, we see the route to 192.168.48.2 via 192.168.48.1 that we need to 
also have on the non-global zone.

I haven't done a lot of work with Solaris zones, so there may be something 
simple I am missing here. Any help would be appreciated.
 
 
This message posted from opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] bug? zone wont create device files during boot

2007-10-03 Thread Konstantin Gremliza





Dan, I apologize. I'm still learning.
I replayed the whole damn thing and of course it works well and all
devices appear in the zone as configured.
I was just confused because looking at /zones/zone-a/dev still doesn't
show any of my device files.
You also wanted me to check ZONEPATH/dev which is still quite empty
although the files apear in /dev within the zone. 
As my little dtrace script shows the earlier implementation of devfsadm
-z  in READY state and the devfsadm -Z during the stop of
the zone have disappeared.
It has been replaced by a strange mount -o attrdir=ZONEPATH/dev ... I
didnt find anything in the man pages, so I guess I have to look into
the source ...

Thanks again,

Konstantin

# more /etc/release  
              Solaris Express Developer Edition 9/07 snv_70b X86
   Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
    Use is subject to license terms.
    Assembled 30 August 2007
# zoneadm -z zone-a list zone-a -v
ID NAME STATUS PATH   BRAND   
IP    
 - zone-a   installed  /zones/zone-a  native  
shared

# ls /zones/zone-a/dev/lockstat 
/zones/zone-a/dev/lockstat: No such file or directory

# zonecgf -z zone-a 'add device;set match=/dev/lockstat;end'
# zonecgf -z zone-a info 
zonename: zone-a
...
device:
    match: /dev/lockstat
...

# zoneadm -z zone-a boot
# zoneadm list -cv
  ID NAME STATUS PATH  
BRAND    IP    
   0 global   running    / 
native   shared
   1 zone-a   running    /zones/zone-a 
native   shared
   - zone-b   installed  /zones/zone-b 
native   shared 

NO SUCH FILE:

# ls /zones/zone-a/dev
cpu   dtrace    fd    pts   rmt   sad   swap 
term  zconsole

BUT HERE IT IS:

# zlogin zone-a ls /dev
arp conslog console cpu crypto cryptoadm dsk dtrace dtremote fd kstat
lockstat log logindmux msglog null poll pool ptmx pts random rdsk rmt
sad stderr stdin stdout swap ...


# zone_state.d

  TIME ZONE  ID STATE
 11280.463 1   zone-a SHUTTDING_DOWN
 12282.011 EXIT:   1 init[993]
 12284.484 1   zone-a EMPTY
 12284.697 1   zone-a DOWN
 12357.223 1   zone-a DYING
 12357.312 EXIT:   1 zsched[981]
 12357.397 1   zone-a DEAD
 12364.892 2   zone-a READY

THIS IS NEW TO ME:
 12377.392 EXEC: mount -o attrdir=/zones/zone-a/dev /dev
/zones/zone-a/root/dev

 12391.944 EXEC: mount -o ro,nosub,nodevices /lib
/zones/zone-a/root/lib
 12400.040 EXEC: mount -o ro,nosub,nodevices /platform
/zones/zone-a/root/platform
 12406.763 EXEC: mount -o ro,nosub,nodevices /sbin
/zones/zone-a/root/sbin
 12412.863 EXEC: mount -o ro,nosub,nodevices /usr
/zones/zone-a/root/usr
 12448.600 2   zone-a BOOTING
 12449.042 2   zone-a RUNNING
 12453.645 FORK:   2 init[1560]
^D^C

script done on Wed Oct 03 15:19:25 2007

Dan Price schrieb:

  On Tue 02 Oct 2007 at 07:35AM, Konstantin Gremliza wrote:
  
  

Someone earlier stated that this was also broken in SXDE-- as far as
I know that is *not* the case.  One of the reasons this has been a
troublesome area is that in Nevada the /dev zones implementation is
radically different from S10, due to the existence of the "devnames"
project in Nevada.  Hence the S10 and Nevada code is pretty in this
area.

-dp


Before I posted this to [zone-discuss] I tried again on SXDE 09/07, and the
same problem occured.
Adding a device match will not create any device files in ZONEPATH/dev.

  
  
Konstantin, we'll go back and retest SXDE 9/07, although at present we
don't have a bug for this problem open against SXDE.  As I said, the
code is basically completely different in that area between SXDE and
S10, so it would have to be a new and different bug.

My desktop is a SPARC box running build 72 (which AFAIK is SXDE 9/07)
and I don't see this there; this is an example of adding, then
removing a pseudo device in a basic test:
  
  # uname -a 
  SunOS snowdog 5.11 snv_72 sun4u sparc SUNW,A70
  # ls -l /aux/foo/root/dev/lockstat
  /aux/foo/root/dev/lockstat: No such file or directory
  # zonecfg -z foo 'add device; set match=/dev/lockstat; end'
  # zoneadm -z foo reboot
  # ls -l /aux/foo/root/dev/lockstat
  crw-r--r--   1 root sys   89,  0 Oct  3 02:55 /aux/foo/root/dev/lockstat
  # zonecfg -z foo 'remove device match=/dev/lockstat'
  # zoneadm -z foo reboot
  # ls -l /aux/foo/root/dev/lockstat
  /aux/foo/root/dev/lockstat: No such file or directory

(Please note that I'm not advising that anyone add /dev/lockstat to
their zone; I simply used it as a test case).

Perhaps you could post your SXDE test case?

-dp

- 
Daniel Price - Solaris Kernel Engineering - [EMAIL PRO

[zones-discuss] zone.max-processes

2007-10-03 Thread Menno Lageman
One of the items listed as 'future work' is the zone.max-processes 
resource control to limit the number of process slots a zone may have.

I have prototyped this and would like to solicit feedback.

The goal of the zone.max-processes resource control is to protect the 
global zone and other non-global zones from a non-global zone that uses 
an inordinate amount of process slots (either by accident or by malice 
such as a fork bomb). While some protection against this can be achieved 
with the zone.max-lwps resource control and/or memory capping, it is not 
  an ideal solution. The zone.max-lwps rctl cannot prevent zombies from 
filling up process slots for instance, as a zombie (by definition) does 
not have any lwps.

The prototype has a per zone limit on the number of slots that can be 
used by the zone at any given time. The limit is enforced regardless of 
the user that tries to get a process slot, i.e. the root user is not 
special in any way. Since we're trying to protect others from a 
misbehaving zone, allowing root to escape the limit would render the 
rctl useless. This can lead to a failure mode where the zone itself may 
not be able recover by itself. The zone.max-lwps rctl has the same 
failure mode, and given the goal of protecting the rest of the system, 
that seems acceptable.

For compatibility with the current behavior the zone.max-processes rctl 
will only have an unlimited 'system' limit by default. To limit the 
number of slots for a zone the administrator must add a 'privileged' 
limit with the appropriate number of processes required. zonecfg(1M) has 
been extended to support setting this limit using the short form 'set 
max-processes=nnn' or the classic 'add rctl ...' form. A lower bound for 
the number of processes (currently an arbitrary 100) is enforced by 
zonecfg to prevent the administrator from making the zone unbootable. 
The usual checks done at process creation (against v_maxup etc.) are 
still done, but after the zone.max-processes check. The default 
configuration will be equivalent to the current behavior.

The prototype currently only enforces the limit for non-global zones to 
prevent rendering the system unusable by setting too low a limit on the 
global zone. This adds a safety net, but may also add some confusion as 
the limit on the global zone can be set but is not enforced (in the same 
way that system processes are exempt fro rctls), so this may or may not 
be a good option.

Thoughts?

Menno
-- 
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone.max-processes

2007-10-03 Thread Menno Lageman
Steve Lawrence wrote:
> Have you considered also implementing project.max-processes?  This would
> give a zone admin some control over workloads within the zone.  I would
> follow suit and make project 0 in the global zone exempt from its 
> project.max-processes rctl.

I hadn't considered project.max-processes yet, mainly because what I see 
in the field is that most people seem to consider project rctls to be 
too much detail. Configuring limits at the zone level seems to be the 
preferred option. But it can't hurt to see what it would take to also 
have project.max-processes.

Menno
-- 
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone.max-processes

2007-10-03 Thread Flemming Danielsen
Hi

I have found in the past that it is frustrating to find resources  
rctl that is not in sync between projects and zones definitions and  
as a costumer I would like to see them in sync.

It would also enable me to isolate applications in zones that tend to  
blow up the zone where I have other part of the workload running  
(other projects).

I would like you to consider something more appropriate then a  
unlimited value of processes in global zone. We did an experiment  
where we created about 400-500 zones and we to hit some limits in the  
default kernel when we reached 8 lwps. This will also affect the  
process limits.  I expect there is a kernel structure that needs to  
be tuned, but I have not had the need to build a 500 zones system  
yet :-) But since you put a lower limit you might investigate how o  
put in a upper limit (based on kernel structures)

On 03/10/2007, at 22.37, Menno Lageman wrote:

> Steve Lawrence wrote:
>> Have you considered also implementing project.max-processes?  This  
>> would
>> give a zone admin some control over workloads within the zone.  I  
>> would
>> follow suit and make project 0 in the global zone exempt from its
>> project.max-processes rctl.
>
> I hadn't considered project.max-processes yet, mainly because what  
> I see
> in the field is that most people seem to consider project rctls to be
> too much detail. Configuring limits at the zone level seems to be the
> preferred option. But it can't hurt to see what it would take to also
> have project.max-processes.
>
> Menno
> -- 
> Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org

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


Re: [zones-discuss] zone.max-processes

2007-10-03 Thread Menno Lageman
Steve Lawrence wrote:
> On Wed, Oct 03, 2007 at 10:37:30PM +0200, Menno Lageman wrote:
>> Steve Lawrence wrote:
>>> Have you considered also implementing project.max-processes?  This would
>>> give a zone admin some control over workloads within the zone.  I would
>>> follow suit and make project 0 in the global zone exempt from its 
>>> project.max-processes rctl.
>> I hadn't considered project.max-processes yet, mainly because what I see 
>> in the field is that most people seem to consider project rctls to be 
>> too much detail. Configuring limits at the zone level seems to be the 
>> preferred option. But it can't hurt to see what it would take to also 
>> have project.max-processes.
> 
> Besides another rctl_test in cfork, you'll also need to have a test in
> tasksys_settaskid().  Very similar to rc_project_nlwps.

Thanks for the pointer to tasksys_settaskid(). My rctl_test() is in 
getproc() btw, as that seems the most logical place.

Menno
-- 
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] zone.max-processes

2007-10-03 Thread Menno Lageman
Flemming Danielsen wrote:
> I have found in the past that it is frustrating to find resources  
> rctl that is not in sync between projects and zones definitions and  
> as a costumer I would like to see them in sync.

Flemming,

I'm not sure I understand what you mean by them being 'in sync'? I think 
from your remark below that you'd want to have both the zone and the 
project version of the max-processes rctl, right?

> 
> It would also enable me to isolate applications in zones that tend to  
> blow up the zone where I have other part of the workload running  
> (other projects).
> 
> I would like you to consider something more appropriate then a  
> unlimited value of processes in global zone. We did an experiment  
> where we created about 400-500 zones and we to hit some limits in the  
> default kernel when we reached 8 lwps. This will also affect the  
> process limits.  I expect there is a kernel structure that needs to  
> be tuned, but I have not had the need to build a 500 zones system  
> yet :-) But since you put a lower limit you might investigate how o  
> put in a upper limit (based on kernel structures)

What would you like to accomplish with the upper limit in the global 
zone? Leave more slots available for the zones? Or something else?

Menno
-- 
Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno
___
zones-discuss mailing list
zones-discuss@opensolaris.org