Re: [zones-discuss] Making zoneadm more like the other adms...

[Joerg Barfurth]

I was away a couple of days, but still wanted to comment.

Darren Reed schrieb:
> Something that really annoys me with zoneadm is that the syntax
> for its command line is different to the other new commands, ie
> the subommand comes after the zone name and the zone name
> needs to have a -z before it.
> 
> ugh.
> 
> So I went and looked at zoneadm.c - it seems well enough
> structured to make hacking easy..
> 
> The attached diffs modify zoneadm to work like this:
> 
> zoneadm boot fred
> 

But your change becomes counterintuitive (IMHO), when subcommand options 
are used. The result certainly doesn't fit any commandline standard 
(CLIP, etc) I know. The distinction between operands and arguments get 
blurred when they are positioned in arbitrary places. Typical syntax for 
command with subcommands and arguments, would be

   zoneadm detach -n fred

rather than

   zoneadm detach fred -n

OTOH a change that puts the zonename at the end is less obvious to do in 
the code and results in less obvious syntax for subcommands that have 
argument lists of their own, for example reboot:

   zoneadm reboot fred [ boot-args ]
or
   zoneadm reboot -- fred [ boot-args ]
or
   zoneadm reboot fred [-- boot-args ]

Whichof those is best/acceptable/misleading?

And the interaction with global options also is non-obvious. Why do you 
support

   zoneadm mark fred incomplete

(N.B: not 'zoneadm mark incomplete fred')
but not

   zoneadm -R /someroot mark fred incomplete


> At present my ability to test seems to be being challenged
> by networks problems/outages here at Sun, so please forgive
> me if there are some bugs (obvious or otherwise.)
> 

One obvious bug with the change is that the new setroot function doesn't 
use its 'arg' argument, but instead operates directly on the global optarg.

- Jörg

-- 
Joerg Barfurth   phone: +49 40 23646662 / x2
Software Engineermailto:[EMAIL PROTECTED]
Desktop Technology   http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software http://www.sun.com/software/sunray/
Sun Microsystems GmbHhttp://www.sun.com/software/javadesktopsystem/


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

Re: [zones-discuss] Will exclusive IP allow for TCP /etc/system settings?

[James Carlson]

Jim Nissen writes:
> Will Solaris 10 Zones, with exclusive IP, allow one to set NGZ TCP 
> tunables, like tcp_conn_req_max_q?

Yes, every zone configured as exclusive has its own TCP/IP stack
instance.

Are you asking because you've encountered some problem with this?

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Will exclusive IP allow for TCP /etc/system settings?

[Steffen Weiberle]

Jim Nissen wrote:
> Will Solaris 10 Zones, with exclusive IP, allow one to set NGZ TCP 
> tunables, like tcp_conn_req_max_q?

ndd settings can be done in an exclusive IP Instance zone.

while ndd is not a service,
http://www.opensolaris.org/os/project/crossbow/faq/#ipinst_services

/etc/system applies to the whole system (per your subject line)

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

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

Re: [zones-discuss] need input for zone update on attach

[Steffen Weiberle]

Jerry Jelinek wrote:
> During testing of the zone "update on attach" feature
> we have encountered a problem with IDRs on S10.
> 
> If you are not familiar with an IDR, it is a temporary,
> one-time patch that is issued to try to solve a problem
> before an official patch is released.  Because these
> are temporary, one-time patches, there is no metadata
> in official patches to tell us if the IDR is obsoleted or
> not.  Because we don't know if the IDR is obsoleted by
> some other patch, "update on attach" will require
> that any IDRs installed on the source system must also be
> installed on the target system.
> 
> If you have a zone that you are migrating because of
> a disaster recovery situation where the original system
> is no longer available, and the original system had
> an IDR installed that is not on the target (e.g. s10u4
> with IDR to S10u6 where IDR is not needed), then there is
> no way to migrate the zone and update it to match the
> target if the IDR does not apply to the target system.
> 
> If the original system is still available, you can work
> around this by removing the IDR before migrating the zone.
> 
> I have a few different ideas for how to handle this.
> 
> 1) change the meaning of attach -u -F
> Right now -F just forces the attach, changes the zone
> state to installed and we're done.  No update occurs.  We
> could change the interaction of these two options so that
> we still do the update but ignore any verification warnings.
> However this would allow a potentially major downgrade.
> 
> 2) attach -u -p xxx -p yyy 
> Add a new -p option which allows you to specify patches to
> ignore.  We would use this to specify IDRs which don't
> exist on the target, although it could also be used for
> regular patches that might be broken.
> The user would have to understand this at a pretty good
> level to know when to use the option.  We might want to extend
> this idea to specify pkgs as well, in case we have a broken
> pkg.  This allows a potentially major downgrade if the user
> specifies a lot of patches.

