Wednesday, June 29, 2005

Upgrading VxVM

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.)

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
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
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:
* boot from alternate media w/ VxVM drivers loaded
* mount rootvol and friends on /a
* chroot /a pkgrm VRTSvxvm
* cd /net/whereever/new/vxvm/is
* pkgadd -R /a . VRTSvxvm

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. 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 :-)


Post a Comment

<< Home