Moving and Reconfiguring Your Disks

Moving Disks Within a System

There a two procedures for moving the disks in a volume group to different hardware locations on a system. Choose a procedure depending on whether you use persistent or legacy device files for your physical volumes; the types of device files are described in “Legacy Device Files versus Persistent Device Files”.

LVM Configuration with Persistent Device Files

If your LVM configuration uses persistent device files, follow these steps:

LVM Configuration with Legacy Device Files

The names of legacy device files change when the hardware paths to their physical devices change. Therefore, you must update the LVM configuration by exporting and importing the volume group to use the new legacy device files. Follow these steps:

Moving Disks Between Systems

To move the disks in a volume group to different hardware locations on a different system, export the volume group from one system, physically move the disks to the other system, and import the volume group there. The procedures for exporting and importing a volume are described in “Exporting a Volume Group” and “Importing a Volume Group”. They are illustrated in the following example.

	NOTE: If the volume group contains any multipathed disks, see the note under “Importing a Volume Group”.

To move the three disks in the volume group /dev/vg_planning to another system, follow these steps:

Moving Data to a Different Physical Volume

You can use the pvmove command to move data contained in logical volumes from one disk to another disk or to move data between disks within a volume group.

For example, you can move the data from a specific logical volume from one disk to another, to use the vacated space on the first disk for another purpose. To move the data in logical volume /dev/vg01/markets from the disk /dev/disk/disk4 to the disk /dev/disk/disk7, enter the following:

On the other hand, you can move all the data contained on one disk, regardless of which logical volume it is associated with, to another disk within the same volume group. For example, do this to remove a disk from a volume group. You can use pvmove to move the data to other specified disks or let LVM move the data to appropriate available space within the volume group, subject to any mirroring allocation policies.

To move all data off disk /dev/dsk/disk3 and relocate it at the destination disk /dev/disk/disk5, enter the following command:

To move all data off disk /dev/disk/disk3 and let LVM transfer the data to available space within the volume group, enter the following command:

In each of the previous instances, if space does not exist on the destination disk, the pvmove command fails.

	NOTE: The pvmove command is not an atomic operation; it moves data extent by extent. If pvmove is abnormally terminated by a system crash or kill -9, the volume group can be left in an inconsistent configuration showing an additional pseudomirror copy for the extents being moved. You can remove the extra mirror copy using the lvreduce command with the –m option on each of the affected logical volumes; there is no need to specify a disk.

Creating a Spare Disk

	NOTE: Disk sparing requires the optional product HP MirrorDisk/UX. Version 2.x volume groups do not support disk sparing.

To configure a spare physical volume into a volume group for which you want protection against disk failure, follow these steps before a disk failure actually occurs:

For more information on disk sparing, see “Increasing Disk Redundancy Through Disk Sparing”.

Reinstating a Spare Disk

	NOTE: Disk sparing requires the optional product HP MirrorDisk/UX. Version 2.x volume groups do not support disk sparing.

After a failed disk has been repaired or a decision has been made to replace it, follow these steps to reinstate it and return the spare disk to its former standby status:

For more information on disk sparing, see “Increasing Disk Redundancy Through Disk Sparing”.

Modifying Physical Volume Characteristics

	NOTE: Version 2.x volume groups do not support bootable physical volumes.

The vgmodify command enables you to modify a volume group to adapt to changes in physical volumes. In particular, you can adjust the volume group to recognize size changes in physical volumes, and you can change a physical volume type between bootable and nonbootable.

Recognizing Size Changes

Disk arrays typically allow a LUN to be resized. If you increase the size of a LUN, follow these steps to incorporate the additional space into the volume group:

1. Increase the LUN size using the instructions for the array.

2. Run vgmodify to detect any physical volume size changes. It also reports whether all of the space can be made available to the volume group.

3. If vgmodify reports that the maximum number of physical extents per physical volume (max_pe) is too small to accommodate the new size, use vgmodify with the -t and -n options to determine a new value for max_pe, as described in “Modifying Volume Group Parameters”.

4. Review the values by running vgmodify with the new settings and the -r option.

5. Deactivate the volume group.

6. Commit any new value of max_pe and update the physical volume information by running vgmodify without the -r option.

7. Activate the volume group. To verify that the increased space is available, run the vgdisplay and pvdisplay commands.

	TIP: Starting with the September 2008 release of HP-UX 11i Version 3, you can use the –E and –a options to vgmodify to recognize and accommodate size changes without deactivating the volume group. For more information, see vgmodify(1M).

