Mike Gerdts wrote: > With the latest requirements for snap upgrade specifying that zones > must be on ZFS file systems, it occurs to me that I haven't seen > anything indicating that people shouldn't be too attached to the file > system they are running on. For instance, I could envision an > architecture where several machines were using VCS with Cluster Volume > Manager and VxFS to form a (parallel) cluster file system that holds > zone roots. The same could happen with QFS. The transition to ZFS > would seem to force a re-architecture. > > I see mention of zone roots not being allowed on cluster file systems > in the Solaris Cluster documentation, but I see no mention of it in > the Zones documentation (System Administration Guide: Solaris > Containers-Resource Management and Solaris Zones). This gives the > impression it is a limitation of Solaris Cluster, not the Solaris > Roadmap. This seems to be an important omission that needs to be > addressed if, in fact, the installer is going to break what appears to > be a quite workable architecture of today.
I don't know if its a limitation in Solaris Zones or not, or whether it was left out of the Solaris [Zones?] Roadmap, but the installer's roadmap is certainly moving toward ZFS. So for the UFS case we certainly want to migrate zones to ZFS by default. This enables features like reversible upgrades/updates of the system going forward. > > One workaround for this would seem to be to create disk images (mkfile > ...) on the cluster file system then create a per-zone zpool using > those disk images. This would allow a cluster-wide pool of storage to > be used with smallish chunks of it (disk images) being used by the > various cluster nodes at different times. Of course, while this looks > like it may work, it needs to be taken in context with the following > paragraph. > > I expect that someone will pipe in saying that zones on VxFS or QFS > will not support upgrade today. This is true, and while we don't have any plans to add support for it in upgrade, I don't see this as breaking any of that current usage. Those zones simply don't get upgraded. > This, however, doesn't seem to be > well publicized. Further such a statement can be taken as "it is OK > to put zones on these file systems but you will not be able to use the > upgrade feature." For customers that don't do upgrades anyway, this > does not seem to be a limitation to consider. Even smaller operations like pkg'ing updates will benefit from snapshotting and rollback, so ZFS is still recommended and the direction we want to go toward. We're working with the IPS team to provide system-wide snapshotting (a snapshot of a 'BE') for pkg transactions. > > So... what does the new installation framework have in store for > non-trivial configurations of zones that may need to be portable > across machines? Are we talking native zones here or non-native, and what do you mean by portable, zone detach/attach? > > > [In interest of avoiding the headaches with cross-posting, I have > initially targeted only caiman-discuss with this message. If useful > conversation that is highly appropriate for zones-discuss happens > I'll post a pointer to this conversation on zones-discuss.] I'm sure I didn't answer all of your questions, so some of these probably need to get directed over there. -ethan