I am not sure I have an opinion yet, as I am not sure what "major 
downgrade" means. If that would allow you detach the zone from the new 
system and re-attach on the original, I can see a benefit. (The 
inability to attach a zone on its original system is my biggest concern 
with the upgrade on attach.)

One thought with 2) is to also consider -P filename, where filename 
lists the patches or packages. Similar to -x and -X for flarcreate.

Steffen

> 
> 3) attach -u -i
> Add a new -i option which means ignore all IDRs.
> This is pretty specific to the IDR issue, doesn't require a
> lot of thought for the user, but doesn't give much flexibility
> if we hit a different problem with bad patches or pkgs.
> This forces the user to think about the impact of ignoring
> the IDRs before an update is done.
> 
> 4) attach -u
> No change to the CLI but change the implementation to
> always ignore all missing IDRs.
> This might still allow a pretty big downgrade with no
> user input if you had a lot of IDRs on the source system for
> some reason.  This is pretty specific to the IDR issue, doesn't
> require any thought for the user, but doesn't give much flexibility
> if we hit a different problem with bad patches or pkgs.
> 
> Let me know what you think about these choices or if there is
> another idea that seems better.
> 
> Thanks,
> Jerry
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org

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

Re: [zones-discuss] Will exclusive IP allow for TCP /etc/system settings?

[Jim Nissen]

James,
No, asking simply because the Solaris tunables guide list both those TCP 
settings that are changed via ndd and other that are /etc/system.  
Customer's asking me if exclusive IP will allow for a NGZ to have its 
own /etc/system TCP tunables, or if they are global.


I think Steffen addressed this.

Thanks to all,
Jim

James Carlson wrote:

Jim Nissen writes:
  
Will Solaris 10 Zones, with exclusive IP, allow one to set NGZ TCP 
tunables, like tcp_conn_req_max_q?



Yes, every zone configured as exclusive has its own TCP/IP stack
instance.

Are you asking because you've encountered some problem with this?

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

Re: [zones-discuss] Will exclusive IP allow for TCP /etc/system settings?

[James Carlson]

Jim Nissen writes:
> No, asking simply because the Solaris tunables guide list both those TCP 
> settings that are changed via ndd and other that are /etc/system.  
> Customer's asking me if exclusive IP will allow for a NGZ to have its 
> own /etc/system TCP tunables, or if they are global.

/etc/system is still global because there's still only one system
kernel.  That's the essence of zones.

/etc/system and ndd are unrelated, which is what confused me here.
Except for a few cases where there are "mirrored" bits (and likely
things that are actually bugs), you can't set ndd variables in
/etc/system, and you can't set /etc/system variables via ndd, and this
is by design.

/etc/system works by scribbling on top of kernel storage named by
symbols in the object files.  It's essentially equivalent to "/W" in
mdb during the boot process -- you're writing directly to a variable,
and perhaps even one that's declared "static" by the original author.

ndd is more programmatic.  It opens the named device node (e.g,
/dev/tcp) and issues an undocumented ioctl.  The driver (and any
STREAMS modules in between) then gets the ioctl and can decide to do
anything it wants with it.  Sometimes, it sets a variable somewhere,
or perhaps modifies multiple variables.  Other ndd ioctls cause other
functions to be called, locks to be taken, and other work done.
Unlike /etc/system, the possibilities are endless.

-- 
James Carlson, Solaris Networking  <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Will exclusive IP allow for TCP /etc/system settings?

[Steffen Weiberle]

Jim Nissen wrote:
> James,
> No, asking simply because the Solaris tunables guide list both those TCP 
> settings that are changed via ndd and other that are /etc/system.  
> Customer's asking me if exclusive IP will allow for a NGZ to have its 
> own /etc/system TCP tunables, or if they are global.
> 
> I think Steffen addressed this.

