On Thu, 27 Jul 2006, Eric Schrock wrote:
The original reasoning was that we didn't have enough time to validate the behavior of the zone upgrade tools with ZFS as the root filesystem, particularly as these tools (Ashanti, Zulu) are a moving target. Upon closer inspection, we found that this scenario should work with the current upgrade solution. What will definitely not work is to delegate a ZFS dataset to a local zone, and then place system software (i.e. Solaris package contents) within such a filesystem. This should work if the mountpoint is set to 'legacy', however. Basically, rather than trying to explain the ins and out of the current situation (which aren't entirely understood in the context of future zones upgrade solutions), we opted to declare this as 'unsupported'. In reality, putting zone roots on ZFS datasets should be perfectly safe (modulo the caveat above). However, we reserve the right to break upgrade in the face of such zones. We are working on integrating ZFS more closely with the whole install and live upgrade experience. Part of this work will include making zones upgrade behave well regardless of ZFS configuration. The current install/upgrade process has a long history of preconceived notions that don't apply in the ZFS work (such as a 1-1 relationship between devices and filesystems, /etc/vfstab, legacy mountpoints, etc), so this is no small task.
Are there any known issues with patching zones that are installed on a ZFS file system? Does smpatch and company work ok with this configuration?
Thanks, - Ryan -- UNIX Administrator http://prefetch.net _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
