upgrading VxVM quick and easy

Rather than using encapsulated rootdisk, take a look at the possibility of a deencapsulating rootdisk and skip to Gene Trantham, section 2). This methodology is tried and true and with fewer side effects and better recovery options. If you still wish to have encapsulated rootdisk, see below.

Contributed by various people:

  1. If the root disk is encapsulated by veritas volume manager
    1. Break any root volume mirror (remove/detach mirror plex from rootvol. This way, you can simply boot back off of this mirror plex if you need to get back quickly).
    2. Save a copy of your /etc/system file
      1. Comment out any "rootdevice" lines in the /etc/system file (remember to use '*' as the comment character!)
    3. save your VxVM volumes in vfstab (by copying the current vfstab to another file, and copy the vfstab.prevm as vfstab; or comment out the Veritas volumes in the vfstab file)
    4. remove any patches you may have applied to VxVM
    5. reboot to single-user mode or multi-user mode to boot of non-veritas initialized volumes.
    6. remove (pkgrm) the current Veritas (SEVM=SUNW... or Veritas=VRTS...) packages
    7. reboot
    8. add (pkgadd) new packages from the Volume Manager cdrom
    9. Run vxinstall
      1. Do a custom install. ONLY encapsulate root disk into array - choose 4 to leave all other disks on all other controllers alone (or use an exclude file for the other disks)
      2. copy back your original (saved above) vfstab file as /etc/vfstab (or uncomment the volumes if applicable).
      3. Let it do its reboots
    10. Done: when it reboots, you should see the volumes listed in vfstab (if you have them in a diskgroup other than rootdg. If you had them in rootdg, you're going to get warnings about rootdg numbers not being the same.)

    <!-- "Part II">

  2. If the root disk is not encapsulated by veritas volume manager
    1. Save your VxVM volumes in vfstab (just in case -- by copying the current vfstab to another file e.g. /etc/vfstab.bak)
    2. Remove any patches you may have applied to VxVM
    3. remove (pkgrm) the current Veritas (SEVM=SUNW... or Veritas=VRTS...) packages
    4. pkgadd the new Veritas (SEVM=SUNW... or Veritas=VRTS...) packages
    5. remove the '/etc/vx/reconfig.d/state.d/install-db' file (to tell Veritas it's not a fresh install).
    6. Apply any new patches that may be required
    7. reboot

Also please note that the above will work for any/all versions of volume manager (2.x and 3.x) but the package names may differ. For SEVM the package names began with 'SUNW'; example: SUNWvmdev, SUNWvxvm, etc. For versions 3.x and higher or versions < 3.X bought directly from Veritas and not through Sun, the package names begin with 'VRTS'; example: VRTSvmdev, VRTSvxvm, etc. See this link for a version cross reference.

Gene Trantham writes, in his Best Practices Paper, about making the rootdg unencapsulated. When asked if this made upgrades to VxVM tricky, he responded:

The officially supported method of upgrading either VxVM or VxVM+OS is to run upgrade-start (located on the VxVM media). This script writes a new VTOC according to the geometry of the core OS volumes, whether the disk is encapsulated or not. In fact, it computes slice start,offset values at run time -- NOT from any saved VTOC or from the underlying slices which may be present on an encapsulated disk.

So, to answer your question, the method that I propose does not make it any harder to upgrade VxVM. But -- and this is a pet peeve of mine -- VxVM shouldn't have to be this hard to upgrade anyway. Consider a patch for SEVM. That does not require the unencapsulate,remove,replace,re-encapsulate procedure, so why should a software upgrade? The only difference is the revision number of the product.

I have successfully upgraded VxVM using two alternate approaches:
  1. Manipulate the /var/sadm/install/contents file and the package database such that the VRTSvxvm and related packages are 'officially' not installed (yet the binaries are still in place). You may then pkgadd your new VRTSvxvm, overwriting the existing binaries.

    This is unlikely to ever be suported by either Veritas or Sun as an acceptable method for upgrade, so should not be attempted in the field.

  2. If you have a clone OS disk or the ability to boot from a network boot image and still operate VxVM (such as with MR and JumpStart), you may upgrade like so:

This second method will be discussed with a little more detail in an upcoming BluePrint article (August [2000], I believe).

Here is a more explicit expansion of method 1. used when the rootdisk is deencapsulated following the guideliness of the best practices paper above:
  1. pkgrm VRTSvmsa VRTSvmman VRTSvmdev
  2. pkgrm.sh VRTSvxvm
  3. cd /net/wherever/new/vxvm/is
  4. pkgadd VRTSvxvm
    (reply 'y' to the overwrite question)
  5. Apply any patches for new VxVM that may be available
  6. Reboot ASAP


  1. Upgrading VxVM only. No OS upgrade
  2. Little or no error trapping in the script. Could mangle the patch and package database (but only a little bit :-)