For example, to increase the size of the physical volume /dev/rdisk/disk6 from 4 GB to 100000000 KB, follow these steps:

1. Increase the LUN size using the instructions for the disk array.

2. Run vgmodify with the -v and -r options to check whether any disks have changed in size and whether all of the space on the physical volumes can be used.

   # vgmodify -v -r vg32 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1016 PE Size (Mbytes) 32 VGRA Size (Kbytes) 176 /dev/rdisk/disk6 Warning: Max_PE_per_PV for the volume group (1016) too small for this PV (3051). Using only 1016 PEs from this physical volume. "/dev/rdisk/disk6" size changed from 4194304 to 100000000kb An update to the Volume Group IS required New Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1016 PE Size (Mbytes) 32 VGRA Size (Kbytes) 176 Review complete. Volume group not modified

   The expanded physical volume requires 3051 physical extents to use all its space, but the current max_pe value limits this to 1016.

3. To determine the optimal values for max_pv and max_pe, run vgmodify -t, with and without the -n as follows:

   # vgmodify -t vg32 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1016 PE Size (Mbytes) 32 VGRA Size (Kbytes) 176 VGRA space (Kbytes) without PE renumbering 896 VGRA space (Kbytes) PE renumbering lower 32768 Volume Group optimized settings (no PEs renumbered): max_pv(-p) max_pe(-e) Disk size (Mb) 2 53756 1720193 3 35836 1146753 4 26876 860033 ... 28 3836 122753 30 3580 114561 32 3324 106369 35 3068 98177 38 2812 89985 ... 255 252 8065

   The table shows that without renumbering physical extents, a max_pv of 35 or lower permits a max_pe sufficient to accommodate the increased physical volume size.

   # vgmodify -v -t -n vg32 Volume Group configuration for /dev/vg32 has been saved in /etc/lvmconf/vg32.conf Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1016 PE Size (Mbytes) 32 VGRA Size (Kbytes) 176 VGRA space (Kbytes) on all Physical Volumes: PV current -n /dev/rdisk/disk6 896 32768 /dev/rdisk/disk5 896 32768 Summary 896 32768 Volume Group optimized settings (PEs renumbered lower): max_pv(-p) max_pe(-e) Disk size (Mb) 61 65535 2097152 62 65532 2097056 63 64252 2056096 ... 251 16124 516000 252 16048 513568 255 15868 507808

   The table shows that if physical extents are renumbered, all values of max_pv permit a max_pe large enough to accommodate the increased physical volume size.

   For this example, select a max_pv of 10, which permits a max_pe value of 10748.

4. Preview the changes by using the -r option to vgmodify as follows:

   # vgmodify -p 10 -e 10748 -r vg32 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1016 PE Size (Mbytes) 32 VGRA Size (Kbytes) 176 The current and new Volume Group parameters differ. "/dev/rdisk/disk6" size changed from 4194304 to 100000000kb An update to the Volume Group IS required New Volume Group settings: Max LV 255 Max PV 10 Max PE per PV 10748 PE Size (Mbytes) 32 VGRA Size (Kbytes) 896 Review complete. Volume group not modified

5. Deactivate the volume group as follows:

   # vgchange -a n vg32 Volume group "vg32" has been successfully changed.

6. Commit the new values as follows:

   # vgmodify -p 10 -e 10748 vg32 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1016 PE Size (Mbytes) 32 VGRA Size (Kbytes) 176 The current and new Volume Group parameters differ. "/dev/rdisk/disk6" size changed from 4194304 to 100000000kb An update to the Volume Group IS required New Volume Group settings: Max LV 255 Max PV 10 Max PE per PV 10748 PE Size (Mbytes) 32 VGRA Size (Kbytes) 896 New Volume Group configuration for "vg32" has been saved in "/etc/lvmconf/vg32.conf" Old Volume Group configuration for "vg32" has been saved in "/etc/lvmconf/vg32.conf.old" Starting the modification by writing to all Physical Volumes Applying the configuration to all Physical Volumes from "/etc/lvmconf/vg32.conf" Completed the modification process. New Volume Group configuration for "vg32" has been saved in "/etc/lvmconf/vg32.conf.old" Volume group "vg32" has been successfully changed.

