Mike,

Thanks for reviewing this.  I have a few comments in-line.
I trimmed the rest.

Mike Gerdts wrote:
* ZFS pool awareness

Isn't it already zpool aware as of S10u6?  Perhaps you mean that it
needs to handle paths other than rpool/ROOT/<be> such as
[<pool>[/arbitrary path]/]<zone>/root/ROOT/<be>.

Yes, thats the problem.  There is a lot of code in LU that is attempting
to look at and manipulate zpools for the PBE and ABE.  There is no zpool
available within the zone so all of the code that wants to discover zpools
and manage datasets within those pools will need modification.

* mnttab parsing

Would mnttab parsing be better handled by providing reasonable paths
in mnttab via the brand shim?  Consider an ipkg branded zone that I
have on a SXCE snv112 system (yes it is a bit of a hack).

Thats a possibility although it has an impact on the security model
for zones themselves.  Since this was part of the original design and
assumptions for what global zone data would be visible within the
non-global zone, I think we'd have to be very careful to understand
what would break or become less secure by changing that.

* file system mounting

I think this is greatly simplified if ZFS is listed as a prerequisite
for live upgrade support.  That is, I think all of the code is
probably there.

Its more complicated than that since LU wants to manage mounts for
the PBE and ABE but some mounts are managed by the global zone on
behalf of the non-global zone, so we would have to make LU handle
that properly as well.

* grub awareness

Clearly grub is not a part of this, nor is /dev/openprom or the bootfs
zpool property.  Perhaps this goes back to file system mounting above.
 The ability to call zoneadmd from within the zone (e.g.
/var/run/zoneadmd_<sock|door>) to set a zonecfg bootfs property would
probably be good.

If we model this on what we've already done for the ipkg brand then
we could cope with this.  Its just more changes to LU to make it do
this.

   c) The zone admin could use LU ABEs to apply patches to their zone.

If an option with (c) isn't offered, many will go off inventing their
own mechanism to simulate live upgrade.  Having a recommended manual
process and a structure that supports it will probably save Sun and
Solaris users lots of time and money.

The issues I highlighted above are just the ones I saw from a
quick look at the LU code.  I don't know what other problems are
there since no one on the zones team knows the LU code base.  Clearly
we can make LU work with enough changes to the code.  Its just
software.  I tried to highlight the fact that this is going to be a
more complex option with no other benefit.  It might simply come
down to a decision about how much resources and time we have to work
on an upgrade solution.  It is unlikely we could get any resources
from the install team since they are already fully committed on the
caiman project and since this is closed source, we can't get any
help from the community.

S10u7 just came out, I think you said that this is targeted to support
S10u8, and it would be able to upgrade from S10u8 to S10u9.  Will
S10u10 ever exist?  Will it see a lot of adoption before S10u9 exists?
 If it is only good for a maximum one time upgrade with several years
of patching afterward, this option doesn't seem to be worth it.

I have no idea how many S10 update releases there will be.  I'm
not sure anyone else would really know either at this point in time.
The best I can say is that S10 updates will continue for the forseeable
future.

Clearly I am more in the make "Live Upgrade work" camp.  If the zfs
userland components can be made to work in the solaris9 brand, there's
benefit for it as well.

If LU weren't so problematic it would be the obvious thing to do.
Unfortunately, because of the issues I tried highlight, its not clear.

I don't know of any plan to backport ZFS to Solaris 9.  If there was
such a plan, it would be a separate project by a different team.  I
would say that this is highly unlikely to ever occur.

Thanks again for looking this over,
Jerry

_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to