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 /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.
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 /rpool.
>>
>>/rpool/ZBE1
>>/rpool/ZBE2
>>/rpool/foo
>>/rpool/foo/bar
>>/rpool/export
>>
>> vs.
>>
>>/rpool/ROOT/ZBE1
>>/rpool/ROOT/ZBE2
>>/rpool/foo
>>/rpool/foo/bar
>>/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 /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.
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 /rpool.
>
>/rpool/ZBE1
>/rpool/ZBE2
>/rpool/foo
>/rpool/foo/bar
>/rpool/export
>
> vs.
>
>/rpool/ROOT/ZBE1
>/rpool/ROOT/ZBE2
>/rpool/foo
>/rpool/foo/bar
>/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] Memory allocation for non-global zones
On Wed, Aug 27, 2008 at 1:20 PM, Patrick Ho <[EMAIL PROTECTED]> wrote: > Can a non-global zone utilize all the available memory on the system if > resource management is not used and rcap is not used? A non-global zone could use up most of the free physical memory on the system. If that happened, Solaris would begin paging physical memory pages out to the swap disk(s) to ensure that there is free physical memory. If this continues, maybe the swap disk will fill up, and then more requests for memory will fail. Or maybe performance will become very bad because the system is paging all the time. That's why the global zone administrator can set a physical memory cap on a non-global zone using the resource management controls. --JeffV ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
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 /rpool. /rpool/ZBE1 /rpool/ZBE2 /rpool/foo /rpool/foo/bar /rpool/export vs. /rpool/ROOT/ZBE1 /rpool/ROOT/ZBE2 /rpool/foo /rpool/foo/bar /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. thanks, -ethan > > -ethan > > ___ > 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. > > 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
[zones-discuss] Memory allocation for non-global zones
Can a non-global zone utilize all the available memory on the system if resource management is not used and rcap is not used? Thanks, Patrick ___ 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.
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 ___ 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 /rpool is delegated to the zone, then the zone admin can >> create anything they want in it, e.g. /rpool/export or >> /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 /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.
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 /rpool is delegated to the zone, then the zone admin can > create anything they want in it, e.g. /rpool/export or > /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 was how I thought it was going to work. Are we limiting the > zone to only be able to create zone BEs underneath /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
Re: [zones-discuss] [caiman-discuss] SNAP zones layout proposal.
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 /rpool is delegated to the zone, then the zone admin can create anything they want in it, e.g. /rpool/export or /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. This was how I thought it was going to work. Are we limiting the zone to only be able to create zone BEs underneath /rpool and not use it for data somehow? -ethan > > 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.
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] zones/SNAP design
Darren J Moffat wrote: > Jerry Jelinek wrote: >> Currently, with user defined properties, the values can be changed >> inside the zone. The proposal actually depends on this feature. >> It sounds like you might need to talk to the zfs team about some >> enhancements here so we can have properties that cannot be changed >> on delegated datasets. That might be generally useful beyond tx, so >> that would be a good conversation to have. > > The label should not be done as a userproperty but a "real" property. > Doing that means that we should be able to control wither or not it is > delegated to a zone or not. I'll see if I can whip up a quick > prototype of this part - I've got a good amount of experience with ZFS > properties from the ZFS crypto project. Darren, Yes, a real property gives you this control. I agree that for this problem, its a better soution. Thanks, Jerry ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zones/SNAP design
Jerry Jelinek wrote: > Currently, with user defined properties, the values can be changed > inside the zone. The proposal actually depends on this feature. > It sounds like you might need to talk to the zfs team about some > enhancements here so we can have properties that cannot be changed > on delegated datasets. That might be generally useful beyond tx, so > that would be a good conversation to have. The label should not be done as a userproperty but a "real" property. Doing that means that we should be able to control wither or not it is delegated to a zone or not. I'll see if I can whip up a quick prototype of this part - I've got a good amount of experience with ZFS properties from the ZFS crypto project. -- Darren J Moffat ___ zones-discuss mailing list zones-discuss@opensolaris.org