7. Activate the volume group and verify the changes by entering the following commands:

   # vgchange -a y vg32 Activated volume group Volume group "vg32" has been successfully changed. # vgdisplay vg32 --- Volume groups --- VG Name /dev/vg32 VG Write Access read/write VG Status available Max LV 255 Cur LV 0 Open LV 0 Max PV 10 Cur PV 2 Act PV 2 Max PE per PV 10748 VGDA 4 PE Size (Mbytes) 32 Total PE 3119 Alloc PE 0 Free PE 3119 Total PVG 0 Total Spare PVs 0 Total Spare PVs in use 0 VG Version 1.0

	CAUTION: This procedure can also be used when the size of a physical volume is decreased. However, there are limitations: To avoid data corruption, the size of the LUN (in the disk array) must be reduced only after vgmodify has successfully changed the volume group. The volume group must be deactivated before attempting any reduction. If you reduce the size of the LUN while the volume group is activated, LVM marks the physical volume as unavailable. If the physical volume has any allocated physical extents beyond the target size, vgmodify prints an error message and exits without changing the physical volume. In this case, you must be prepared to restore the LUN to its original size (ensuring the same disk space is allocated).

Changing Physical Volume Boot Types

	NOTE: The vgmodify command does not support Version 2.x volume groups.

When a physical volume is initialized for LVM use, it can be made bootable or nonbootable. Bootable physical volumes require additional space in their LVM metadata for boot utilities and information. If a physical volume was accidentally initialized as bootable, you can convert the disk to a nonbootable disk and reclaim LVM metadata space.

	CAUTION: The boot volume group requires at least one bootable physical volume. Do not convert all of the physical volumes in the boot volume group to nonbootable, or your system will not boot.

To change a disk type from bootable to nonbootable, follow these steps:

1. Use vgcfgrestore to determine if the volume group contains any bootable disks.

2. Run vgmodify twice, once with the -B n and once without it. Compare the available values for max_pe and max_pv.

3. Choose new values for max_pe and max_pv. Review the values by running vgmodify with the new settings and the -r option.

4. Deactivate the volume group.

5. Commit the changes by running vgmodify without the -r option.

6. Activate the volume group. Run the vgcfgrestore or pvdisplay commands to verify that the disk type has changed.

For example, to convert any bootable disks in volume group vg, follow these steps:

1. Check if any physical volumes in vg01 are bootable as follows:

   # vgcfgrestore -l -v -n vg01 Volume Group Configuration information in "/etc/lvmconf/vg01.conf" VG Name /dev/vg01 ---- Physical volumes : 1 ---- PV Type Size (kb) Start (kb) PVkey c2t1d0 Bootable 35566480 2912 0 max_pv 16 max_pe 1085 max_lv 255

2. To determine which values of max_pe and max_pv are available, run the following command:

   # vgmodify -t -B n vg01 /dev/rdsk/c2t1d0 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1085 PE Size (Mbytes) 32 VGRA Size (Kbytes) 208 VGRA space (Kbytes) without PE renumbering 2784 VGRA space (Kbytes) PE renumbering lower 32768 Volume Group optimized settings (no PEs renumbered): max_pv(-p) max_pe(-e) Disk size (Mb) 5 65535 2097122 6 56828 1818498 ... 255 1276 40834

   Compare the values if the disk is made non-bootable, and if it is not. Enter the following command:

   # vgmodify -t vg01 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1085 PE Size (Mbytes) 32 VGRA Size (Kbytes) 208 VGRA space (Kbytes) without PE renumbering 768 VGRA space (Kbytes) PE renumbering lower 768 Volume Group optimized settings (no PEs renumbered): max_pv(-p) max_pe(-e) Disk size (Mb) 1 65535 2097120 2 45820 1466240 ... 255 252 8064

   If you change the disk type, the VGRA space available increases from 768 KB to 2784KB (if physical extents are not renumbered) or 32768 KB (if physical extents are renumbered). Changing the disk type also permits a larger range of max_pv and max_pe. For example, if max_pv is 255, the bootable disk can only accommodate a disk size of 8064 MB, but after conversion to nonbootable, it can accommodate a disk size of 40834 MB.