I was going to include this reference in my previous response...

http://docs.sun.com/app/docs/doc/817-0404/chapter1-1?a=view

A lot of things that used to be in /etc/system are no longer there since

1. it does no syntax checking
2. it applies to the whole system
3. it requires a reboot to take effect

So I think the answer is still that you do general IP stack tuning on 
the zone that "owns" the stack--the global zone for share IP Instances, 
and the individual non-global zone(s) for exclusive IP Instances.

Things you still may tune in /etc/system affect drivers, and some things 
such as ip_squeue_fanout. I suspect the list of non-driver, non-NFS 
tunables via /etc/system is small.

Steffen

> 
> Thanks to all,
> Jim
> 
> James Carlson wrote:
>> Jim Nissen writes:
>>   
>>> Will Solaris 10 Zones, with exclusive IP, allow one to set NGZ TCP 
>>> tunables, like tcp_conn_req_max_q?
>>> 
>>
>> Yes, every zone configured as exclusive has its own TCP/IP stack
>> instance.
>>
>> Are you asking because you've encountered some problem with this?
>>
>>   
> 
> 
> 
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org

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

[zones-discuss] Question on testing Solaris 10 Zones

[Paul Neal]

Hi,

The Navy is asking us the following question on Solaris 10 Zones.

"We need tests to ensure the installs are correct and the configures had 
not changed.  Also, we need to test the integrity of the Zones (ensuring 
there is no data spillage between zones)?"

Is this something we can provide?

Thanks,

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

[zones-discuss] Memory Cap accounting for shared memory

[Brian Smith]

My reading of the documentation is that if I try to cap the memory of a
zone, that cap applies to the total RSS, calculated by summing the RSS of
each process in the zone. According to the documentation, there is not any
accounting for processes sharing memory. For example, if I have 10 processes
with private RSS of 2MB each and shared RSS of 100MB, then the zone would be
considered to be using 10*(2+100)=1,020MB of memory, and not 100+2*10=120MB
of memory. Restricting the zone to 500MB would make it practically unusable
even though only 120MB of memory is being used. Is that correct? Is there
any way to cause rcapd to take shared memory into account when deciding
which zones to start swapping to disk?

Regards,
Brian

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

[zones-discuss] Rcapd threshold vs ZFS cache

[Brian Smith]

When rcapd is calculating how much memory is free, to compare to the memory
cap enforcement threshold, does it consider the memory used by the ZFS cache
to be free or used? If I set "rcapadm -c 90" then will rcapd behave any
differently than with "rcapadm -c 0" if there is a ZFS cache? I have read
that the ZFS cache will use all free physical RAM.

Regards,
Brian

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

Re: [zones-discuss] Memory Cap accounting for shared memory

[Steve Lawrence]

As of s10u4, (and nevada build 56?) rcapd (and prstat -ZJTta) account for
shared memory (both sysV, anon, and text) between processes in the same zone,
project, etc.

-Steve L.

On Wed, Jun 18, 2008 at 01:13:21PM -0500, Brian Smith wrote:
> My reading of the documentation is that if I try to cap the memory of a
> zone, that cap applies to the total RSS, calculated by summing the RSS of
> each process in the zone. According to the documentation, there is not any
> accounting for processes sharing memory. For example, if I have 10 processes
> with private RSS of 2MB each and shared RSS of 100MB, then the zone would be
> considered to be using 10*(2+100)=1,020MB of memory, and not 100+2*10=120MB
> of memory. Restricting the zone to 500MB would make it practically unusable
> even though only 120MB of memory is being used. Is that correct? Is there
> any way to cause rcapd to take shared memory into account when deciding
> which zones to start swapping to disk?
> 
> Regards,
> Brian
> 
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org

[zones-discuss] rcapd interactions between global and local zones?

[James Litchfield]

I'm struggling with the resource capping documentation. This environment 
uses zones
and the documentation is frustratingly vague about resource capping and 
zones.

A) If I run rcapd in the global zone and have resource settings via 
zonecfg for one or more zones,
   it would seem to me that I would not want to run rcapd in any local 
zones with capped-memory
   settings since that since both might end up working on the same 
process and possibly deadlock?

B) If I do not have capped-memory settings for the zones in the zonecfg, 
I should be able to
   run rcapd in the global zone and rcapd in local zones?

