On Mon, May 18, 2009 at 4:01 PM, Jerry Jelinek <gerald.jeli...@sun.com> wrote:
> I've been spending some time researching ideas for how we could upgrade
> Solaris 10 once its installed in a solaris10 branded zone on S.next.
> We won't need this capability until S10u9 is released, but I want to make
> sure we do whatever we need to do now in order to enable this for the
> future.
>
> I have two possibilities in mind. Each of these is project level in its
> own right, so I assume we will only actually be able to do one of the
> options.
>
> 1) Make live-upgrade work inside the solaris10 branded zone
>
> I've been looking at the LU code to try to see what might be involved.
> There is no way we can emulate for this. We would have to do a project
> in the S10u9 LU code to make it solaris10 branded zone aware and enhance
> the code to make it work for upgrade inside the zone. There are various
> issues, such as ZFS pool awareness, mnttab parsing, file system mounting,
> grub awareness, etc. which would have to be coded around or changed. To
> enable this for the future I think we would have to set up the solaris10
> zone now using a ZFS root dataset model similar to what we're doing today
> with the ipkg brand on OpenSolaris.
* 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>.
* 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).
Things that use mnttab to figure out where things are mounted are
useless in zones - seemingly without reason. This has been a source
of confusion for administrators and end-users of zones. For example:
# df -h /
Filesystem size used avail capacity Mounted on
/ 0K 2.0G 77G 3% /
But the path that should be in column 1 is already exposed to the zone.
r...@ipkg:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 57.3G 76.6G 22.5K /rpool
rpool/zones 2.22G 76.6G 22K /zones
rpool/zones/ipkg 2.05G 76.6G 21K /zones/ipkg
rpool/zones/ipkg/ROOT 2.05G 76.6G 18K legacy
rpool/zones/ipkg/ROOT/zbe 2.05G 76.6G 2.02G legacy
So why not expose it just like in the global zone? This is what I
would like to see df report.
r...@ipkg# df -h /
Filesystem size used avail capacity Mounted on
rpool/zones/ipkg/ROOT/zbe
134G 2.0G 77G 3% /
Fixing this could be done in the open source code and would probably
have benefits beyond live upgrade.
* 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.
However, if the appropriate devices (slices or metadevices) are
exposed to the zone I don't see why it would be that hard to support
UFS as well. In the UFS case, the most obvious problems would be:
- communicating to the global zone that on next boot something else
should be mounted at <zonepath>/root.
- requiring that metadevice operations happen in the global zone as
a prerequisite step, then forbid the use of metattach et. al.
- creation of device nodes during BE copies would be problematic
Those that are concerned about the strict separation of root between
the global zone and non-global zones will want to stick with ZFS for
all the same reasons that giving raw disks and the ability to mount
them is discouraged. (Hmmm... patching operations could be calling
mknod whether it is ufs or zfs - does this happen?)
I've just about convinced myself that trying to support UFS for live
upgrade is not worth the effort.
* 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.
This would require changes to open source code and live upgrade code.
The benefits could go beyond this single brand (e.g. ipkg, etc.).
>
> Pros:
> a) The zone sysadmin would be in control of the upgrade.
> b) The user would be using a S10 tool to upgrade the zone (even
> though that tool will have been enhanced to be solaris10 zone aware).
> 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.
>
> Cons:
> a) We don't know this code.
> b) This is S10-only code that would have be enhanced.
> c) This is closed source so no community involvement.
> d) This is complex, legacy code which is a hairball.
> e) This code is fragile and there might be strong pushback for changing
> it further in S10.
> f) There is no re-use or other benefit to this work.
>
> 2) Enhance the zones "update on attach" code to do a real upgrade
>
> The idea here is that we improve the 'update on attach' code so it can
> use a Solaris 10 CD image as the source of the pkgs instead of the
> global zone. We would also enhance the code so it uses the full pkg
> list from the CD image instead of just the system software pkgs that
> have to be updated to sync the zone. The global zone admin would run
> this new code to upgrade specific solaris10 branded zones. They could
> either upgrade the zone in place or clone the zone and upgrade the clone,
> providing similar functionality to LU.
>
> Pros:
> a) I think this would be a simpler project.
> b) This code could be easily re-used to provide a true single zone
> "upgrade on attach" feature for a S10 native zone backport - lots of
> people want that.
> c) We know this code.
> d) This code is open source and readily re-usable.
>
> Cons:
> a) Upgrade would be done by the global zone admin, not the zone admin,
> so the zone admin is no longer the one in control.
> b) Because LU wouldn't work this might cause a perception of
> incompatibility between the solaris10 branded zone and a bare
> metal system.
> c) This doesn't solve the problem of using LU to apply patches to
> an ABE within the zone.
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.
> Please send me any comments on preferences for one solution or
> the other, as well as any other thoughts on this topic.
>
> Thanks,
> Jerry
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
>
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.
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