3. For this example, select a max_pv value of 6, which permits a max_pe value of 56828. Preview the changes by entering the following command:

   # vgmodify -r -p 6 -e 56828 -B n vg01 /dev/rdsk/c2t1d0 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1085 PE Size (Mbytes) 32 VGRA Size (Kbytes) 208 The current and new Volume Group parameters differ. An update to the Volume Group IS required New Volume Group settings: Current Volume Group settings: Max LV 255 Max PV 6 Max PE per PV 56828 PE Size (Mbytes) 32 VGRA Size (Kbytes) 2784 Review complete. Volume group not modified

4. Deactivate the volume group as follows:

   # vgchange -a n vg01 Volume group "vg01" has been successfully changed.

5. Commit the new values as follows:

   # vgmodify -p 6 -e 56828 -B n vg01 /dev/rdsk/c2t1d0 Current Volume Group settings: Max LV 255 Max PV 16 Max PE per PV 1085 PE Size (Mbytes) 32 VGRA Size (Kbytes) 208 The current and new Volume Group parameters differ. An update to the Volume Group IS required New Volume Group settings: Current Volume Group settings: Max LV 255 Max PV 6 Max PE per PV 56828 PE Size (Mbytes) 32 VGRA Size (Kbytes) 2784 New Volume Group configuration for "vg01" has been saved in "/etc/lvmconf/vg01.conf" Old Volume Group configuration for "vg01" has been saved in "/etc/lvmconf/vg01.conf.old" Starting the modification by writing to all Physical Volumes Applying the configuration to all Physical Volumes from "/etc/lvmconf/vg01.conf" Completed the modification process. New Volume Group configuration for "vg01" has been saved in "/etc/lvmconf/vg01.conf.old" Volume group "vg01" has been successfully changed.

6. Activate the volume group and verify the changes as follows:

   # vgchange -a y vg01 Activated volume group Volume group "vg01" has been successfully changed. # vgcfgbackup vg01 Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf # vgcfgrestore -l -v -n vg01 Volume Group Configuration information in "/etc/lvmconf/vg01.conf" VG Name /dev/vg01 ---- Physical volumes : 1 ---- PV Type Size (kb) Start (kb) PVkey c2t1d0 Non-Boot 35566480 2912 0 max_pv 6 max_pe 56828 max_lv 255

Disabling a Path to a Physical Volume

	IMPORTANT: This procedure only disables LVM's use of the link. The pvchange command does not prevent diagnostics or an application from accessing the physical volume. By default, the mass storage stack uses all the paths available to access a physical volume, independently of the paths configured in LVM. Disabling a path in LVM does not prevent the native multipathing from using that path. Use the scsimgr command to disable I/O along a path or to disable the native multipathing.

You can temporarily disable LVM's use of one or all of the physical paths to a physical volume using the pvchange command. Disabling a path, also known as detaching the link, causes LVM to close that path to the device and stop using it. This can be useful if you want to guarantee that a link is idle, such as when you are running diagnostics on an I/O card, replacing an I/O card, or replacing the disk containing the physical volume.

Detaching a link to a physical volume is a temporary operation, not a permanent one. If you want to permanently remove a link or physical volume from the volume group, use vgreduce instead, as described in “Removing a Disk from a Volume Group”.

To detach a link to a physical volume, use the -a option to pvchange. For example, to disable the link through the device /dev/disk/disk33, enter the following command:

If you are using LVM's alternate links for multipathed disks, each link uses a different legacy device files. In that situation, to detach all links to a physical volume, use N as the argument to the -a option:

Detaching one or more links to a physical volume does not necessarily cause LVM to stop using that physical volume entirely. If the detached link is the primary path to the device, LVM begins using any available alternate link to it. LVM stops using the physical volume only when all the links to it are detached.

If all the links to a device are detached, the associated physical volume becomes unavailable to the volume group. The links remain associated with the volume group but LVM does not send any I/O requests to the physical volume until it is reattached. This means that the data on that physical volume becomes temporarily unavailable; consequently, you must make sure that any availability requirements for that data can be satisfied by mirroring before you make the device unavailable by detaching it.

Detaching a link does not disable sparing. That is, if all links to a physical volume are detached and a suitable spare physical volume is available in the volume group, LVM uses it to reconstruct the detached disk. For more information on sparing, see “Increasing Disk Redundancy Through Disk Sparing”.

You can view the LVM status of all links to a physical volume using vgdisplay with the -v option.

Restoring a detached link to a physical volume, or reattaching it, makes that link available to the volume group. LVM can begin using that link as necessary to access the disk.

To reattach a specific path to a physical volume, use the pvchange command with the -a option. For example, enter the following command:

Because detaching a link to a physical volume is temporary, all detached links in a volume group are reattached when the volume group is activated, either at boot time or with an explicit vgchange command, such as the following:

Creating an Alternate Boot Disk

	NOTE: Version 2.x volume groups do not support bootable physical volumes. You cannot create an alternate boot disk in a Version 2.x volume group.

With non-LVM disks, a single root disk contains all the attributes needed for boot, system files, primary swap, and dump. Using LVM, a single root disk is replaced by a pool of disks, a root volume group, which contains all of the same elements but allowing a root logical volume, a boot logical volume, a swap logical volume, and one or more dump logical volumes. Each of these logical volumes must be contiguous, that is, contained on a single disk, and they must have bad block relocation disabled. (Other noncontiguous logical volumes can be used for user data.) For more information on the swap and dump devices and their configuration, see HP-UX System Administrator's Guide: Configuration Management.

The root logical volume contains the operating system software and the root file system (/).. The boot logical volume contains the boot file system (/stand). You can combine the root and boot logical volumes into a single logical volume or keep them separate. Whether you use a single combined root-boot logical volume, or separate root and boot logical volumes, the logical volume used to boot the system must be the first logical volume on its physical volume. It must begin at physical extent 0000 to boot the system in maintenance mode.

If you newly install your HP-UX system and choose the LVM configuration, a root volume group is automatically configured (/dev/vg00), as are separate root (/dev/vg00/lvol3) and boot (/dev/vg00/lvol1) logical volumes. If you currently have a combined root and boot logical volume and you want to reconfigure to separate them after creating the boot logical volume, use the lvlnboot command with the -b option to define the boot logical volume to the system, taking effect the next time the system is booted.

The swap logical volume is the system’s primary swap area and is typically used for dump. The swap logical volume is often on the same physical disk as the root logical volume. However, you can configure it (and the dump logical volumes) on a different physical disk than the root logical volume.

If you create your root volume group with multiple disks, use the lvextend command to place the boot, root, and primary swap logical volumes on the boot disk.

	TIP: You can use pvmove to move the data from an existing logical volume to another disk if necessary to make room for the root logical volume. For more information, see “Moving Data to a Different Physical Volume”.

To create a new root volume group with an alternate boot disk, follow these steps:

Mirroring the Boot Disk

	NOTE: Mirroring requires the optional product, HP MirrorDisk/UX. Version 2.x volume groups do not support boot disks, so you cannot mirror the boot disk in a Version 2.x volume group.

After you create mirror copies of the root, boot, and primary swap logical volumes, if any of the underlying physical volumes fail, the system can use the mirror copy on the other disk and continue. When the failed disk comes back online, it is automatically recovered, provided the system has not been rebooted.

If the system reboots before the disk is back online, reactivate the volume group to update the LVM data structures that track the disks within the volume group. You can use vgchange -a y even though the volume group is already active.

For example, you can reactivate volume group vg00 by entering the following command:

As a result, LVM scans and activates all available disks in the volume group vg00, including the disk that came online after the system rebooted.

The procedure for creating a mirror of the boot disk is different for HP 9000 and HP Integrity servers. HP Integrity servers use partitioned boot disks.

	NOTE: These examples include creating a mirror copy of the primary swap logical volume. The primary swap mirror does not need to be on a specific disk or at a specific location, but it must be allocated on contiguous disk space. The recommended mirror policy for primary swap is to have the mirror write cache and the mirror consistency recovery mechanisms disabled. When primary swap is mirrored and your primary swap device also serves as a dump area, be sure that mirror write cache and mirror consistency recovery are set to off at boot time to avoid losing your dump. To reset these options, reboot your system in maintenance mode and use the lvchange command with the -M n and -c n options.

Mirroring the Boot Disk on HP Integrity Servers

The procedure to mirror the root disk on Integrity servers is similar to the procedure for HP 9000 servers. The difference is that Integrity server boot disks are partitioned; you must set up the partitions, copy utilities to the EFI partition, and use the HP-UX partition device files for LVM commands.

Figure 3-1shows the disk layout of a boot disk. The disk contains a Master Boot Record (MBR) and EFI partition tables that point to each of the partitions. The idisk command creates the partitions (see idisk(1M)).

Figure 3-1 Sample LVM Disk Layout on an HP Integrity Server

