Matty wrote:
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?
They might work, but as Eric said, the configuration isn't
supported at this time because there hasn't been adequate
testing and we know that there can be complications with
delegated datasets.
Also, even leaving aside the issue of delegated datasets,
the install code (which include patchadd and pkgadd) has
assumptions that can cause patch problems with zone roots
under some circumstances. The main one that I know about
is the matter of space checking. The install code
currently doesn't understand pooled storage. If you have
ten datasets in a pool with 10 GB of available space, a
"df" on each dataset will report 10 GB of available space
(yes, there are ways to modify this with reservations and
quotas, but let's leave that aside for now). But you
can't allocate 10 GB in EACH dataset. The install code
will assume that 10 additional GB of contents can be
allocated in each dataset because it doesn't understand
that the free space is coming out of a common pool. So
the install/patching code might think there's adequate
space for an upgrade when there really isn't.
So until the install code is made zfs-aware (which is
related to the issue of bootable zfs, but not limited to it),
zone roots in zfs datasets is an unsupported configuration.
It's tantalizing, however, because it would often work quite
well. Maybe it's worth some kind of solution short of
full zfs boot support. Something to consider.... However,
given the timing of full zones upgrade support (independent
of zfs), it may all have to come out at the same time anyway.
Lori
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
