Thanks for looking this over, responses in-line.

Steve Lawrence wrote:
>> During the zone installation and after the zone is installed, the zone's ZBE1
>> dataset is explicitly mounted by the global zone onto the zone root (note, 
>> the
>> dataset is a ZFS legacy mount so zones infrastructure itself must manage the
>> mounting.  It uses the dataset properties to determine which dataset to
>> mount, as described below.): e.g.
>>      # mount -f zfs rpool/export/zones/z1/rpool/ZBE1 /export/zones/z1/root
>> The rpool dataset (and by default, its child datasets) will be implicitly
>> delegated to the zone.  That is, the zonecfg for the zone does not need to
>> explicitly mention this as a delegated dataset.  The zones code must be
>> enhanced to delegate this automatically:
> Is there any requirement to have a flag go disallow a zone from doing zfs/BE
> operations?  I'm not sure when an admin may want to make this restrction.

There has been no discussion about disallowing a zone from installing sw,
which is what I think you are asking for.  Would you want that to
be a general new feature or specific to ipkg branded zones?

>>      rpool/export/zones/z1/rpool
>> Once the zone is booted, running a sw management operation within the zone
>> does the equivalent of the following sequence of commands:
>> 1) Create the snapshot and clone
>>      # zfs snapshot rpool/export/zones/z1/rpool/[EMAIL PROTECTED]
>>      # zfs clone rpool/export/zones/z1/rpool/[EMAIL PROTECTED] \
>>        rpool/export/zones/z1/rpool/ZBE2
>> 2) Mount the clone and install sw into ZBE2
>>      # mount -f zfs rpool/export/zones/z1/rpool/ZBE2 /a
>> 3) Install sw
>> 4) Finish
>>      # unmount /a
>> Within the zone, the admin then makes the new BE active by the equivalent of
>> the following sequence of commands:
>>      # zfs set org.opensolaris.libbe:active=off 
>> rpool/export/zones/z1/rpool/ZBE1
>>      # zfs set org.opensolaris.libbe:active=on 
>> rpool/export/zones/z1/rpool/ZBE2
>> Note that these commands will not need to be explicitly performed by the
>> zone admin.  Instead, a utility such as beadm does this work (see issue #2).
> Inside a zone, beadm should "fix" this.

This is already noted here.

> From the global zone, beadm should be able to "fix" a (halted?) zone in this
> state so that it may be booted.

I am not sure that is possible, since there was deliberate
effort by a sysadmin to get the zone into this state, it might
be difficult for a tool to automatically undo this in a reliable way.
I don't see this as a requirement since you can always manually
undo whatever the sysadmin did to set up the properties incorrectly,
assuming you can figure out which ZBEs are which.

> I think this means that the global zone should be able to do some explict
> beadm operations on a zone (perhaps only when it is halted?), in addition
> to the automatic ones that happen when the GBE is manipulated.
>> When the zone boots, the zones infrastructure code in the global zone will 
>> look
>> for the zone's dataset that has the "org.opensolaris.libbe:active" property 
>> set
>> to "on" and explicitly mount it on the zone root, as with the following
>> commands to mount the new BE based on the sw management task just performed
>> within the zone:
>> # umount /export/zones/z1/root
>> # mount -f zfs rpool/export/zones/z1/rpool/ZBE2 /export/zones/z1/root
>> Note that the global zone is still running GBE1 but the non-global zone is
>> now using its own ZBE2.
>> If there is more than one dataset with a matching
>> "org.opensolaris.libbe:parentbe" property and the
>> "org.opensolaris.libbe:active" property set to "on", the zone won't boot.
>> Likewise, if none of the datasets have this property set.
>> When global zone sw management takes place, the following will happen.
>> Only the active zone BE will be cloned.  This is the equivalent of the
>> following commands:
>>      # zfs snapshot -r rpool/export/zones/z1/[EMAIL PROTECTED]
>>      # zfs clone rpool/export/zones/z1/[EMAIL PROTECTED] 
>> rpool/export/zones/z1/ZBE3
>> (Note that this is using the zone's ZBE2 dataset created in the previous
>> example to create a zone ZBE3 dataset, even though the global zone is
>> going from GBE1 to GBE2.)
>> When global zone BE is activated and the system reboots, the zone root must
>> be explicitly mounted by the zones code:
>>      # mount -f zfs rpool/export/zones/z1/rpool/ZBE3 /export/zones/z1/root
>> Note that the global zone and non-global zone BE names move along 
>> independently
>> as sw management operations are performed in the global and non-global
>> zone and the different BEs are activated, again by the global and non-global
>> zone.
>> 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.  The zone admin could
>> delete the zone's inactive BE datasets which are associated with a non-active
>> global zone BE, causing the zone to be unusable if the global zone boots back
>> to an earlier global BE.
>> One solution is for the global zone to turn off the "zoned" property on
>> the datasets that correspond to a non-active global zone BE.  However, there
>> seems to be a bug in ZFS, since these datasets can still be mounted within
>> the zone.  This is being looked at by the ZFS team.  If necessary, we can 
>> work
>> around this by using a combination of a mountpoint along with turning off
>> the "canmount" property, although a ZFS fix is the preferred solution.
>> Another concern is that the zone must be able to promote one of its datasets
>> that is associated with a non-active global zone BE.  This can occur if the
>> global zone boots back to one of its earlier BEs.  This would then cause an
>> earlier non-global zone BE to become the active BE for that zone.  If the 
>> zone
>> then wants to destroy one of its inactive zone BEs it needs to be able to
>> promote any children of that dataset.  We must make sure that any 
>> restrictions
>> we use with the ZFS "zoned" attribute doesn't prevent this.  This may require
>> an enhancement in ZFS itself.
> I think it would be generally useful if zfs had a "destroy and promote as
> necessary" operation.  Otherwise, this will just be re-implemented by various
> higher level software in annoyingly different ways.

Yes, we may need some zfs enhancements here.  We'll have to see as this
moves forward, but this sounds like a good idea.

Thanks again,
zones-discuss mailing list

Reply via email to