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
