On Mon 07 Feb 2011 at 04:43AM, Darren Reed wrote:
> Mike Gerdts wrote:
> >On Fri, Feb 4, 2011 at 11:32 PM, Darren Reed <darren.r...@oracle.com> wrote:
> >>On a test system that is using only ZFS, I'm trying to create a zone
> >>but it keeps failing with:
> >>netvirt-d1 ~# zoneadm -z exclusivetestzone1 install
> >>ERROR: the zonepath must be a ZFS dataset.
> >>The parent directory of the zonepath must be a ZFS dataset so that the
> >>zonepath ZFS dataset can be created properly.
> >>I don't get it. This restriction never used to exist.
> >Zones need to be on ZFS with a particular dataset layout so that boot
> >environments can be managed with beadm, pkg, etc. That is, zone boot
> >environments have very similar requirements that global zone boot
> >environments have.
> >>Why do I need to do something extra that is mandatory?
> >If the parent of the zonepath is itself a ZFS dataset, it does happen
> That's not what I observed...
That should be: if the parent is itself the root of a ZFS dataset that
is not within a global zone boot environment.
> >>Further to this, there's a script on Oracle's website here:
> >>that also fails to configure & create a zone that can be installed with b154
> >>To give an example (/tmp/ozone is the script from the above page)...
> >>/ is rpool/ROOT/solaris
> >># zfs create rpool/ROOT/solaris/zone
> >># zfs set mountpoint=/zone rpool/ROOT/solaris/zone
> >That needs to be fixed. It would cause zone boot environments to be
> >contained within global zone boot environments. As new global zone
> >boot environments are created, you will end up with roughly 2x the
> >number of non-global zone BEs.
> Why is that necessarily a problem?
It complicates the architecture and implementation in unnecessary ways.
> What if I only ever have 1 boot environment?
As soon as you do "pkg update" (nee pkg image-update) in the global zone
you will have have multiple boot envirnoments. Only if you never update
your OS (previously known as patching) can you get by with a single BE.
> Surely that's my problem if I end up with so many zone BEs?
It seems much more likely that people end up with unneeded zone BEs
trapped inside of global zone BEs, which then becomes problematic for
> If I was in the habit of upgrading, creating new BEs, validating
> those BEs, then deleting the old ones, why wouldn't the same apply
> to zones and thus result in mitigation of the problem you cite
If the old global zone BEs and associated snapshots are deleted, there's
probably not a big problem. However, the code paths for creating the
zone BEs during "beadm create" and similar operations becomes more
complicated having to deal with more scenarios. More complicated for
the sake of flexibility that has no material benefit means that
developers spend less time working on things that are of material
Is there a reason that
zfs create -o mountpoint=/zones rpool/zones
then creating each zonepath as /zones/<zonename> is a problem?
Solaris Core OS / Zones
zones-discuss mailing list