Any other limitations?

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

Re: [zones-discuss] Rcapd threshold vs ZFS cache

[Steve Lawrence]

ZFS cache memory is not considered free.  rcapd uses the
sysconf(_SC_AVPHYS_PAGES) interface to get the amount of free memory.
One possibility could be to alter sysconf to report some about of the
zfs cache as free.

-Steve L.

On Wed, Jun 18, 2008 at 01:18:07PM -0500, Brian Smith wrote:
> When rcapd is calculating how much memory is free, to compare to the memory
> cap enforcement threshold, does it consider the memory used by the ZFS cache
> to be free or used? If I set "rcapadm -c 90" then will rcapd behave any
> differently than with "rcapadm -c 0" if there is a ZFS cache? I have read
> that the ZFS cache will use all free physical RAM.
> 
> Regards,
> Brian
> 
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org

[zones-discuss] Adding devices to NGZ's

[Geoff Shipman]

Hello All,

I have a question on how zoneadm determines what devices it will add to
a NGZ's.   I have a disk device that is displayed as /dev/dsk/c1t0d0s7
by the global zone the device works fine when added as a dsk/rdsk device
for the NGZ.

When I create my own device link in /dev/dsk and /dev/rdsk for my device
now called mydisk the zonecfg takes the update but the zone when booted
does not list the device.

I tried adding both sets of devices in case the kernel did not like one
existing in the global environment but still only the c1t0d0s7 device is
listed in the NGZ environment.

Any insight would be greatly appreciated.

Geoff

Using the c1t0d0s7 device name:
# zonecfg -z pcgalzone
zonecfg:pcgalzone> add device
zonecfg:pcgalzone:device> set match=/dev/rdsk/c1t0d0s7
zonecfg:pcgalzone:device> end
zonecfg:pcgalzone> info
zonename: pcgalzone
zonepath: /zone
brand: native
autoboot: false
bootargs:
pool:
limitpriv:
scheduling-class:
ip-type: shared
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
device
match: /dev/rdsk/c1t0d0s7
zonecfg:pcgalzone> verify
zonecfg:pcgalzone> exit
# zoneadm -z pcgalzone boot
# ls -l /zone/dev/rdsk
total 0
crw-r-   1 root sys  136, 15 Jun 17 19:58 c1t0d0s7
# zlogin pcgalzone
[Connected to zone 'pcgalzone' pts/3]
Last login: Tue Jun 17 19:40:57 on console
Sun Microsystems Inc.   SunOS 5.10  Generic January 2005
# ls -l /dev/rdsk
total 0
crw-r-   1 root sys  136, 15 Jun 17 19:58 c1t0d0s7
# zonecfg -z pcgalzone
zonecfg:pcgalzone> add device
zonecfg:pcgalzone:device> set match=/dev/dsk/c1t0d0s7
zonecfg:pcgalzone:device> end
zonecfg:pcgalzone> verify
zonecfg:pcgalzone> commit
zonecfg:pcgalzone> exit
# pwd
/
# cd /dev/dsk
# chown -R -H 3207:200 c1t0d0s7
# ls -l c1t0d0s7 ; ls -lL c1t0d0s7
lrwxrwxrwx   1 root root  38 May  7 17:58 c1t0d0s7 ->
../../devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:h
brw-r-   1 oracle   dba  136, 15 Jun 18 11:57 c1t0d0s7
# zoneadm -z pcgalzone halt
# zoneadm -z pcgalzone boot
# zlogin pcgalzone
[Connected to zone 'pcgalzone' pts/3]
Last login: Tue Jun 17 19:59:55 on pts/3
Sun Microsystems Inc.   SunOS 5.10  Generic January 2005
# ls -l /dev/dsk
total 0
brw-r-   1 root sys  136, 15 Jun 18 11:58 c1t0d0s7
# mount /dev/dsk/c1t0d0s7 /mnt
# ls -l /mnt
total 16
drwx--   2 root root8192 May  7 17:07 lost+found
# mkfile 200m /mnt/testfile
# ls -l /mnt
total 409840
drwx--   2 root root8192 May  7 17:07 lost+found
-rw---   1 root root 209715200 Jun 18 12:00 testfile
# df -h
Filesystem size   used  avail capacity  Mounted on
/  4.8G   752M   4.0G16%/
/dev   4.8G   752M   4.0G16%/dev
/lib   4.8G   752M   4.0G16%/lib
/platform  4.8G   752M   4.0G16%/platform
/sbin  4.8G   752M   4.0G16%/sbin
/usr   4.8G   2.9G   1.8G62%/usr
proc 0K 0K 0K 0%/proc
ctfs 0K 0K 0K 0%/system/contract
mnttab   0K 0K 0K 0%/etc/mnttab
objfs0K 0K 0K 0%/system/object
swap   1.0G   328K   1.0G 1%/etc/svc/volatile
fd   0K 0K 0K 0%/dev/fd
swap   1.0G32K   1.0G 1%/tmp
swap   1.0G32K   1.0G 1%/var/run
/dev/dsk/c1t0d0s7   15G   215M14G 2%/mnt
# exit

