On 11/ 3/10 02:21 PM, Henrik Johansson wrote:
On Nov 3, 2010, at 1:22 AM, Ian Collins wrote:
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.
I guess you can solve those two by setting the quota on the
filesystem containing the zoned filesystem and replicating snapshots.
I guess replication would solve the problem but with lots of overhead.
What? no backups!
The quota problem should work if we dedicated a dataset below the pool
itself to the zone as it's "root dataset". But for some zones we would
really like to limit all zfs operations such as rename, destroy and
create. The solution to this would be to make sure there are no users
inside the zone with such privileges, as long as the zone is not
compromised it would be fine.
The only option there would be to deny root access to the zone's users.
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.
I can see those being a problem if the cycles consumed by compression
are not assigned to the zone (I'm not sure if they are or not),
otherwise a zone cpu-cap would protect the rest of the system. As
for dedup, don't enable it on the zone dataset pool!
The zone is not accounted for the resources consumed by ZFS so that
could be a problem. I don't and won't assign gzip compression or
deduplication to any datasets, but a privileged user in the zone could
do just that.
I thought as much, but wasn't sure. I guess what you really want is
some form of block on overriding inherited properties.
Maybe raise this issue on zfs-discuss?
--
Ian.
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
