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 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.


zones-discuss mailing list

Reply via email to