Topics:
Placing the Boot Disk Under VxVM Control
Creating an Alternate Boot Disk
Removing the Boot Disk from VxVM Control
Upgrading to a New VxVM Version
What is Encapsulation?
Encapsulation is a method of placing a disk under VxVM control.in which the data that exists on a disk is preserved. Encapsulation converts existing partitions into volumes, which provides continued access to the data on the disk after a reboot. After a disk has been encapsulated, the disk is handled in the same way as an initialized disk.
Requirements:
One free partition (for public and private region)
s2 slice that represents the full disk
2048 sectors free at beginning or end of disk for the private region
What is Rootability?
Rootability, or root encapsulation, is the process of placing the root file system, swap device, and other file systems on the boot disk under VxVM control. VxVM converts existing partitions of the boot disk into VxVM volumes. The system can then mount the standard boot disk file systems (that is, /, /usr, and so on) from volumes instead of disk partitions.
Requirements are the same as for data disk encapsulation, but the private region can be created from swap space.
Why Encapsulate the Boot Disk?
You should encapsulate the boot disk only if you plan to mirror the boot disk.
Benefits of mirroring the boot disk:
1) Enables high availability
2) Fixes bad blocks automatically (for reads)
3) Improves performance (ed. I don’t buy this point)
There is no benefit to boot disk encapsulation for its own sake. You should not encapsulate the boot disk if you do not plan to mirror the boot disk.
Limitations of Boot Disk Encapsulation
Encapsulating the boot disk adds steps to OS upgrades.
A system cannot boot from a boot disk that spans multiple devices
You should never expand or change the layout of boot volumes. No volume associated with an encapsulated boot disk (rootvol, usr, var, opt, swapvol, and so on) should be expanded or shrunk, because these volumes map to a physical underlying partition on the disk and must be contiguous.
If you attempt to expand these volumes, the system can become unbootable if it becomes necessary to revert back to slices in order to boot the system. Expanding these volumes can also prevent a successful OS upgrade, and a fresh install can be required.
Note: regarding Solaris, the upgrade_start script may fail.
Solaris File System Requirements
For root, use, var, and opt volumes:
1) Use UFS file systems (VxFS is not available until later in the boot process)
2) Use contiguous disk space. (Volumes cannot use striped, RAID-5, concatenated mirrored, or striped mirrored layouts)
3) Do not use dirty region logging on the system volumes. (You can use DRL for the opt and var volumes)
For swap volumes:
1) The first swap volume must be contiguous, and, therefore, cannot use striped or layered layouts.
2) Other swap volumes can be noncontiguous and can use any layout. However, there is an implied 2Gb limit of usable swap space per device for 32-bit operating systems.
Before Encapsulating the Boot Disk
Plan your rootability configuration. bootdg is a system-wide reserved disk group name that is an alias for the disk group that contains the volumes that are used to boot the system. When you place the boot disk under VxVM control, VxVM sets bootdg to the appropriate disk group. You should never attempt to change the assigned value of bootdg; doing so may render you system unbootable. An example configuration would be to place the boot disk into a disk group named sysdg, and add at least two more disks to the disk group: one for a boot disk mirror and one as a spare disk. VxVM will set bootdg to sysdg.
For Solaris, enable boot disk aliases: eeprom “use-nvramrc?=true”
Record the layout of the partitions on the unencapsulated boot disk to save for future use.
Encapsulating the Boot Disk
vxdiskadm:
“Encapsulate one or more disks”
Follow the prompts by specifying:
1) Name of the device to add
2) Name of the disk group to which the disk will be added
3) Sliced disk format (The boot disk cannot be a CDS disk)
vxencap:
/etc/vx/bin/vxencap –g diskgroup accessname
/etc/init.d/vxvm-reconfig accessname
After Boot Disk Encapsulation
You can view operating system-specific files to better understand the encapsulation process.
Solaris:
1) VTOC (prtvtoc device)
2) /etc/system
3) /etc/vfstab
Linux:
/etc/fstab
Alternate Boot Disk: Requirements
An alternate boot disk is a mirror of the entire boot disk. It preserves the boot block in case the primary boot disk fails
Creating an alternate boot disk requires that:
1) The boot disk be encapsulated by VxVM
2) Another disk be available with enough space to contain all of the boot disk partitions
3) All disks be in the boot disk group
The root mirror places the private region at the beginning of the disk. The remaining partitions are placed after the private region.
Creating an Alternate Boot Disk
VEA:
1) Highlight the boot disk, and select Actions -> Mirror Disk
2) Specify the target disk to use as the alternate boot disk.
vxdiskadm:
“Mirror volumes on a disk”
CLI:
To mirror the root volume only:
vxrootmir alternate_disk
To mirror all other unmirrored, concatenated columes on the boot disk to the alternate disk:
vxmirror –g diskgroup boot_disk alternate_disk
To mirror other volumes to the boot disk or other disks:
vxassist –g diskgroup mirror homevol alternate_disk
On Solaris, to set up system boot information on a VxVM disk:
vxbootsetup
Booting from an Alternate Mirror (Solaris)
1) Set the eeprom variable use-nvramrc? to true:
ok> setenv use-nvramrc? true
ok> reset
This variable must be set to true to enable the use of alterate boot disks.
2) Check for available boot disk aliases:
ok> devalias
Output displays the name of the boot disk and available mirrors.
3) Boot from an available boot disk alias:
ok> boot vx-diskname
Unencapsulating a Boot Disk
To unencapsulate a boot disk, use vxunroot
Requirements: Remove all but one plex of rootvol, swapvol, use, var, opt, and home.
Use vxunroot when you need to:
* Boot from physical system partitions
* Change the size or location of the private region on the boot disk.
* Upgrade both the OS and VxVM
Do not use vxunroot if you are only upgrading VxVM packages, including the VEA package.
The vxunroot Command
1) Ensure that the boot disk volumes only have one plex each:
vxprint –ht rootvol swapvol use var
2) If boot disk volumes have more than one plex each, remove the unnecessary plexes:
vxplex –g diskgroup –o rm dis plex_name
3) Run the vxunroot utility:
vxunroot
Notes on Upgrading Storage Foundation
* Determine what you are upgrading: Storage Foundation, VxVM only, both VxVM and the OS, or the OS only.
* Follow documentation for Storage Foundation and the OS
* Install appropriate patches
* A license is not required to upgrade VxVM only
* Your existing VxVM configuration is retained
* Upgrading VxVM does not upgrade existing disk group of file system versions. You may need to manually upgrade each after a VxVM upgrade.
* Get the latest upgrade information from the support.veritas.com website
* Backup data before upgrading (Note: copy /kernel/drv/sd.conf to a safe location)
Upgrading Storage Foundation
1) Unmount any mounted VxFS file systems
2) Reboot the system to single-user mode
3) When the system comes up, mount the /opt and /var filesystems
4) Mount the Veritas cdrom
5) Invoke the common installer, run the install command:
cd /cdrom/cdrom0
./installer
6) Answer the prompts appropriately
Upgrading VxVM Only
Methods:
* VxVM installation script (installvm)
* Manual package upgrade
* VxVM upgrade scripts (Solaris only)
- upgrade_start
- upgrade_finish
Note: on Sun, the upgrade_finish script changes /etc/vfstab to point to /dev/vx/bootdg/… even if bootdg doesn’t exist. Remember to change it back by hand before reboot. Unless you like booting off of CD in order to change the vfstab by hand.
Upgrading VxVM Only: installvm
* Invoke the installvm script and follow the instructions when prompted
* If you are performing a multihost installation, you can avoid copying packages to each system. For example, to ensure that packages are not copied remotely when using the NFS mountable filesystem $NFS_FS:
# cd /cdrom/CD_NAME
# cp –r * $NFS_FS
# cd volume_manager
# ./installvm –pkgpath $NFS_FS/volume_manager/pkgs –patchpath $NFS_FS/volume_manager/patches
* This copies the files to an NFS mounted file system that is connected to all of the systems on which you want to install the software.
Upgrading VxVM Only: Manual Packages Upgrade
1) Bring the system to single-user mode
2) Stop the vxconfigd and vxiod daemons:
# vxdctl stop
# vxiod –f set 0
3) Remove the VMSA software packages VRTSvmsa (optional)
4) Add the new VxVM packages using OS specific package installation commands
5) Perform a reconfiguration reboot (i.e. on Sun: reboot -- -r)
Scripts Used in Upgrades: Sun only
The upgrade_start and upgrade_finish scripts preserve your VxVM configuration
To check for potential problems before and upgrade, run:
# upgrade_start –check
Note: on Sun: save off a copy of your /etc/vfstab and /kernel/drv/sd.conf. The upgrade_finish will screw both up. Your /etc/vfstab will point to bootdg even if you don’t use that diskgroup name. Also, your sd.conf will be messed up if you use SAN and you’ll not see all of your disks. The vfstab can be corrected by hand, but you’ll need to copy the sd.conf back to your system to correct the “fix”.
Upgrading VxVM Only: Upgrade Scripts: Sun Only
1) Mount the Veritas cdrom
2) Run upgrade_start –check
3) Run upgrade_start
4) Reboot to single-user
5) mount /opt if not part of the root filesystem
6) Remove the VxVM package and other related VxVM packages with pkgrm
7) Reboot the system to multiuser mode
8) Verify that /opt is mounted, and than install the new VxVM packages with pkgadd
9) Run the upgrade_finish script
Upgrading Solaris Only
To prepare:
1) Detach any boot disk mirrors
2) Check alignment of boot disk volumes
3) Ensure that /opt is not a symbolic link
To upgrade:
1) Bring the system to single-user mode
2) Mount the Veritas cdrom
3) Run upgrade_start -check
4) Run upgrade_start
5) Reboot to single-user mode
6) Upgrade the OS
7) Reboot to single-user mode
8) Mount the Veritas cdrom
9) Run upgrade_finish
10) Reboot to multiuser mode
Upgrading VxVM and Solaris
To prepare:
1) Install license keys if needed
2) Detach any boot disk mirrors
3) Check alignment of boot disk volumes
4) Ensure that /opt is not a symbolic link
To remove old version:
1) Bring system to single-user mode
2) Mount the Veritas cdrom
3) Run upgrade_start –check
4) Run upgrade_start
5) Reboot to single-user mode
6) Remove VxVM packages
To install new version:
1) Reboot to single-user mode
2) Upgrade OS
3) Reboot to single-user mode
4) Mount Veritas cdrom
5) Add new licensing and VxVM packages
6) Run upgrade_finish
7) Reboot to multiuser mode
8) Add additional packages
After Upgrading
1) Confirm that key VxVM processes (vxconfigd, vxnotify, vxcache, vxrelocd, vxconfigbackupd, and vxesd) are running:
# ps –ef grep vx
2) Verify the existence of the boot disk’s volumes:
# vxprint –ht
Upgrading VxFS
1) Unmount any mounted Veritas file systems
2) Remove old VxFS packages
3) Comment out VxFS filesystems in /etc/vfstab, then reboot
4) Upgrade the OS if necessary for VxFS version compatibility.
5) Add the new VxFS packages
6) Undo any changes made to /etc/vfstab
7) Reboot
Custom Search
