Encapsulating and mirroring the root disk


		< Previous \| TOC \| Index \| Next >

Encapsulating and mirroring the root disk

VxVM allows you to mirror the root volume and other areas needed for booting onto another disk. This makes it possible to recover from failure of your root disk by replacing it with one of its mirrors.

Use the fdisk or sfdisk commands to obtain a printout of the root disk partition table before you encapsulate the root disk. For more information, see the appropriate manual pages. You may need this information should you subsequently need to recreate the original root disk.

See the Veritas Volume Manager Troubleshooting Guide.

See "Restrictions on using rootability with Linux" on page 109.

You can use menu item 2 of the vxdiskadm command to encapsulate the root disk.

See "Encapsulating a disk" on page 104.

You can also use the vxencap command, as shown in this example where the root disk is sda:

# /etc/vx/bin/vxencap -c -g diskgroup rootdisk=sda

where diskgroup must be the name of the current boot disk group. If no boot disk group currently exists, one is created with the specified name. The name bootdg is reserved as an alias for the name of the boot disk group, and cannot be used. You must reboot the system for the changes to take effect.

Both the vxdiskadm and vxencap procedures for encapsulating the root disk also update the /etc/fstab file and the boot loader configuration file (/boot/grub/menu.lst or /etc/grub.conf (as appropriate for the platform) for GRUB or /etc/lilo.conf for LILO):

Entries are changed in /etc/fstab for the rootvol, swapvol and other volumes on the encapsulated root disk.
A special entry, vxvm_root, is added to the boot loader configuration file to allow the system to boot from an encapsulated root disk.

The contents of the original /etc/fstab and boot loader configuration files are saved in the files /etc/fstab.b4vxvm, /boot/grub/menu.lst.b4vxvm or /etc/grub.conf.b4vxvm for GRUB, and /etc/lilo.conf.b4vxvm for LILO.

Warning: When modifying the /etc/fstab and the boot loader configuration files, take care not to corrupt the entries that have been added by VxVM. This can prevent your system from booting correctly.

To mirror the root disk onto another disk after encapsulation

Choose a disk that is at least as large as the existing root disk, whose geometry is seen by Linux to be the same as the existing root disk, and which is not already in use by VxVM or any other subsystem (such as a mounted partition or swap area).
Select menu item 6 (Mirror Volumes on a Disk) from the vxdiskadm main menu, or use the VEA to create a mirror of the root disk. (These automatically invoke the vxrootmir command if the mirroring operation is performed on the root disk.)

The disk that is used for the root mirror must not be under Volume Manager control already.

Alternatively, to mirror all file systems on the root disk, run the following command:

# /etc/vx/bin/vxrootmir mirror_da_name mirror_dm_name

mirror_da_name is the disk access name of the disk that is to mirror the root disk, and mirror_dm_name is the disk media name that you want to assign to the mirror disk. The alternate root disk is configured to allow the system to be booted from it in the event that the primary root disk fails. For example, to mirror the root disk, sda, onto disk sdb, and give this the disk name rootmir, you would use the following command:

# /etc/vx/bin/vxrootmir sdb rootmir

The operations to set up the root disk mirror take some time to complete.

The following is example output from the vxprint command after the root disk has been encapsulated and its mirror has been created (the TUTIL0 and PUTIL0 fields and the subdisk records are omitted for clarity):

Disk group: rootdg

TY NAME ASSOC KSTATE LENGTH PLOFFS STATE ...

dg rootdg rootdg - - - -

dm rootdisk sda - 16450497 - -

dm rootmir sdb - 16450497 - -

v rootvol root ENABLED 12337857 - ACTIVE

pl mirrootvol-01 rootvol ENABLED 12337857 - ACTIVE

pl rootvol-01 rootvol ENABLED 12337857 - ACTIVE

v swapvol swap ENABLED 4112640 - ACTIVE

pl mirswapvol-01 swapvol ENABLED 4112640 - ACTIVE

