Re: [zones-discuss] zoneadm wants more ZFS when only ZFS exists
On 7/02/11 08:22 AM, Mike Gerdts wrote: ... If I was in the habit of upgrading, creating new BEs, validating those BEs, then deleting the old ones, why wouldn't the same apply to zones and thus result in mitigation of the problem you cite above? If the old global zone BEs and associated snapshots are deleted, there's probably not a big problem. However, the code paths for creating the zone BEs during beadm create and similar operations becomes more complicated having to deal with more scenarios. More complicated for the sake of flexibility that has no material benefit means that developers spend less time working on things that are of material benefit. Is there a reason that zfs create -o mountpoint=/zones rpool/zones then creating each zonepath as /zones/zonename is a problem? From the perspective of a developer that uses a test suite that creates zones using a shell script, the less changes required to my script the better. I suspect that ultimately the above will become part of the system installation configuration, but it would be nice if the zones tools kept the difference in requirements for disk configuration internal? Thus the same commands just work when building zones on Solaris10 11. I suppose in my case, it is rpool/zone and mountpoint=/zone. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] zoneadm wants more ZFS when only ZFS exists
On a test system that is using only ZFS, I'm trying to create a zone but it keeps failing with: netvirt-d1 ~# zoneadm -z exclusivetestzone1 install ERROR: the zonepath must be a ZFS dataset. The parent directory of the zonepath must be a ZFS dataset so that the zonepath ZFS dataset can be created properly. I don't get it. This restriction never used to exist. Why do I need to do something extra that is mandatory? Further to this, there's a script on Oracle's website here: http://download.oracle.com/docs/cd/E19963-01/821-1460/z.conf.start-1/index.html that also fails to configure create a zone that can be installed with b154 bits. To give an example (/tmp/ozone is the script from the above page)... / is rpool/ROOT/solaris # zfs create rpool/ROOT/solaris/zone # zfs set mountpoint=/zone rpool/ROOT/solaris/zone # /tmp/ozone 1 exclusivetestzone /zone configuring exclusivetestzone1 installing exclusivetestzone1 setting up sysid for exclusivetestzone1 /tmp/ozone[74]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] /tmp/ozone[75]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] /tmp/ozone[76]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] /tmp/ozone[77]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] /tmp/ozone[78]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] /tmp/ozone[79]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] /tmp/ozone[80]: /zone/exclusivetestzone1/root/etc/sysidcfg: cannot create [No such file or directory] Fri Feb 4 14:20:11 PST 2011 booting exclusivetestzone1 zoneadm: zone 'exclusivetestzone1': must be installed before boot. # zoneadm -z exclusivetestzone1 uninstall Are you sure you want to uninstall zone exclusivetestzone1 (y/[n])? y # zoneadm -z exclusivetestzone1 install ERROR: the zonepath must be a ZFS dataset. The parent directory of the zonepath must be a ZFS dataset so that the zonepath ZFS dataset can be created properly. # cat /zone/exclusivetestzone1.config create set zonepath=/zone/exclusivetestzone1 As you can see from this, the parent of the zonepath is /zone and that is a freshly created ZFS dataset. Furthermore, / which is the parent of /zone is also a ZFS dataset. Having /zone as a directory within / and not a dataset also results in the above error. Between zoneadm and zonecfg, I can't see anything that instructs me on how to resolve this. Am I missing something? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zoneadm wants more ZFS when only ZFS exists
So it would seem this is related to at 7010744 which implies 6726123 needs to be fixed. It could also be a manifestation of 7010102 (if the submitter means slashes and not spaces.) Can someone else confirm that? Or is the problem I've observed different again? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [networking-discuss] FW: using load balancers with zones]
On 11/10/08 13:56, Steve Lawrence wrote: ... I am sure there must be a way to tell ipf to force packets from the be- net to the fe-net to go out on the wire, presumably using dup-to but I was unable to make it work, so I am using source-nat at the moment. I look forward to hearing that someone else has already figured this out and here is how they did it, but for now I need to work on installing software on mail-fe-1 because it was supposed to be working last Tuesday ;) I think the best answer to your question is to download the latest snapshot of a crossbow build and use that. What you need is local (on the zones box) switching that recognises packets don't need to leave the host to find the destination. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
James Carlson wrote: Darren Reed writes: 2) it would seem the next place worth going is: zoneadm subcommand [all options] 3) but what I'd rather do is: zoneadm subcommand zonename [all-options-except -z] You might want to review the CLIP specification and companion, as the above goal seems to be out of step -- options are supposed to go before the operand, not trailing after: http://opensolaris.org/os/community/arc/caselog/2006/062/spec-clip-html/ I'm not really a fan of CLIP, but I am a fan of consistency. To the degree we can manage it, we shouldn't have individual utilities striking out to explore new command line syntax territory. CLIP delivered us inetadm, zoneadm and svcadm all new in Solaris 10. Given the disparity between these three new commands, I'm going to declare CLIP a failure and that we should just ignore it. I'm still really unclear on what problem we're solving. Is it just that zlogin has a command line that behaves like rlogin (needing no option to select host), and that zoneadm/zonecfg use an option to specify the same thing. The problem is the lack of consistency between *adm commands. inetadm should probably be whacked as well - if we care about it enough. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Jordan Brown wrote: Darren Reed wrote: Hmmm, I think I prefer the bottom one, but I can't see why either precludes the other as I'm pretty confident no sane person will ever want a zone name that matches a uuid and code could easily be written to cover this. Are zones required to have names? Unless zonecfg has a magic option to not need them, yes. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
Joerg Barfurth wrote: Nicolas Williams schrieb: On Thu, Jun 19, 2008 at 09:36:15AM +0200, Joerg Barfurth wrote: Take all the unstated (in the original post) syntax changes into account, I agree that it seems possible to have a (CLIP compliant) syntax of the form zoneadm subcommand [all-options] [zonename [operands]] and that this is more usable than the current zoneadm [global-opts] subcommand [subcmd-opts] [operands] Given that the global-opts and subcmd-opts today don't conflict, why not just: zoneadm subcommand [all-options] where the zone on which a sub-command must operate is named with -z/-u as usual, just after the sub-command name? Still there are some details in the required options and operands (like use of -u instead of -z or the reboot boot-options arguments) that make it tricky to do this cleanly - particularly if the old syntax needs to be kept alive for compatibility. The old syntax must remain, yes, for backwards compat. But I don't see why this is complicated. If argv[1] doesn't start with - then you do the new thing and use a getopts string with all the options for that sub-command and all the global ones too. Otherwise do as today. That surely is a much easier change - and easy to do compatibly, if you allow global options both before and after the subcommand. But Darren apparently much prefers not having to use an 'extraneous' option letter to designate the main object of the command (which is the zone). It is the attempt to morph this from option argument to operand that makes this complicated. First, as has been mentioned elsewhere, various other *adm commands do not require a option identifier (-*) before the key, which in this case is predicted to come after the subcommand. Where I started from was: 1) if neither argv[1] nor argv[2] start with '-' then it is: zoneadm subcommand zonename [sub-options] 2) it would seem the next place worth going is: zoneadm subcommand [all options] 3) but what I'd rather do is: zoneadm subcommand zonename [all-options-except -z] ...but just maybe that requires (2) to allow for -u. The other thing to say is that any string that is going to be successfully parsed by linuuid(3) is not going to be a normal zonename, therefore no -u is required for zonename to indicate that it is a uuid instead - the string can be passed to libuuid(3) and if it works, we move along. The only problem that poses if someone was expecting zoneadm blah uuid to fail on purpose - but I'd wager that more people would like it to just work than fail. Actually the only thing that is substantially different is that I haven't supported the global-opts on the right hand side. But the only global option of significance is -R, so that isn't an insurmountable problem. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Making zoneadm more like the other adms...
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] Making zoneadm more like the other adms...
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]
mailto:[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 zone\t\t\t(%s)\n,
execname, gettext(interactive));
+ (void) fprintf(fp, \t%s command zone\n,
execname);
(void) fprintf(fp, \t%s -z zone command\n,
execname);
(void) fprintf(fp, \t%s -z zone -f
command-file\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) {
case '?':
--- 6654,6679
return (execbasename);
}
! static void
! set_zonename(char *zonename)
{
! if (strcmp(zonename, GLOBAL_ZONENAME) == 0) {
! global_zone = B_TRUE;
! } else if (zonecfg_validate_zonename(zonename) != Z_OK) {
! zone_perror(zonename, Z_BOGUS_ZONE_NAME, B_TRUE);
! usage(B_FALSE, HELP_SYNTAX);
exit(Z_USAGE);
}
! (void) strlcpy(zone, zonename, sizeof (zone));
! (void) strlcpy(revert_zone, zonename, sizeof (zone));
! }
+ static void
+ get_clioptions(int argc, char *argv[])
+ {
+ struct stat st;
+ int arg;
+
while ((arg = getopt(argc, argv, ?f:R:z:)) != EOF) {
switch (arg) {
case '?':
***
*** 6712,6726
zonecfg_set_root(optarg);
break;
case 'z':
! if (strcmp(optarg, GLOBAL_ZONENAME) == 0) {
! global_zone = B_TRUE;
! } else if
(zonecfg_validate_zonename(optarg) != Z_OK) {
! zone_perror(optarg,
Z_BOGUS_ZONE_NAME, B_TRUE);
! usage(B_FALSE, HELP_SYNTAX);
! exit(Z_USAGE);
! }
! (void) strlcpy(zone, optarg, sizeof (zone));
! (void) strlcpy(revert_zone, optarg, sizeof
(zone));
break;
default:
usage(B_FALSE, HELP_USAGE);
--- 6702,6708
zonecfg_set_root(optarg);
break;
case 'z':
! set_zonename(optarg);
break;
default:
usage(B_FALSE, HELP_USAGE);
***
*** 6727,6733
--- 6709,6761
exit(Z_USAGE);
}
}
+ }
+ int
[zones-discuss] Making zoneadm more like the other adms...
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
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.)
Feedback welcome.
Darren
p.s. no, there isn't an RFE for this yet...and I didn't see one
when I looked during the week...
--- usr/src/cmd/zoneadm/zoneadm.c ---
Index: usr/src/cmd/zoneadm/zoneadm.c
*** /biscuit/onnv/usr/src/cmd/zoneadm/zoneadm.c Thu May 29 12:48:36 2008
--- /biscuit/onnv_20080608/usr/src/cmd/zoneadm/zoneadm.cSun Jun 8
17:49:37 2008
***
*** 24,30
* Use is subject to license terms.
*/
! #pragma ident @(#)zoneadm.c 1.6508/05/08 SMI
/*
* zoneadm is a command interpreter for zone administration. It is all in
--- 24,30
* Use is subject to license terms.
*/
! #pragma ident @(#)zoneadm.c 1.6608/06/08 SMI
/*
* zoneadm is a command interpreter for zone administration. It is all in
***
*** 345,350
--- 345,352
execname);
(void) fprintf(fd, \t%s {-z zone|-u uuid-match} %s\n, execname,
gettext(subcommand));
+ (void) fprintf(fd, \t%s %s zone\n, execname,
+ gettext(subcommand));
(void) fprintf(fd, \n%s:\n\n, gettext(Subcommands));
for (i = CMD_MIN; i = CMD_MAX; i++) {
if (cmdtab[i].short_usage == NULL)
***
*** 5944,5955
return (execbasename);
}
int
main(int argc, char **argv)
{
int arg;
zoneid_t zid;
- struct stat st;
char *zone_lock_env;
int err;
--- 5946,5972
return (execbasename);
}
+ static void
+ setroot(char *arg)
+ {
+ struct stat st;
+
+ if (*optarg != '/') {
+ zerror(gettext(root path must be absolute.));
+ exit(Z_ERR);
+ }
+ if (stat(optarg, st) == -1 || !S_ISDIR(st.st_mode)) {
+ zerror(gettext(root path must be a directory.));
+ exit(Z_ERR);
+ }
+ zonecfg_set_root(optarg);
+ }
+
int
main(int argc, char **argv)
{
int arg;
zoneid_t zid;
char *zone_lock_env;
int err;
***
*** 5968,6003
if (init_zfs() != Z_OK)
exit(Z_ERR);
! while ((arg = getopt(argc, argv, ?u:z:R:)) != EOF) {
! switch (arg) {
! case '?':
! return (usage(B_TRUE));
! case 'u':
! target_uuid = optarg;
! break;
! case 'z':
! target_zone = optarg;
! break;
! case 'R': /* private option for admin/install use */
! if (*optarg != '/') {
! zerror(gettext(root path must be absolute.));
! exit(Z_ERR);
}
- if (stat(optarg, st) == -1 || !S_ISDIR(st.st_mode)) {
- zerror(
- gettext(root path must be a directory.));
- exit(Z_ERR);
- }
- zonecfg_set_root(optarg);
- break;
- default:
- return (usage(B_FALSE));
}
}
- if (optind = argc)
- return (usage(B_FALSE));
-
if (target_uuid != NULL *target_uuid != '\0') {
uuid_t uuid;
static char newtarget[ZONENAME_MAX];
--- 5985,6026
if (init_zfs() != Z_OK)
exit(Z_ERR);
! if (argc = 3 *argv[1] != '-' *argv[2] != '-') {
! /*
!* The syntax being looked for is:
!* zoneadm boot zonename
!* but the application expects it to be:
!* zoneadm -z zonename boot
!* so we swap boot/zonename around, swallow the first arg
!* as being the zonename and prepare to continue by bumping
!* optind up to point at the command arg.
!*/
! target_zone = argv[2];
! argv[2] = argv[1];
! optind++;
! } else {
! while ((arg = getopt(argc, argv, ?u:z:R:)) != EOF) {
! switch (arg) {
! case '?':
! return (usage(B_TRUE));
! case 'u':
! target_uuid = optarg;
!
[zones-discuss] RFC on introducing getzoneidbyname(9f)....
Looking in usr/src/uts/common/os/zone.c, there are is a number of functions that have the words Public interface before them, such as: /* * Public function to retrieve the zone status. The zone status may * change after it is retrieved. */ zone_status_t zone_status_get(zone_t *zone) ... However doing a man zone_status_get returns nothing, so it would appear that it isn't completely public. In light of there being a relative lack of public functions in the kernel to deal with zone names and id's, I'd like to propose providing an implementation of getzoneidbyname() and getzonenamebyid() for the kernel that mirrors the behaviour of those found in libc today. So to summarise, I'd like to provide getzoneidbyname(9f) and getzonenamebyid(9f) that have the same interface as getzoneidbyname(3c) and getzonenamebyid(3c). Comments? Darren This message posted from opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] RFC on introducing getzoneidbyname(9f)....
Looking in usr/src/uts/common/os/zone.c, there are is a number of functions that have the words Public interface before them, such as: /* * Public function to retrieve the zone status. The zone status may * change after it is retrieved. */ zone_status_t zone_status_get(zone_t *zone) ... However doing a man zone_status_get returns nothing, so it would appear that it isn't completely public. In light of there being a relative lack of public functions in the kernel to deal with zone names and id's, I'd like to propose providing an implementation of getzoneidbyname() and getzonenamebyid() for the kernel that mirrors the behaviour of those found in libc today. So to summarise, I'd like to provide getzoneidbyname(9f) and getzonenamebyid(9f) that have the same interface as getzoneidbyname(3c) and getzonenamebyid(3c). Comments? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] ALL_ZONES and other magic names.
In reviewing the current interfaces made available from zones, it appears that ALL_ZONES and GLOBAL_ZONE are still private interfaces - correct? If so, if I'm forced to expose the existance of zones through an API to kernel consumers and then somehow map zone names into zoneid_t's. While userspace has a getzoneidbyname(), there appears to be no equivalent in the kernel - using zone_find_by_name() appears to be the only way. Is that a project private interface or a consolidation private interface? It would appear that the current state of the zones interfaces requires cooperation between a program in user space that maps a zone name to a zoneid_t and then passes the zoneid_t into the kernel, correct? But doing this begats the original problem - there would seem to be no correct way of specifying all zones in the zoneid_t if ALL_ZONES is also private. What I'd like to do is offer an API to consumers in which they can specify a zone by virtue of its name and resolve that internally inside the kernel. In such a design, I might choose to make a NULL name a wildcard, whilst allowing the API to also be specific to the global zone or other local zones. Thus I'd prefer to avoid exposing zoneid_t's to the consumers completely, if I can. Comments? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Using all as a name for a zone
Is anything bad likely to happen if someone chooses the name all for their zone? With respect to the definition of ALL_ZONES to be -1 in sys/zone.h, are there any thoughts about reserving a name to match that (such as all), similar to how global is used/reserved? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
[zones-discuss] Re: Restart: PSARC/2006/598 Swap resource control; locked memory RM improvements
Steve Lawrence wrote:
On Sat, Nov 11, 2006 at 09:02:48PM -0800, Gary Winiger wrote:
First off, sorry for the stutter in the spec update mail.
The project team didn't supply a summary of the changes, so I'll be
asking for one in a follow on.
I've addressed your comments way below. Here is my change summary and case
discussion summary:
SUMMARY OF CHANGES
1. Change to the proposed uncommitted kstat names and statistics.
From the form:
zone:{zoneid}:vm
with statistics:
zonename
swap_reserved
max_swap_reserved
locked_memory
max_locked_memory
To the form:
caps:{zoneid}:swaprsev_zone_{zoneid}
caps:{zoneid}:lockedmem_zone_{zoneid}
caps:{zoneid}:lockedmem_project_{projid}
with statistics:
zonename
usage
value
This sets up a generic scheme for adding kstats to project and
zone rctls. A kstat is created per rctl, instead of per zone.
2. Addition of zonecfg(1m) minimums for setting zone.max-swap.
When setting zone.max-swap via zonecfg(1m), a minimum value will be
enforced:
global zone: 100M
non-global zone: 50M
Currently, this is about 20M more than is needed to boot after a
default installation.
3. Addition of zonecfg(1m) warnings when setting zone.max-swap and
zone.max-lwps on the global zone.
global:capped-memory set swap=200M
Warning: Setting capped swap on the global zone can impact
system availability.
SUMMARY OF CASE DISCUSSION:
The case disussion has focused on the problem that the zone.max-swap
rctl on the global zone can affect system availability. An identical
problem exists today with task/project/zone.max-lwps.
Solutions to this problem may involve one or more of:
- Exempting project 0 in the global zone from zone.* rctls.
- Preventing task/project.* rctls from being set on project 0
in the global zone.
- Modifying root's default project.
- Adding a new privilege to exempt a process from rctls.
- Updating system service manifests to drop the new privilege.
Solving this problem in a way that will prevent the global zone (on a
default system) from becoming unavailable due to a resource control setting
will require a signficant change to the system. I believe solving this
problem is outside the scope of the zone.max-swap case, and would be better
solved by another case which is not seeking patch binding.
To minimize this problem for zone.max-swap (and zone.max-lwps), I've instead
proposed zonecfg enhacements to assist the admin in configuring these rctls
safely.
1. This case proposes adding the following resource control:
INTERFACE COMMITMENT BINDING
zone.max-swapCommittedPatch
This control will limit the swap reserved by processes and tmpfs
mounts within the global zone and non-global zones. This resource
control serves to address the referenced RFE[6].
There was some considerable discussion on the global zone aspect
of this part of the proposal. Perhaps I missed in the spec how
the new proposal mitigates the risk of the global zone not being
able to administer the system.
DETAIL:
1. zone.max-swap resource control.
Limits swap consumed by user process address space mappings and
tmpfs mounts within a zone.
While a low zone.max-swap setting for the global zone can lead to
a difficult-to-administer global zone, the same problem exists
today when configuring the zone.max-lwps resource control on the
global zone, or when all system swap is reserved. The zonecfg(1m)
enhancements detailed below will help administrators configure
zone.max-swap safely.
Perhaps I misunderstood the interaction between project 0
and zone.max-lwps in the global zone. If a max-lwps is set
is project 0 bound by it?
Currently yes. zone.* rctls bound all processes in the global zone, regardless
of project. This is the issue that my other proposal is attempting to
address.
Perhaps a short summary of the offline discussion on project 0
and the project teams feeling that the discussions conclusions
might not be patch qualified. I realize the need for this project
to have a patch binding.
I've added this summary above.
2. swap and locked properties for zonecfg(1m) capped_memory
resource.
To prevent administrators from configuring a low swap limit that
will prevent a system from booting, zonecfg will not allow a
swap limit to be configured to less than:
Global zone: 100M
Non-global zone: 50M.
These numbers are based on the swap needed to boota zone after a
Re: [zones-discuss] Re: [networking-discuss] Re:[crossbow-discuss]Design review of IP Instances part of Crossbow
From: James Carlson [EMAIL PROTECTED] Erik Nordmark writes: It depends on the administrator's mental model for the system. Agreed. My point is that the model for an exclusive-IP zone is different in important aspects than the shared-IP zones. And in other important aspects it's the same: it's still a single shared kernel and a single set of hardware resources. For that reason, I don't believe it's entirely wrong for users to want to be able to answer questions such as what addresses are being used by this node? ... Anyway, as I said at the beginning, I think making ifconfig work this way would be very hard to do, and likely would not work well. Though users often think of ifconfig as the sole way to interact with networking interfaces (because that's the way it works everywhere but Solaris), I don't think that's reasonably doable here, even if it's something that might be wanted. So how would you propose a system administrator, in the global zone, bring together all of the network addresses configured for his machine? Does this now require zlogin and a loop through all of the zones that are currently booted? Will this be too hard for those that want to do it? Thinking on this, would it be nice if there was some special command line switch for the likes of netstat/ifconfig and others that caused them to iterate through all of the present stack instances and report on them? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss]Design review of IP Instances part of Crossbow
- Original Message - From: Erik Nordmark [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Could ifconfig be modified to report all network interfaces that are assigned to a zone? I assume you mean in the global zone; ifconfig -a inside a zone (global or not) does report all the network interfaces that are configured. Yes I do, and more specifically, I was referring to the shared stack model, not the exclusive stack model. I can't see any reason why or for ifconfig, in the global zone, should report on interfaces that belong to other zones where they are using the exclusive zone model. Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Re: [networking-discuss] Re: [crossbow-discuss] Design review of IP Instances part of Crossbow
Erik Nordmark wrote: Dan Price wrote: 'list -i' religiously follows this idiosyncratic approach ;-) We have a plan to add 'zoneadm info' or some such to display all the runtime attributes of running zones. Hopefully we'll get to that in the next 12 months or so. I'd request that you hold off on adding list -l until we design 'info'. The problem is that we have requests from the users of IP Instances (folks that have used the bits on opensolaris.org) to have a way of displaying which datalink names are assigned to which running zones. Could ifconfig be modified to report all network interfaces that are assigned to a zone? There is also another tool I hacked up earlier in the year called ifgrep that you could do ifgrep -z global or whatever with... Is it worth doing something more worthwhile with that? Darren ___ zones-discuss mailing list zones-discuss@opensolaris.org
