|
Replies:
10
-
Last Post:
Jul 24, 2006 5:46 AM
by: gjelinek
|
|
|
Posts:
812
From:
US
Registered:
3/9/05
|
|
|
|
Proposal: Zone Boot Arguments II
Posted:
Apr 24, 2006 2:17 PM
|
|
Hi all; I've just submitted the following proposal to our Architecture
Review Process. The timer is set for one week (5/1/2006). I would
really appreciate your feedback on this feature and any questions or
comments you may have by that time. I realize that some of this case
refers to earlier caselogs not available, but I think the proposal will
make sense anyway.
I hope to make a webrev of the changes available in the next few days as
I put the finishing touches on the code.
Thanks for your feedback!
-dp
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Zone Boot Arguments II
Daniel Price (dp@eng)
A. Introduction
This case modifies the Solaris Zones [1] architecture and describes
how zones will handle boot arguments.
This case is intended to supersede an earlier case "Zone Boot Arguments"[2]
which contains some insufficiently researched information, insufficiently
describes the interface, and was never implemented. This case also
obsoletes the syntax of the '-s' interface specified in
"Single-User Zone Boot" [3] but does not remove it at this time.
The proposed changes are Evolving (or Stable, depending on the terminology
currently in effect). The binding for new features is "patch." The binding
for obsoleted interfaaces is "minor."
B. Interface Table
Interface Stability Binding
---------------------------------------------------------
-s for zones [old style] Obsolete Minor
-s for zones [new style] Evolving Patch
-i for zones Evolving Patch
-m for zones Evolving Patch
C. Background
An earlier case, "Single-User Zone Boot"[3] documents the "-s" boot
argument for zones:
zoneadm -z myzone boot -s
This was primarily done in support of admin/install work ongoing at that
time. This support has several important limitations:
- It is limited to the -s argument.
- It does not work for 'zoneadm reboot' or reboot(1m) inside
the zone.
- It does not mimic the syntax of the most obviously related command,
reboot(1m), which requires a "--" (or other string to stop getopt())
to separate arguments to reboot from arguments to boot. As a
reminder, in Solaris:
# reboot -s
Is not valid syntax.
- It mixes together arguments to the 'zoneadm' command with arguments
ultimately interpreted by init(1m).
- Administrators running inside the zone are not able to pass
options to reboot.
PSARC/2005/167, "Zone Boot Arguments" was intended to solve these problems;
however, the case is not clearly specified and promises features we are
choosing not to deliver (see Section F below). This cases supersedes PSARC
2005/167, which will be marked as such following approval of this case.
D. New Arguments for Zone Boot
This proposal adds support for the following additional boot arguments:
- -m <arg>, which was introduced by the SMF project[4]
- -i </path/t
This proposal anticipates the BrandZ project by adding the kernel plumbing
needed to boot an arbitrary program as 'init'. Additionally, the argument
processing has been architected in a fashion which should allow brands to
plug in new boot argument parsers (since, e.g. -m may be invalid, or mean
something different on other OS's).
This proposal allows boot arguments to be specified for 'zoneadm boot',
'zoneadm reboot' and for reboot(1m), following a getopt delimiter (--)
or boot file argument (also see Section C.4 below)
The preferred syntax is:
zoneadm -z myzone boot -- -s
zoneadm -z myzone reboot -- -i /sbin/myinit
reboot -- -m verbose
Support for specifying the '-s' option in the old way will continue
to be supported.
zoneadm -z myzone boot -s
However, documentation for this feature will be removed and replaced with
the new style syntax.
E. Boot Argument Persistence
This proposal adds the ability to persistently specify boot arguments
for zones using the zonecfg(1m) command, as follows:
# zonecfg -z myzone
zonecfg:myzone> set bootargs="-m verbose"
zonecfg:myzone> info bootargs
bootargs: -m verbose
zonecfg:myzone> ^D
This setting will be applied unless overridden by 'reboot', 'zoneadm boot'
or 'zoneadm reboot'. In this respect it is similar to existing system
behavior currently supported by the eeprom(1m) tool.
It is worthwhile to note that this proposal does not alter the fact
that eeprom(1m) is not functional inside of a zone.
F. Arbitrary Boot Parameters
PSARC 2005/167 explained that:
>
> This will make it possible to pass arbitrary boot parameters to a
> zone:
>
> zoneadmd -z local0 boot -- mumble
However, the case neglected to note that this facility is *not* available
for "regular" Solaris boot, which handles the first such argument as the
name of the object to boot, and subsequent arguments as follows:
global# reboot -- kernel/unix mumble
...
(system reboots)
...
krtld: Unused kernel arguments: `mumble'.
...
krtld then discards the extraneous argument (i.e. 'init' never gets to
see 'mumble' in the example). At this time, we do not believe the utility
of this facility outweighs the confusion that it could cause; we'd rather
not be in the following situation:
global# reboot foo bar (boot the file called foo, with bar as
an argument to init(1m))
myzone# reboot foo bar (boot the zone, with foo and bar as
arguments to init(1m))
If demand for this feature occurs in the future, this issue can be revisited
in future case materials.
In the event that the user specifies a boot file for a boot or reboot, we will
detect and silently discard it; thus the following will "just work" from
inside a zone:
myzone# reboot kernel/unix -s
G. References
1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris
2. PSARC 2005/167 Zone Boot Arguments
3. PSARC 2004/602 Single-User Zone Boot
4. PSARC 2002/547 Greenline
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
De Mena, Ron
ron.demena@eds.com
|
|
|
|
RE: Proposal: Zone Boot Arguments II
Posted:
Apr 25, 2006 6:44 AM
in response to: dp
|
|
I personally think that the obsolescing of -s would be Major not minor.
ISVs that many of us users and administrators depend on, potentially,
may have to change their own software to support it. The earliest and
safest opportunity to phase it out would probably be Nevada in my
opinion ... especially given the difficulty in getting Solaris 10
adopted thus far.
Additionally putting another item into the zonecfg XML opens more
opportunity for existing software that edits the XML files, against all
warnings, to edit more of it.
-- Ron
-----Original Message-----
From: zones-discuss-bounces at opensolaris dot org
[mailto:zones-discuss-bounces at opensolaris dot org] On Behalf Of Dan Price
Sent: Monday, April 24, 2006 5:18 PM
To: zones-discuss at opensolaris dot org
Subject: [zones-discuss] Proposal: Zone Boot Arguments II
Hi all; I've just submitted the following proposal to our Architecture
Review Process. The timer is set for one week (5/1/2006). I would
really appreciate your feedback on this feature and any questions or
comments you may have by that time. I realize that some of this case
refers to earlier caselogs not available, but I think the proposal will
make sense anyway.
I hope to make a webrev of the changes available in the next few days as
I put the finishing touches on the code.
Thanks for your feedback!
-dp
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - Zone Boot Arguments II Daniel Price (dp@eng)
A. Introduction
This case modifies the Solaris Zones [1] architecture and describes how
zones will handle boot arguments.
This case is intended to supersede an earlier case "Zone Boot
Arguments"[2] which contains some insufficiently researched information,
insufficiently describes the interface, and was never implemented. This
case also obsoletes the syntax of the '-s' interface specified in
"Single-User Zone Boot" [3] but does not remove it at this time.
The proposed changes are Evolving (or Stable, depending on the
terminology currently in effect). The binding for new features is
"patch." The binding for obsoleted interfaaces is "minor."
B. Interface Table
Interface Stability Binding
---------------------------------------------------------
-s for zones [old style] Obsolete Minor
-s for zones [new style] Evolving Patch
-i for zones Evolving Patch
-m for zones Evolving Patch
C. Background
An earlier case, "Single-User Zone Boot"[3] documents the "-s" boot
argument for zones:
zoneadm -z myzone boot -s
This was primarily done in support of admin/install work ongoing at that
time. This support has several important limitations:
- It is limited to the -s argument.
- It does not work for 'zoneadm reboot' or reboot(1m) inside
the zone.
- It does not mimic the syntax of the most obviously related
command,
reboot(1m), which requires a "--" (or other string to stop
getopt())
to separate arguments to reboot from arguments to boot. As a
reminder, in Solaris:
# reboot -s
Is not valid syntax.
- It mixes together arguments to the 'zoneadm' command with
arguments
ultimately interpreted by init(1m).
- Administrators running inside the zone are not able to pass
options to reboot.
PSARC/2005/167, "Zone Boot Arguments" was intended to solve these
problems; however, the case is not clearly specified and promises
features we are choosing not to deliver (see Section F below). This
cases supersedes PSARC 2005/167, which will be marked as such following
approval of this case.
D. New Arguments for Zone Boot
This proposal adds support for the following additional boot arguments:
- -m <arg>, which was introduced by the SMF project[4]
- -i </path/t
This proposal anticipates the BrandZ project by adding the kernel
plumbing needed to boot an arbitrary program as 'init'. Additionally,
the argument processing has been architected in a fashion which should
allow brands to plug in new boot argument parsers (since, e.g. -m may be
invalid, or mean something different on other OS's).
This proposal allows boot arguments to be specified for 'zoneadm boot',
'zoneadm reboot' and for reboot(1m), following a getopt delimiter (--)
or boot file argument (also see Section C.4 below) The preferred syntax
is:
zoneadm -z myzone boot -- -s
zoneadm -z myzone reboot -- -i /sbin/myinit
reboot -- -m verbose
Support for specifying the '-s' option in the old way will continue to
be supported.
zoneadm -z myzone boot -s
However, documentation for this feature will be removed and replaced
with the new style syntax.
E. Boot Argument Persistence
This proposal adds the ability to persistently specify boot arguments
for zones using the zonecfg(1m) command, as follows:
# zonecfg -z myzone
zonecfg:myzone> set bootargs="-m verbose"
zonecfg:myzone> info bootargs
bootargs: -m verbose
zonecfg:myzone> ^D
This setting will be applied unless overridden by 'reboot', 'zoneadm
boot'
or 'zoneadm reboot'. In this respect it is similar to existing system
behavior currently supported by the eeprom(1m) tool.
It is worthwhile to note that this proposal does not alter the fact that
eeprom(1m) is not functional inside of a zone.
F. Arbitrary Boot Parameters
PSARC 2005/167 explained that:
>
> This will make it possible to pass arbitrary boot parameters to a
> zone:
>
> zoneadmd -z local0 boot -- mumble
However, the case neglected to note that this facility is *not*
available for "regular" Solaris boot, which handles the first such
argument as the name of the object to boot, and subsequent arguments as
follows:
global# reboot -- kernel/unix mumble
...
(system reboots)
...
krtld: Unused kernel arguments: `mumble'.
...
krtld then discards the extraneous argument (i.e. 'init' never gets to
see 'mumble' in the example). At this time, we do not believe the
utility of this facility outweighs the confusion that it could cause;
we'd rather not be in the following situation:
global# reboot foo bar (boot the file called foo, with bar as
an argument to init(1m))
myzone# reboot foo bar (boot the zone, with foo and bar as
arguments to init(1m))
If demand for this feature occurs in the future, this issue can be
revisited in future case materials.
In the event that the user specifies a boot file for a boot or reboot,
we will detect and silently discard it; thus the following will "just
work" from inside a zone:
myzone# reboot kernel/unix -s
G. References
1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2.
PSARC 2005/167 Zone Boot Arguments 3. PSARC 2004/602 Single-User Zone
Boot 4. PSARC 2002/547 Greenline
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com -
blogs.sun.com/dp _______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: Proposal: Zone Boot Arguments II
Posted:
Apr 25, 2006 7:01 AM
in response to: De Mena, Ron
|
|
>I personally think that the obsolescing of -s would be Major not minor.
>ISVs that many of us users and administrators depend on, potentially,
>may have to change their own software to support it. The earliest and
>safest opportunity to phase it out would probably be Nevada in my
>opinion ... especially given the difficulty in getting Solaris 10
>adopted thus far.
Nevada is a "minor" release. "Major" would mean making "SunOS 6.x"
which is something we'll likely never do.
That's why "-s" stays in S10 but will be removed from "Nevada" (probably)
and you will need to use -- -s.
Casper
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,813
From:
US
Registered:
3/9/05
|
|
|
|
RE: Proposal: Zone Boot Arguments II
Posted:
Apr 25, 2006 7:25 AM
in response to: De Mena, Ron
|
|
De Mena, Ron writes:
> I personally think that the obsolescing of -s would be Major not minor.
"Obsolescence" in ARC terminology doesn't mean actual removal. It
means that the feature is considered to be obsolete, and the
documentation is updated to indicate this (and point to a new way to
accomplish the same thing).
Obsolescence itself doesn't require a major or minor release. Removal
does.
Some other groups use the term "deprecated" for this sort of state.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.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 at opensolaris dot org
|
|
|
|
|
Posts:
812
From:
US
Registered:
3/9/05
|
|
|
|
Re: Proposal: Zone Boot Arguments II
Posted:
Apr 25, 2006 10:20 AM
in response to: De Mena, Ron
|
|
On Tue 25 Apr 2006 at 09:44AM, De Mena, Ron wrote:
> Additionally putting another item into the zonecfg XML opens more
> opportunity for existing software that edits the XML files, against all
> warnings, to edit more of it.
We're already well down that road-- and we've provided good tools to
edit the zone configuration. Note that since this document is an
interface description, I didn't mention the XML file at all-- because it
is not an interface.
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
23
From:
US
Registered:
7/22/06
|
|
|
|
Re: Proposal: Zone Boot Arguments II
Posted:
Jul 22, 2006 2:06 PM
in response to: dp
|
|
Is there a timeframe when it will be possible to specify boot parameters in the zone configuration. I plan to use zones in a classroom environment and would like to script the process of destroying existing zones and recreating them at the end of every semester. The ability to specify boot parameters in the zone configuration would be a great help so I don't have to go through the initial boot sequence for each zone every semester.
Thanks
Manish
|
|
|
|
|
Matty
mattyml@prefetch.net
|
|
|
|
Re: Re: Proposal: Zone Boot Arguments II
Posted:
Jul 22, 2006 7:53 PM
in response to: magrawal
|
|
On Sat, 22 Jul 2006, Manish Agrawal wrote:
> Is there a timeframe when it will be possible to specify boot parameters in the
> zone configuration. I plan to use zones in a classroom environment and
> would like to script the process of destroying existing zones and
> recreating them at the end of every semester. The ability to specify
> boot parameters in the zone configuration would be a great help so I
> don't have to go through the initial boot sequence for each zone every
> semester.
Hi Manish,
It sounds like you might be interested in the zoneadm "clone" option.
This feature is currently in Solaris Express, and I am hopeful it will
make Solaris 10 update 3. Does anyone from Sun happen to know if the
"attach," "detach" and "clone" features could be released as a patch for
Solaris 10? These are super useful options, and it would be awesome to get
them in a supported version of Solaris prior to the next update.
Thanks,
- Ryan
--
UNIX Administrator
http://prefetch.net
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
470
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Proposal: Zone Boot Arguments II
Posted:
Jul 24, 2006 5:46 AM
in response to: Matty
|
|
Matty wrote:
> It sounds like you might be interested in the zoneadm "clone" option.
> This feature is currently in Solaris Express, and I am hopeful it will
> make Solaris 10 update 3. Does anyone from Sun happen to know if the
> "attach," "detach" and "clone" features could be released as a patch for
> Solaris 10? These are super useful options, and it would be awesome to
> get them in a supported version of Solaris prior to the next update.
These features will be delivered in the S10u3 release. I don't think they
will be available before the next update though, unless you use Solaris
express, where they are already available.
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
812
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Proposal: Zone Boot Arguments II
Posted:
Jul 23, 2006 1:25 AM
in response to: magrawal
|
|
On Sat 22 Jul 2006 at 02:06PM, Manish Agrawal wrote:
> Is there a timeframe when it will be possible to specify boot
> parameters in the zone configuration. I plan to use zones in a
> classroom environment and would like to script the process of
> destroying existing zones and recreating them at the end of every
> semester. The ability to specify boot parameters in the zone
> configuration would be a great help so I don't have to go through the
> initial boot sequence for each zone every semester.
I'm not sure why boot arguments solves your problem (see Matty's
response)-- you may be looking for sysidcfg support which is already
present, or clone, which would help you snap off many identical
zones.
Anyway, as for boot arguments, I checked in support for this feature
into build 44 of Solaris Nevada. The following are supported:
-s (single user)
-m <smf_options>
-i </path/t
All Solaris Express builds starting with B44 should have support
for setting the 'bootargs' property in the zonecfg:
zonecfg:myzone> set bootargs="-s"
Boot arguments may eventually appear in an update for Solaris 10
but I couldn't reasonably speculate as to which one (except not
the next one; that one is already "filled up" with features).
Thanks,
-dp
--
Daniel Price - Solaris Kernel Engineering - dp at eng dot sun dot com - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Matty
mattyml@prefetch.net
|
|
|
|
Re: Re: Proposal: Zone Boot Arguments II
Posted:
Jul 23, 2006 4:37 AM
in response to: dp
|
|
On Sun, 23 Jul 2006, Dan Price wrote:
> Boot arguments may eventually appear in an update for Solaris 10
> but I couldn't reasonably speculate as to which one (except not
> the next one; that one is already "filled up" with features).
Do you happen to know if the "clone," "attach" and "detach" options will
be part of update 3?
Thanks,
- Ryan
--
UNIX Administrator
http://prefetch.net
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
Posts:
202
From:
Singapore
Registered:
6/17/05
|
|
|
|
Re: Re: Proposal: Zone Boot Arguments II
Posted:
Jul 23, 2006 6:20 PM
in response to: magrawal
|
|
On 7/23/06, Manish Agrawal <magrawal at coba dot usf dot edu> wrote:
> Is there a timeframe when it will be possible to specify boot parameters in the zone configuration. I plan to use zones in a classroom environment and would like to script the process of destroying existing zones and recreating them at the end of every semester. The ability to specify boot parameters in the zone configuration would be a great help so I don't have to go through the initial boot sequence for each zone every semester.
Hi Manish,
If you need to duplicate zones quickly and escape the boot sequence (I
believe the SMF import stuff et.al), I'm not sure how much boot
parameters will help you.
Here's what we do now while waiting for zoneadm-clone that Matty
mentioned in S10.
1) Take a clean zone and sys-unconfig it.
2) Tar up an image of this zone's zonepath
3) zonecfg the new zone
4) Untar the image to the new zone's zonepath
5) Edit the file /etc/zones/index and set the new zone's status to "installed"
6) The new zone should boot straight into sysconfig
If you are using ZFS, Steps 2&4 are just a ZFS snapshot/clone with the
bonus of saving some disk space.
It's unlikely to be supported by Sun. I haven't had any problems yet though.
That said, zones has pampered us so much that we have reduced the
"re-provisioning" cycle from weeks (if it involves a purchase) to
minutes. And now, even 10 minutes seems too long.
--
Just me,
Wire ...
_______________________________________________
zones-discuss mailing list
zones-discuss at opensolaris dot org
|
|
|
|
|