pl swapvol-01 swapvol ENABLED 4112640 - ACTIVE

Allocation of METADATA Subdisks During Root Disk Encapsulation

METADATA subdisks are created during root disk encapsulation to protect partitioning information. These subdisks are deleted automatically when a root disk is unencapsulated.

The following example fdisk output shows the original partition table for a system's root disk:

# fdisk -ul /dev/hda

Disk /dev/hda: 255 heads, 63 sectors, 2431 cylinders

Units = sectors of 1 * 512 bytes

Device Boot Start End Blocks Id System

/dev/hda1 63 2104514 1052226 83 Linux

/dev/hda2 2104515 6297479 2096482+ 83 Linux

/dev/hda3 6329610 39054014 16362202+ 5 Extended

/dev/hda5 6329673 10522574 2096451 83 Linux

/dev/hda6 10522638 14715539 2096451 83 Linux

/dev/hda7 14715603 18908504 2096451 83 Linux

/dev/hda8 18908568 23101469 2096451 83 Linux

/dev/hda9 23101533 25205984 1052226 82 Linux swap

Notice that there is a gap between start of the extended partition (hda3) and the start of the first logical partition (hda5). For the logical partitions (hda5 through hda9), there are also gaps between the end of one logical partition and the start of the next logical partition. These gaps contain metadata for partition information. Because these metadata regions lie inside the public region, VxVM allocates subdisks over them to prevent accidental allocation of this space to volumes.

After the root disk has been encapsulated, the output from the vxprint command appears similar to this:

Disk group: rootdg

TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0

dg rootdg rootdg - - - - - -

dm disk01 sdh - 17765181 - - - -

dm rootdisk hda - 39053952 - - - -

sd meta-rootdisk05 - ENABLED 63 - - - METADATA

sd meta-rootdisk06 - ENABLED 63 - - - METADATA

sd meta-rootdisk07 - ENABLED 63 - - - METADATA

sd meta-rootdisk08 - ENABLED 63 - - - METADATA

sd meta-rootdisk09 - ENABLED 63 - - - METADATA

sd meta-rootdisk10 - ENABLED 63 - - - METADATA

sd rootdiskPriv - ENABLED 2049 - - - PRIVATE

v bootvol fsgen ENABLED 2104452 - ACTIVE - -

pl bootvol-01 bootvol ENABLED 2104452 - ACTIVE - -

sd rootdisk-07 bootvol-01 ENABLED 2104452 0 - - -

v homevol fsgen ENABLED 4192902 - ACTIVE - -

pl homevol-01 homevol ENABLED 4192902 - ACTIVE - -

sd rootdisk-05 homevol-01 ENABLED 4192902 0 - - -

v optvol fsgen ENABLED 4192902 - ACTIVE - -

pl optvol-01 optvol ENABLED 4192902 - ACTIVE - -

sd rootdisk-04 optvol-01 ENABLED 4192902 0 - - -

v rootvol root ENABLED 4192902 - ACTIVE - -

pl rootvol-01 rootvol ENABLED 4192902 - ACTIVE - -

sd rootdisk-02 rootvol-01 ENABLED 4192902 0 - - -

v swapvol swap ENABLED 2104452 - ACTIVE - -

pl swapvol-01 swapvol ENABLED 2104452 - ACTIVE - -

sd rootdisk-01 swapvol-01 ENABLED 2104452 0 - - -

v usrvol fsgen ENABLED 4192965 - ACTIVE - -

pl usrvol-01 usrvol ENABLED 4192965 - ACTIVE - -

sd rootdisk-06 usrvol-01 ENABLED 4192965 0 - - -

v varvol fsgen ENABLED 4192902 - ACTIVE - -

pl varvol-01 varvol ENABLED 4192902 - ACTIVE - -

sd rootdisk-03 varvol-01 ENABLED 4192902 0 - - -

The new partition table for the root disk appears similar to the following: