Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Ethan Quach wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? Ethan, Following up with some of the other responses, I don't see how this helps you and I don't think of rpool/export/zones/z1/rpool as a shared area. Based on the design, that is only for the zone's BEs. Maybe you could explain why you think this is better. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Jerry Jelinek wrote: Ethan, Ethan Quach wrote: Jerry Jelinek wrote: Ethan Quach wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? Ethan, Following up with some of the other responses, I don't see how this helps you and I don't think of rpool/export/zones/z1/rpool as a shared area. Based on the design, that is only for the zone's BEs. If zonepath/rpool is delegated to the zone, then the zone admin can create anything they want in it, e.g. zonepath/rpool/export or zonepath/rpool/mystuff. And whatever they create is also seen and automatically mounted whenever any of that zone's BEs boots; hence its like a shared area between that zones BEs, just like rpool in the global zone. How is that different than if .../rpool/ROOT is delegated? They can still create stuff in there too. This is the same as what is done with /rpool/ROOT and ZFS boot, with ROOT being the confined area where we place BE's. An admin can still create things there but this is the only place that we look for BE's. Datasets outside this are not considered BE's but would be shared between BE's as is done in the global zone now. This was how I thought it was going to work. Are we limiting the zone to only be able to create zone BEs underneath zonepath/rpool and not use it for data somehow? There is no way to limit this, no matter what name we call it. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Jerry Jelinek wrote: Evan Layton wrote: This is the same as what is done with /rpool/ROOT and ZFS boot, with ROOT being the confined area where we place BE's. An admin can still create things there but this is the only place that we look for BE's. Datasets outside this are not considered BE's but would be shared between BE's as is done in the global zone now. Evan, We can certainly call this .../ROOT instead of .../rpool, if that makes a difference. The extra level is what makes the difference, not the name. -ethan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Jerry Jelinek wrote: Evan Layton wrote: This is the same as what is done with /rpool/ROOT and ZFS boot, with ROOT being the confined area where we place BE's. An admin can still create things there but this is the only place that we look for BE's. Datasets outside this are not considered BE's but would be shared between BE's as is done in the global zone now. Evan, We can certainly call this .../ROOT instead of .../rpool, if that makes a difference. Jerry I think what Ethan was getting at is if rpool/export/zones/z1/rpool is what's delegated then rpool/export/zones/z1/rpool/ROOT gives us a confined space to look for BE's in. Plus it gives a similar set of datasets for a BE as would be found in the global zone's BE's. For example we could define a BE rpool/export/zones/z1/rpool/ROOT/ZBE1 as the root of the zone BE and rpool/export/zones/z1/rpool/ROOT/ZBE1/opt for /opt in that zone BE rpool/export/zones/z1/rpool/ROOT/ZBE1/var for /var any thing outside that would be shared between zone BE's rpool/export/zones/z1/rpool/export -evan ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Ethan Quach wrote:
Ethan Quach wrote:
Jerry Jelinek wrote:
Evan Layton wrote:
This is the same as what is done with /rpool/ROOT and ZFS boot, with
ROOT being the confined area where we place BE's. An admin can still
create things there but this is the only place that we look for BE's.
Datasets outside this are not considered BE's but would be shared
between BE's as is done in the global zone now.
Evan,
We can certainly call this .../ROOT instead of .../rpool, if that
makes a difference.
The extra level is what makes the difference, not the name.
Jerry,
Let me try to clarify (if I wasn't clear), the extra level would be just an
organizational convenience, not something required for this to work.
Without ROOT, the zone BE root datasets would have zfs properties
and such to delineate them from random datasets that a zone admin could
have created under zonepath/rpool.
zonepath/rpool/ZBE1
zonepath/rpool/ZBE2
zonepath/rpool/foo
zonepath/rpool/foo/bar
zonepath/rpool/export
vs.
zonepath/rpool/ROOT/ZBE1
zonepath/rpool/ROOT/ZBE2
zonepath/rpool/foo
zonepath/rpool/foo/bar
zonepath/rpool/export
Yes, the zone admin could still create random datasets directly under the
ROOT because we have nothing stopping them to, but it's documented to
be a special dataset that they shouldn't play around with.
Ethan,
I wasn't evinsioning that the {zonepath}/rpool dataset was a general
purpose dataset to put stuff in. We already have other mechanisms for that.
In fact, rpool is a bad name, since it is not a pool. Calling this
{zonepath}/ROOT seems to be clearer.
Jerry
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Jerry Jelinek wrote:
Ethan Quach wrote:
Ethan Quach wrote:
Jerry Jelinek wrote:
Evan Layton wrote:
This is the same as what is done with /rpool/ROOT and ZFS boot, with
ROOT being the confined area where we place BE's. An admin can
still
create things there but this is the only place that we look for BE's.
Datasets outside this are not considered BE's but would be shared
between BE's as is done in the global zone now.
Evan,
We can certainly call this .../ROOT instead of .../rpool, if that
makes a difference.
The extra level is what makes the difference, not the name.
Jerry,
Let me try to clarify (if I wasn't clear), the extra level would be
just an
organizational convenience, not something required for this to work.
Without ROOT, the zone BE root datasets would have zfs properties
and such to delineate them from random datasets that a zone admin could
have created under zonepath/rpool.
zonepath/rpool/ZBE1
zonepath/rpool/ZBE2
zonepath/rpool/foo
zonepath/rpool/foo/bar
zonepath/rpool/export
vs.
zonepath/rpool/ROOT/ZBE1
zonepath/rpool/ROOT/ZBE2
zonepath/rpool/foo
zonepath/rpool/foo/bar
zonepath/rpool/export
Yes, the zone admin could still create random datasets directly under
the
ROOT because we have nothing stopping them to, but it's documented to
be a special dataset that they shouldn't play around with.
Ethan,
I wasn't evinsioning that the {zonepath}/rpool dataset was a general
purpose dataset to put stuff in. We already have other mechanisms for
that.
In fact, rpool is a bad name, since it is not a pool. Calling this
{zonepath}/ROOT seems to be clearer.
Jerry,
If its not for general purpose, then yes, I agree zonepath/ROOT is
more clear. (And I also agree about the rpool name)
Regarding a general purpose dataset, IMO we need to always automatically
give this branded zone one of those since we're giving it the ability to
manipulate its own BEs. With BEs, zone admins will inevitably want a
place to store data shared by all of their BEs instead of having everything
cloned.
thanks,
-ethan
___
zones-discuss mailing list
zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
On Wed, Aug 27, 2008 at 4:31 PM, Ethan Quach [EMAIL PROTECTED] wrote: Jerry, If its not for general purpose, then yes, I agree zonepath/ROOT is more clear. ?(And I also agree about the rpool name) Regarding a general purpose dataset, IMO we need to always automatically give this branded zone one of those since we're giving it the ability to manipulate its own BEs. ?With BEs, zone admins will inevitably want a place to store data shared by all of their BEs instead of having everything cloned. I'm with you here. It seems as though there should be a convention for a non-root dataset that is delegated to the zone. For instance zfs create -o mountpoint=none rpool/zones/z1/share zonecfg -z z1 add dataset name=rpool/zones/z1/share zoneadm -z z1 boot -s zlogin z1 zfs set mountpoint=/share rpool/zones/z1/data Again - some would immediately choose /export instead of /share. Unless you are using samba, there isn't much chance you will be exporting much from a zone so filesystem(5) says it is the wrong place. In this context, /share is indicating that it is shared between boot environments. This goes along the same lines as the /var/share idea that I've been pushing for a while. So as to not muddy the waters with the historical use of share (e.g. /usr/share) it may be appropriate to use common instead of share. I don't really care - so long is the name is indicative of current use and doesn't throw us into UNIX history lessons with new users. Scope creep ahead... On a somewhat related noted, delegated datasets seem to expose administrative decisions made in the global zone that the local zone administrator shouldn't care about. An alias mechanism to hide this detail seems to me to be a reasonable thing to do. # zonecfg -z z1 add dataset set name=pool67fromArraySN-SF23424HW23/acct7823/z1 set alias=share end commit exit # zfs set mountpoint=none pool67fromArraySN-SF23424HW23/acct7823/z1 # zoneadm boot z1 # zlogin z1 zfs set mountpoint=/share share # zlogin z1 zfs list NAME USED AVAIL REFER MOUNTPOINT share 18K 4.86G18K /share I'm done with scope creep now. :) -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Hey Jerry,
I just thought about something regarding the zones dataset
namespace. Instead of creating the dataset for zone roots at:
rpool/export/zones/z1/rpool/ZBE1
Maybe we should insert the roped off ROOT container dataset
like we do in the global zone:
rpool/export/zones/z1/rpool/ROOT/ZBE1
so that we confine the place where we know boot environment roots
live. The reason we do this is in the global zone is so that we
don't have to troll through potentially thousands of datasets
(sorting out whatever's been created in the shared area) to find
BE roots. This same problem would occur in the zone BE namespace.
Thoughts?
thanks,
ethan
Jerry Jelinek wrote:
The final design is attached.
Thanks,
Jerry
---
Zones/SNAP Design
8/25/2008
I. Overview
This specification describes how ZFS datasets will be used with zones for
supporting software management operations with ipkg branded zones on
OpenSolaris. Software management includes tasks such as a SNAP upgrade or
installing/removing pkgs.
Issues are summarized in Part III.
One goal is that sw management behavior within the zone should be as similar
as possible to the behavior in the global zone. That is, when the zone admin
does sw management, the tools running within the zone should be able to take a
snapshot of the zone root, clone it, and the zone admin should be able to
roll-back if the sw installation was problematic. This implies that the zone
root itself must be a delegated dataset. Up to now, zones does not support
this, so we must extend zones to provide this capability.
(Note that these software management features within a zone are not a
requirement for the 2008.11 release, however, this proposal lays the
groundwork to enable that capability moving forward.)
There are some issues with delegating the zone root dataset to the zone. The
way zones work, it is fundamental that the zone root be mounted in the global
zone so that the system can set up the chrooted environment when the zone
boots or when a process enters the zone. However, the ZFS mountpoint property
cannot be interpreted from the global zone when a dataset is delegated,
since this could lead to security problems.
(Note that the zone root is {zonepath}/root as seen in the global zone}
To address this, the zones code must be enhanced to explicitly manage the zone
root mounts. This naturally falls out of the basic design described here.
There were two alternative proposal considered; a two-level zone layout and a
single-level zone layout. After much discussion, the single-level approach
was chosen. The two-level approach is not described further here.
II. Description
To support the management of boot environments (BEs) for zones within both the
global zone context as well as the non-global zone context, a nested,
two-level, BE dataset naming scheme is used so that there is a top-level
global zone BE namespace, as well as a zone-level BE namespace for the zone's
own use. Properties on the zone's datasets are used to manage which dataset
is active and which datasets are associated with a specific global zone BE.
There are two properties on a zone's datasets that are used to manage the
datasets; org.opensolaris.libbe:parentbe and org.opensolaris.libbe:active.
The org.opensolaris.libbe:parentbe property is set to the UUID of the global
zone BE that is active when the non-global zone BE is created. The
org.opensolaris.libbe:active property is set to on or off to indicate
that the dataset is the one that should be mounted.
We leave the org.opensolaris.libbe:active property set to on to
correspond with older, inactive global zone BEs, and use the combination of
this property, along with the matching org.opensolaris.libbe:parentbe to
determine which dataset to mount on the zone root. Thus, rolling back to an
earlier global zone BE would cause the last active zone BE to be mounted for
that global zone BE.
When a global zone BE is deleted, all corresponding zone-specific BEs with the
matching org.opensolaris.libbe:parentbe property should also be deleted.
When a non-global zone is deleted, all of zone-specific BEs with the
matching org.opensolaris.libbe:parentbe property for the current global zone
BE UUID should be deleted, however, any zone-specific BEs for other
global zone BEs must be preserved.
The following example illustrates the dataset layout and management for zone
z1 while the global zone is running BE1. The zones code must be enhanced to
automatically create these datasets when the zone is installed.
(For clarity, the global zone GBE string is used instead of the global zone
BE UUID in the following examples. Likewise, the ZBE string is used to for
the non-global zone BE name.)
The zone has zonepath: /export/zones/z1
The relevant dataset that exists before the zone is installed:
dataset mountpoint prop.
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
On Tue, Aug 26, 2008 at 5:07 PM, Ethan Quach [EMAIL PROTECTED] wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? rpool/ROOT seems to be redundant and it repeats itself. :) In the global zone, rpool/ROOT makes sense because there needs rpool and ROOT perform different duties. In a non-global zone, rpool/export/zones/z1 is equivalent to the global zone's rpool. To maximize synergies (and end abuse of /export - see filesystem(5)), I suggest: This is the equivalent of the global zone's rpool. Or in an environment where there is a pool per zone, it may be z1pool. rpool/zones/z1 This is managed by zoneadm and beadm. If all goes well, they both use libzonecfg to minimize the chance of divergence. rpool/zones/z1/ROOT rpool/zones/z1/ROOT/be1 rpool/zones/z1/ROOT/be2 The rest are available for use within the zone and may be mounted other places rpool/zones/z1/* -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Absolutely. +1 to Mike. http://blogs.sun.com/mrbill/entry/separation_is_a_good_thing And from the SVM world: http://blogs.sun.com/mrbill/entry/in_the_zone_with_jet bill. Mike Gerdts wrote: On Tue, Aug 26, 2008 at 5:07 PM, Ethan Quach [EMAIL PROTECTED] wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? rpool/ROOT seems to be redundant and it repeats itself. :) In the global zone, rpool/ROOT makes sense because there needs rpool and ROOT perform different duties. In a non-global zone, rpool/export/zones/z1 is equivalent to the global zone's rpool. To maximize synergies (and end abuse of /export - see filesystem(5)), I suggest: This is the equivalent of the global zone's rpool. Or in an environment where there is a pool per zone, it may be z1pool. rpool/zones/z1 This is managed by zoneadm and beadm. If all goes well, they both use libzonecfg to minimize the chance of divergence. rpool/zones/z1/ROOT rpool/zones/z1/ROOT/be1 rpool/zones/z1/ROOT/be2 The rest are available for use within the zone and may be mounted other places rpool/zones/z1/* ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
Mike Gerdts wrote: On Tue, Aug 26, 2008 at 5:07 PM, Ethan Quach [EMAIL PROTECTED] wrote: Hey Jerry, I just thought about something regarding the zones dataset namespace. Instead of creating the dataset for zone roots at: rpool/export/zones/z1/rpool/ZBE1 Maybe we should insert the roped off ROOT container dataset like we do in the global zone: rpool/export/zones/z1/rpool/ROOT/ZBE1 so that we confine the place where we know boot environment roots live. The reason we do this is in the global zone is so that we don't have to troll through potentially thousands of datasets (sorting out whatever's been created in the shared area) to find BE roots. This same problem would occur in the zone BE namespace. Thoughts? rpool/ROOT seems to be redundant and it repeats itself. :) In the global zone, rpool/ROOT makes sense because there needs rpool and ROOT perform different duties. In a non-global zone, rpool/export/zones/z1 is equivalent to the global zone's rpool. To maximize synergies (and end abuse of /export - see filesystem(5)), I suggest: Sure, that's fine. That part isn't really relevant from what I was trying to convey though. This is the equivalent of the global zone's rpool. Or in an environment where there is a pool per zone, it may be z1pool. rpool/zones/z1 This is managed by zoneadm and beadm. If all goes well, they both use libzonecfg to minimize the chance of divergence. rpool/zones/z1/ROOT rpool/zones/z1/ROOT/be1 rpool/zones/z1/ROOT/be2 The rest are available for use within the zone and may be mounted other places rpool/zones/z1/* rpool/zones/z1 is the zonepath, and I don't know if we're planning on delegating that dataset to the zone (for zone reasons I suppose). Based on Jerry's proposal, the zonepath is not delegated. Hence the need for: rpool/zones/z1/pool/ROOT/ZBE1 The pool level is delegated, and that was what I was thinking the zone can use as its free-range area. thanks, -ethan ___ zones-discuss mailing list zones-discuss@opensolaris.org
