By John Clingan-Oracle on Aug 24, 2006
For the zone and/or zfs aficionado this is probably old news. For those new to Solaris, this is pretty straightforward. While zones leverage Solaris resource controls, controlling disk space in an administratively efficient manner was challenging ... until recently.
ZFS sets quotas at the filesystem level of granularity. Sssooo, why not give each zone its own ZFS filesystem? Creating and managing a zfs filesystem is easy to do. With this approach, we also get the added benefit of managing each zone's ZFS properties independently, such as enabling compression (or potentially encryption in the future) on a zone by zone basis.
Assuming a zfs pool named 'zonepool':
## First, the ZFS setup
# zfs create zonepool/zone1
## I'm a stickler about my zone mountpoints
# zfs set mountpoint=/zones/zone1 zonepool/zone1
# zfs set quota=5G zonepool/zone1
## And now for the zone setup
# zonecfg -z zone1
Use 'create' to begin configuring a new zone.
zonecfg:zone1> set zonepath=/zones/zone1
I haven't tried applying this to cloned zones yet. My bet is that if a zone is on a cloned filesystem, the 5 gigs of disk will be above and beyond the disk space "used" by a cloned dataset, not inclusive of it. I did do a test a while back on a zone with both a quota and compression enabled, and the quota is applied to the post-compressed data, not the pre-compressed data. Makes sense since that is the true on-disk utilization.
Note, using ZFS delegated administration with zonecfg's "add dataset" command, users home directories, if managed locally in the zone, can also have per-user ZFS attributes applied (compression, quotas, etc). However, I suspect NFS mounts of ZFS-enabled home directories to be of more benefit in most scenarios.
Of course, after writing 95% of this blog entry, I ran across this howto while looking for a link. Wouldn't be the first time. What the heck, I'll post this entry anyway