[indiana-discuss] [pkg-discuss] zones w/ indiana

[Steffen Weiberle]

Dan Price wrote:
> On Thu 01 May 2008 at 09:50PM, Jason King wrote:
>> On a related issue, what about IPS w/ sparse root zones?  If I install
>> packages from in the global zone while an IPS zone is booted, I notice
>> doing a pkg info in the zone doesn't know it's there, and rebooting
>> doesn't seem to help, nor did running pkg image-update within the
>> zone.  Am I missing something?
> 
> We have what I'd call rudimentary support for zones in this release; zones
> are essentially "whole root" and are independent of the global zone.  That means
> you're on your own in terms of keeping your zones up to date with respect
> to the global zone.  I also can't warrant that zones you create today
> will be automatically upgradeable when a more-full-fledged-zones-support
> version of opensolaris comes out.
> 
> I'll put a blog entry together about the good and the bad, soon I hope.
> 
> As for sparse zones, which feature a read-only looped-back /usr (and/or /opt)
> -- I have been doing a lot of thinking about how (or frankly, if) we should
> support them in the new pkg(5) universe.

Something to ponder as I watch the insides of my eye lids tonight. I did 
not know that whole root zones work and sparse do not, as I only create 
sparse zones to save space, and that fails even on RC3.

Since zonepath on ZFS is supported in Nevada and OpenSolaris, the price 
of whole root is smaller if, which I will, I clone. Smaller as I create 
lots of zones, that is. The initial zone will consume a lot of disk 
space (relative to sparse zones). [1]

My unknown is the unexpected increase in zone size due to copy on write 
of the clone as different zones diverge from the snapshot.

Off to ponder...

Steffen

[1] While my 80 or 100GB laptop disk seems large with an OpenSolaris 
installation, I generally mutliboot, and have three or four 8-15GB per 
OS instance slices (Live Upgrade or fresh install), and a shared slice 
for data I want to share between images. Since I can't share a zonepath 
between different release/builds (I may be going up or down, so upgrade 
on attach does not apply), the zonepath needs to be exclusive to the OS 
on which it was created. Thus the expense of a whole root zone in disk 
space starts limiting how many zones I can created, or my flexibility in 
using multiple releases on a single disk.

> 
> I'm planning on posting a write-up exploring the issues to zones-discuss
> in the near future.  I'll be looking for a lot of input from the community
> of zones operators on future direction.
> 
> 	-dp
>