[Connection to zone 'pcgalzone' pts/3 closed]

# ls -l /dev/dsk/c1t0d0s7 /dev/rdsk/c1t0d0s7
lrwxrwxrwx   1 root root  38 May  7 17:58 /dev/dsk/c1t0d0s7
-> ../../devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:h
lrwxrwxrwx   1 root root  42 May  7 17:58 /dev/rdsk/c1t0d0s7
-> ../../devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:h,raw


Using the mydisk link:

# zlogin pcgalzone
[Connected to zone 'pcgalzone' pts/3]
Last login: Wed Jun 18 12:10:27 on pts/3
Sun Microsystems Inc.   SunOS 5.10  Generic January 2005
# ls -l /dev/dsk
total 0
# ls -l /dev/rdsk
total 0
# format
Searching for disks...done
No disks found!

#
# uname -a
SunOS pcgalzone 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Blade-100
# exit

[Connection to zone 'pcgalzone' pts/3 closed]
# zonecfg -z pcgalzone export
create -b
set zonepath=/zone
set autoboot=false
set ip-type=shared
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add device
set match=/dev/rdsk/mydisk
end
add device
set match=/dev/dsk/mydisk
end
# ls -l /dev/rdsk/mydisk /dev/dsk/mydisk
lrwxrwxrwx   1 root root  38 Jun 18 12:12 /dev/dsk/mydisk ->
../../devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PRO

Re: [zones-discuss] Making zoneadm more like the other adms...

[Darren Reed]

Joerg Barfurth wrote:

> I was away a couple of days, but still wanted to comment.
>
> Darren Reed schrieb:
>
>> Something that really annoys me with zoneadm is that the syntax
>> for its command line is different to the other new commands, ie
>> the subommand comes after the zone name and the zone name
>> needs to have a -z before it.
>>
>> ugh.
>>
>> So I went and looked at zoneadm.c - it seems well enough
>> structured to make hacking easy..
>>
>> The attached diffs modify zoneadm to work like this:
>>
>> zoneadm boot fred
>>
>
> But your change becomes counterintuitive (IMHO), when subcommand 
> options are used. The result certainly doesn't fit any commandline 
> standard (CLIP, etc) I know.


Compare the usage of zoneadm with svcadm, dladm, zfs or
any of the other newer *adm commands that have a subcommand
directly after the command name.

Furthermore, I'm not concerned with any _official_ standard,
we seem to be making up our own "standards" as we go.

I think having all of our commands that have subcommands be
consistent in use within the same operating system is of value,
don't you?


> The distinction between operands and arguments get blurred when they 
> are positioned in arbitrary places. Typical syntax for command with 
> subcommands and arguments, would be
>
>zoneadm detach -n fred
>
> rather than
>
>zoneadm detach fred -n


This wasn't a focus of what I was doing...

But in all seriousness, if the subcommand is going to
follow the command name then the other important
change is to have the key be at the end.


> OTOH a change that puts the zonename at the end is less obvious to do 
> in the code and results in less obvious syntax for subcommands that 
> have argument lists of their own, for example reboot:
>
>zoneadm reboot fred [ boot-args ]
> or
>zoneadm reboot -- fred [ boot-args ]
> or
>zoneadm reboot fred [-- boot-args ]
>
> Whichof those is best/acceptable/misleading?


Considering that I do:
reboot -- net - install
it would seem that the best is the last.

