By mrbill on Aug 12, 2008
A couple folks have emailed me asking about my VxVM and VxFS in this physical to virtual conversion. As I have blahg'd before, separation is a good thing. In this case, we had Veritas Volume Manager and Veritas Filesystem on the source machine, and on the target machine. Volume Management and Filesystem Management should live within the Global Zone, not in local zones (or non-global zones as they are officially called). Mixing "system" activities within zones is a BadThing[tm], especially when the zone is a branded container. Trying to use Solaris 8 filesystem utilities and disk volume management utility binaries (even through the branded containers software) against a Solaris 10 system, kernel, and possibly even a hardware architecture (sun4v) unknown to a Solaris 8 operating system is a dangerous path to walk.
Definitely too much risk in there for me to even attempt to whack it into working.
We installed out Volume Management (VxVM) and Filesystem (VxFS) on the Solaris 10 target host system using the Veritas Foundation Suite (5.0 maintenance pack 1 Rolling Patch 4). All of the storage goodies were installed and configured as local objects on the Solaris 10 host system, and mounted under the /z/[zonename]_[function] pathnames as described earlier. The lofs loopback mounts and zonecfg "add fs" pieces mapped them into the places that we wanted them to be, just providing "disk space" to the Solaris 8 branded containers. We did use zonecfg "add fs" with a type of vxfs, and it worked as advertised. In the end, we decided that the VxFS pieces are a "system function" and should be mounted in the Global Zone under /z for simplicity and consistency.
Who knows, at some point we might even use ZFS instead of the VxFS in this configuration (more on that in a later blahg entry), and this allows us to keep the "zone space" filesystem and storage agnostic.