For this example, the disk to be added is at hardware path 0/1/1/0.0x1.0x0, with device special files named /dev/disk/disk2 and /dev/rdisk/disk2. Follow these steps:

1. Partition the disk using the idisk command and a partition description file.

   1. Create a partition description file. For example:

      # vi /tmp/idf

      In this example, the partition description file contains the following information:

      3 EFI 500MB HPUX 100% HPSP 400MB

      The values in the example represent a boot disk with three partitions: an EFI partition, an HP-UX partition, and an HPSP. Boot disks of earlier HP Integrity servers might have an EFI partition of only 100 MB and might not contain the HPSP partition.

   2. Partition the disk using idisk and your partition description file as follows:

      # idisk -f /tmp/idf -w /dev/rdisk/disk2

   3. To verify that your partitions are correctly laid out, enter the following command:

      # idisk /dev/rdisk/disk2

2. Create the device files for all the partitions. For example:

   # insf -e -H 0/1/1/0.0x1.0x0

   The following device files now exist for this disk:

   /dev/[r]disk/disk2 (this refers to the entire disk) /dev/[r]disk/disk2_p1(this refers to the efi partition) /dev/[r]disk/disk2_p2(this will be the hp-ux partition) /dev/[r]disk/disk2_p3(this refers to the service partition)

3. Create a bootable physical volume using the device file denoting the HP-UX partition. For example:

   # pvcreate -B /dev/rdisk/disk2_p2

4. Add the physical volume to your existing root volume group as follows:

   # vgextend vg00 /dev/disk/disk2_p2

5. Place boot utilities in the boot area. Copy EFI utilities to the EFI partition, and use the device special file for the entire disk as follows:

   # mkboot -e -l /dev/rdisk/disk2

6. Add an autoboot file to the disk boot area as follows:

   # mkboot -a "hpux" /dev/rdisk/disk2

   	NOTE: If you expect to boot from this disk only when you lose quorum, you can use the alternate string hpux –lq to disable quorum checking. However, HP recommends configuring your root volume group to minimize quorum losses, by using at least three physical volumes and no single points of failure, as described in “Planning for Recovery”.

7. The logical volumes on the mirror boot disk must be extended in the same order that they are configured on the original boot disk. Determine the list of logical volumes in the root volume group and their order. For example:

   # pvdisplay -v /dev/disk/disk0_p2 | grep 'current.*0000 $' 00000 current /dev/vg00/lvol1 00000 00010 current /dev/vg00/lvol2 00000 00138 current /dev/vg00/lvol3 00000 00151 current /dev/vg00/lvol4 00000 00158 current /dev/vg00/lvol5 00000 00159 current /dev/vg00/lvol6 00000 00271 current /dev/vg00/lvol7 00000 00408 current /dev/vg00/lvol8 00000

8. Mirror each logical volume in vg00 (the root volume group) onto the specified physical volume. For example:

   # lvextend –m 1 /dev/vg00/lvol1 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol2 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol3 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol4 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol5 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol6 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol7 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait .... # lvextend –m 1 /dev/vg00/lvol8 /dev/disk/disk2_p2 The newly allocated mirrors are now being synchronized. This operation will take some time. Please wait ....

   	NOTE: If lvextend fails with following message: "m": illegal option HP MirrorDisk/UX is not installed.

   	TIP: To shorten the time required to synchronize the mirror copies, use the lvextend and lvsync command options introduced in the September 2007 release of HP-UX 11i Version 3. These options enable you to resynchronize logical volumes in parallel rather than serially. For example: # lvextend -s –m 1 /dev/vg00/lvol1 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol2 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol3 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol4 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol5 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol6 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol7 /dev/disk/disk2_p2 # lvextend -s –m 1 /dev/vg00/lvol8 /dev/disk/disk2_p2 # lvsync -T /dev/vg00/lvol*

9. Update the root volume group information as follows:

   # lvlnboot -R /dev/vg00

10. Verify that the mirrored disk is displayed as a boot disk and that the boot, root, and swap logical volumes appear to be on both disks as follows:

    # lvlnboot -v

11. Specify the mirror disk as the alternate boot path in nonvolatile memory as follows:

    # setboot –a 0/1/1/0.0x1.0x0

12. Add a line to /stand/bootconf for the new boot disk using vi or another text editor as follows:

    # vi /stand/bootconf l /dev/disk/disk2_p2

    Where the literal “l” (lower case L) represents LVM.