Managing Zones using ZFS
By John Clingan on Jun 04, 2006
Martin has a really useful blog entry on using a new Nevada build 40 feature for cloning a zone. No need to hack it anymore, it's simply there.
I have found this capability, even through hacking, to be invaluable. While it saves me hours of cumulative time waiting, it also enables me to concentrate on whatever the problem is at hand. For example, I deployed an N-Tier Highly Available (sans a single laptop) application using zones on my laptop in under an hour. That included zone creation, product installation and configuration, etc.
I'll tell you where I am having a problem, though. Getting my head around which zone does what and then understanding the zfs/zone dependency tree. For example, at the peak I had roughly 20 zones cloned and slightly tweaked to meet my needs. Grokking which zone had what tweak was problematic. The temporary solution was to create (using the hack) snapshots with names such as "appserver@TWEAKED_THIS" and "appserver@after_TWEAKED_THIS_and_then_tweaked_that". I would get a few levels deep. Then, of course, when it comes time to clean it all up, it's not easy (that I know of) to find out which cloned zones depend on what other cloned zones. There is, of course, the zfs "origin" property, but I wish there were a zfs command to recursively print out the entire zfs dependency tree from pool root down to leaf nodes. "zfs -r", which seems to stop at snapshots (IIRC) and doesn't pick up the clones of snapshots. The origin property does, though. A perl or shell script could probably do it with some thought.
I haven't tried build 40 yet, so some of this may be addressed.