>
> And the interaction with global options also is non-obvious. Why do 
> you support
>
>zoneadm mark fred incomplete
>
> (N.B: not 'zoneadm mark incomplete fred')
> but not
>
>zoneadm -R /someroot mark fred incomplete


Because doing that was going to take longer than the short period
of time I set aside to experiment with this - in this case, parsing the
-R needs to be moved to be after the subcommand.

Darren

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

Re: [zones-discuss] Rcapd threshold vs ZFS cache

[Steffen Weiberle]

Brian Smith wrote:
> When rcapd is calculating how much memory is free, to compare to the memory
> cap enforcement threshold, does it consider the memory used by the ZFS cache
> to be free or used? If I set "rcapadm -c 90" then will rcapd behave any
> differently than with "rcapadm -c 0" if there is a ZFS cache? I have read
> that the ZFS cache will use all free physical RAM.

IIRC, the ARC is limit to 3/4 of total memory. That is the max, it may 
use [much] less, depending on overall memory use.

In your case, where you are allowing up to 90%, the ARC may get small if 
that memory is actually getting used. zfs-discuss is a good place to get 
info regarding ARC vs VM memory

> 
> Regards,
> Brian
> 
> ___
> zones-discuss mailing list
> zones-discuss@opensolaris.org

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

Re: [zones-discuss] Making zoneadm more like the other adms...

[Steve Lawrence]

Hey Darren,

Are you interested in drafting an arc fasttrack for these interface additions?
Do you see zoneadm being used as:

# zoneadm boot myzone -s

That would be:
- myzone is an operand to zoneadm that comes after the subcommand.

This is not compliant with getopt or clip guidelines.  You may
want to review the info here:

http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/

I think the usability issue is with the zoneadm syntax:

# command -opt optarg subcommand ...

The above clip guidlines make this comment:

Q: I'd like to have options before my subcommands. This makes sense because
   some options apply to all operations.

A: This often makes sense from an engineering perspective, but our
usability data says most users don't understand the system model well
enough to be able to predict whether the option should go before or after   
the subcommand.

>From this you could argue that the current zoneadm command is getopt, but not
fully clip compliant.

I think that you are proposing that the zonename could also take a special
operand to the zoneadm command, which comes after the subcommand.

The "good" commands that you are comparing zoneadm to were nice enough to not
have any options/optargs before the subcommand.

You might try running a fastrack, arguing that the syntax:

# zoneadm boot myzone -m milestone=single-user
being:
# command subcommand operand suboptions suboperands

while conforming to no standards/guidelines, is more usable than:

# command option optarg subcommand suboptions suboperand.

I think this could be defined as:

if -z is not present, a subcommand is present, and the token after
the subcommand is not an option, then it is the operand to an
implicit -z.

This is of course not compliant with anything.  You could argue that this
is more usable anyway, or you could find a compliant solution.

-Steve L.

