On  7/02/11 08:22 AM, Mike Gerdts wrote:
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?

From the perspective of a developer that uses a test suite that creates
zones using a shell script, the less changes required to my script the
better. I suspect that ultimately the above will become part of the system
installation configuration, but it would be nice if the zones tools kept the
difference in requirements for disk configuration internal? Thus the same
commands "just work" when building zones on Solaris10 & 11.

I suppose in my case, it is "rpool/zone" and "mountpoint=/zone".


zones-discuss mailing list

Reply via email to