Hello Ian,

Thanks four your answer, more below.

On Nov 3, 2010, at 12:06 AM, Ian Collins wrote:

> On 11/ 3/10 11:56 AM, Henrik Johansson wrote:
>> I would ideally like to do two things:
>> 1. Have all filesystem configuration for the zone in the pool as we have 
>> with the global zone, only specify the pool(s) for the zone and all 
>> filesystems would be mounted inside the zone, this without giving away all 
>> control to the local zone.
> Why don't you want the zones to be able to manage their own filesystems?  One 
> of the main reasons for "zoned" filesystems is to allow filesystems to have 
> mount points relative to the zone's root filesystem.

It would depend on what kind of users we have in the zone and how the zone is 
used, for some it would be fine to give away all control for other we would 
like to keep them from deleting snapshots/datasets or changing properties like 
quota. If the zones is compromised or if a privileged users does something 
nasty we would like to be able to rollback it from the global zone only. 

We would like the administrative gains of having all "filesystem" configuration 
inside the pool but for some customers we handle their data needs even if they 
have privileged equal to root inside the zone so we would like to restrict what 
they can do.

Changing properties for the zone could also affect the global zone and other 
zones on the same global zone, lets say you would enable gzip-9 compression and 
write lots of data, that would bypass all resource limits for the zone and 
drastically change the amount of cycles required for zones datasets . Even 
worse for zones in Solaris.Next you could enable deduplication which could eat 
the metadata part of the ARC. This would decrease the amount of  separation 
provided by zones with resource management.


zones-discuss mailing list

Reply via email to