Thanks for taking the time to go through this.  I have
a few responses to your comments in-line.

Edward Pilatowicz wrote:
> hey jerry,
> nice proposal.
> sorry i didn't reply to this earlier, i managed to miss it last
> week.  :(
> some comments are below.
> - you proposed:
>       The "org.opensolaris.libbe:parentbe" property is set to the
>       UUID of the global zone BE that is active when the non-global
>       zone BE is created.
>   when you first mention this it might make sense to say that no
>   such UUID currently exists (i know you say that later, but i
>   immediatly started thinking of the existing zone UUIDs).

We probably don't need to rev the proposal for this since the
caiman team is aware of the issue and adding this already.

>   also, at some point we had talked about having some core-bits
>   versioning that would restrict which packages a zone can update.
>   wouldn't it make more sense to have this propety set to that
>   identifier?  this way a gobal zone BE can boot any non-global
>   zone BE which has matching core bits.  this is less restrictive
>   that a UUID.  (also, if some stuff in the global zone is updated,
>   but the core-bits don't change there is no reason to snapshot
>   all the non-global zones.)

We don't have a design for how this would work yet, so I am not sure
if we can express it in a simple attribute value or not.

> - as mentioned in other emails, i agree that ROOT is a better name
>   than rpool.  also, i think that since we snapshotting all zone
>   filesystem, the zone realy needs a default dataset that is not
>   contained within ROOT.  (ethan mentioned this in other mails.)
>   i don't really have a strong opinion on the name (export, share,
>   common, etc) or the location (../z1/share or .../z1/data/share)
>   but i think this proposal is incomplete without specifying a
>   default common location for zone admins to place data that spans
>   all zone BEs.

Yes, we will be using ROOT.  Once we settle on a name for a shared
dataset, it'll be easy to add that since it is orthogonal to the
rest of this stuff.

> - you said:
>       One concern with this design is that the zone has access to its
>       datasets that correspond to a global zone BE which is not active.
>   fixing bugs in zfs aside, i think that this issue could be addressed
>   by telling users not to maniuplate filesystem in ROOT directly with
>   the zfs command.  instead these filesystems will always be manipulated
>   indirectly via tools like beadm and pkg, which can detect and prevent
>   this situation (and other invalid or inconsistent configurations).
>   this would also addresses the second issue of providing an interface
>   for promoting non-active BEs for zones.

Yes, we'll tell users, but does anybody listen? :-)  If someone
thinks they can just 'zfs destroy' to get some space, they will.

> - wrt a zones /dev filesystem, in nevada <zonepath>/root/dev is
>   not a re-mount of <zonepath>/dev.  instead the devnames
>   filesystem is mounted on <zonepath>/root/dev and <zonepath>/dev
>   is only used as a an attribute backing store by the devnames
>   filesystem.  this was done to allow upgrades from s10 where
>   devanems doesn't exist.  given that currently there is no
>   upgrade path from s10 to opensolaris, <zonepath>/dev really
>   should have just been eliminated from the first opensolaris
>   release.  all this would taken was removing:
>       opt="attrdir=%R/dev"
>   from
>       /usr/lib/brand/ipkg/platform.xml
>   of course doing that now would break upgrades from 2008.05 to
>   some future version of opensolaris that changes this behavior.
>   so we'll probably need special code to handle this upgrade.

We are already disallowing upgrades so that is not a factor.
I do have the ipkg brand already using the dev backing store
inside the root and I have a prototype if we wanted to put
this into s10.  For that case, the code would have to handle
the migration on the fly, so we may just not want to do that.

> - another issue wrt /dev and multiple BEs is that devnames
>   saves attributes in the backing store in a passthrough
>   manner.  this means that items in the underlying filesystems
>   are actualy device nodes.  so imagine the following bad
>   scenario:
>       zonecfg specified access to usb devices /dev/usb/*
>       zone is snapshotted and cloned
>       zonecfg is changed to remove access to usb devices /dev/usb/*
>       inside the zone, the old zone BE (and it's /dev attribute
>               backing store) are still accessible, so the raw
>               usb device nodes are still accessible in the zone.
>   i can't really think of a good way to protect against this other
>   than to have the /dev attribute store live outside of any zoned
>   filesystems.  so perhaps something like:
>       <zonepath>/DEV/ZBE1
>   where none of the above filesystems are zoned and where there is
>   a 1:1 mapping between snapshots/clones of the DEV/XXX
>   attribute backing stores and the zone boot environments.

Yes, this one is a bit of a problem.  I'll have to think about it some.
We don't have a way to associate zonecfg changes with a specific
snapshot/clone either.

Thanks again,
zones-discuss mailing list

Reply via email to