On Sun, Jun 15, 2008 at 06:15:46PM -0700, Darren Reed wrote:
> Tony Ambrozie wrote:
> 
> > Your code changes for both zoneadm and zonecfg would preserve the 
> > current zonexxx -z zonename for backwards compatibility purposes, is 
> > that correct?
> 
> 
> Correct.  There are some command line options that the changes I've
> made don't support, such as using -R.  That's quite deliberate.
> 
> The aim of the changes was to address the common use cases of the
> commands and make their use more intuitive when viewed with the
> other commands in OpenSolaris.
> 
> Darren
> 
> >
> > Thank you,
> >
> >
> > On Mon, Jun 9, 2008 at 11:51 AM, Darren Reed <[EMAIL PROTECTED] 
> > > wrote:
> >
> > Someone mentioned zonecfg was the cause of some similar awkwardness...
> >
> > So here's a patch attached for that.
> >
> > Darren
> >
> >
> >
> > --- usr/src/cmd/zonecfg/zonecfg.c ---
> >
> > Index: usr/src/cmd/zonecfg/zonecfg.c
> > *** /biscuit/onnv/usr/src/cmd/zonecfg/zonecfg.c Mon Mar 24
> > 17:30:38 2008
> > --- /biscuit/onnv_20080608/usr/src/cmd/zonecfg/zonecfg.c  
> >  Mon Jun  9 11:47:41 2008
> > ***
> > *** 1071,1076 
> > --- 1071,1077 
> >execname, cmd_to_str(CMD_HELP));
> >(void) fprintf(fp, "\t%s -z \t\t\t(%s)\n",
> >execname, gettext("interactive"));
> > +   (void) fprintf(fp, "\t%s  \n",
> > execname);
> >(void) fprintf(fp, "\t%s -z  \n",
> > execname);
> >(void) fprintf(fp, "\t%s -z  -f
> > \n",
> >execname);
> > ***
> > *** 6653,6689 
> >return (execbasename);
> >  }
> >
> > ! int
> > ! main(int argc, char *argv[])
> >  {
> > !   int err, arg;
> > !   struct stat st;
> > !
> > !   /* This must be before anything goes to stdout. */
> > !   setbuf(stdout, NULL);
> > !
> > !   saw_error = B_FALSE;
> > !   cmd_file_mode = B_FALSE;
> > !   execname = get_execbasename(argv[0]);
> > !
> > !   (void) setlocale(LC_ALL, "");
> > !   (void) textdomain(TEXT_DOMAIN);
> > !
> > !   if (getzoneid() != GLOBAL_ZONEID) {
> > !   zerr(gettext("%s can only be run from the global
> > zone."),
> > !   execname);
> > !   exit(Z_ERR);
> > !   }
> > !
> > !   if (argc < 2) {
> > !   usage(B_FALSE, HELP_USAGE | HELP_SUBCMDS);
> >exit(Z_USAGE);
> >}
> > !   if (strcmp(argv[1], cmd_to_str(CMD_HELP)) == 0) {
> > !   (void) one_command_at_a_time(argc - 1, &(argv[1]));
> > !   exit(Z_OK);
> > !   }
> >
> >while ((arg = getopt(argc, argv, "?f:R:z:")) != EOF) {
> >switch (arg) {
> >c

Re: [zones-discuss] need input for zone update on attach

[Mike Gerdts]

On Wed, Jun 18, 2008 at 8:47 AM, Steffen Weiberle
<[EMAIL PROTECTED]> wrote:
> I am not sure I have an opinion yet, as I am not sure what "major
> downgrade" means. If that would allow you detach the zone from the new
> system and re-attach on the original, I can see a benefit. (The
> inability to attach a zone on its original system is my biggest concern
> with the upgrade on attach.)

The combination of update on attach plus zones on ZFS should make this
problem be one that isn't too scary.  I imagine the following as being
standard practice.

zfs snapshot zones/[EMAIL PROTECTED]
zoneadm -z $zone attach -u
if [ $? != 0 ] ; then
zfs rollback zones/[EMAIL PROTECTED]
fi

Of course, it would be nice if zoneadm would just do this on its own.

> One thought with 2) is to also consider -P filename, where filename
> lists the patches or packages. Similar to -x and -X for flarcreate.

The only reason I would say not to use another option is to keep the
option free for other things in the future.  I think that the IDR
situation will be rare and the probability that a lot of IDR's exist
on a single system is quite unlikely.  Assuming that the
Indiana/OpenSolaris approach to packaging is integrated as the
replacement for current packaging+patching then this functionality
will not really be needed post S10 and as such also suggests that
keeping the option free for something else may make sense.

If I am wrong about the likelihood of having a longish list of patches
to ignore, then I think the -P option makes sense.

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] need input for zone update on attach

[Dan Price]

On Wed 18 Jun 2008 at 10:36PM, Mike Gerdts wrote:
> On Wed, Jun 18, 2008 at 8:47 AM, Steffen Weiberle
> <[EMAIL PROTECTED]> wrote:
> > I am not sure I have an opinion yet, as I am not sure what "major
> > downgrade" means. If that would allow you detach the zone from the new
> > system and re-attach on the original, I can see a benefit. (The
> > inability to attach a zone on its original system is my biggest concern
> > with the upgrade on attach.)
> 
> The combination of update on attach plus zones on ZFS should make this
> problem be one that isn't too scary.  I imagine the following as being
> standard practice.
> 
> zfs snapshot zones/[EMAIL PROTECTED]
> zoneadm -z $zone attach -u
> if [ $? != 0 ] ; then
> zfs rollback zones/[EMAIL PROTECTED]
> fi
>
> Of course, it would be nice if zoneadm would just do this on its own.

Yeah, we thought that up a couple of weeks ago and there's an RFE
filed.

-dp

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