HP Serviceguard for Linux Version A.11.18 Deployment Guide, August 2008

lvcreate -L 280M -n lvol1 vgclog

mke2fs -j /dev/vgclog/lvol1

mkdir /clog

vgchange -a n vgclog

NOTE: The size specified in the lvcreate command, specified by the “-L” option, is related to the size

of the physical partition created on the storage device.

Backup the Volume Groups

The steps in this section should be performed on the same server where the partitions and volumes

were created.

1. Execute the vgcfgbackup command to backup the volume groups, for example:

vgcfgbackup /dev/vgws /dev/vgclog

Import and Configure the Volume Groups on the Second Server

At this point, you need to import the volume groups (e.g. vgws and vgclog) and create the mount

points on the second server.

NOTE: The Serviceguard for Linux documentation suggests using vgexport and vgimport to achieve

the same result, but the vgscan on the second server is sufficient.

The steps in this section should be performed on the second server.

1. First, run the “fdisk –l” command to verify that the external devices are visible on the second

server. For example, look for /dev/sda through /dev/sdf, and /dev/mapper/mpath2,

/dev/mapper/mpath3, and /dev/mapper/mpath4.

fdisk –l

NOTE: If you do not see these devices, test the connections and reboot the server.

2. Import the volume groups by running the vgscan command.

vgscan

Reading all physical volumes. This may take a while...

Found volume group "vgclog" using metadata type lvm2

Found volume group "vgws" using metadata type lvm2

NOTE: If the volume groups, vgws and vgclog are not found, reboot the server.

3. Create the mount points

mkdir /ws

mkdir /clog

4. Backup the volume group configurations

vgcfgbackup /dev/vgws /dev/vgclog

5. Deactivate the volume groups on this server

vgchange –a n vgws vgclog

Create alternate disk monitoring script

In this step, you will create a configuration script that will be used to monitor disk failures. This

alternate script is required to overcome the limitation that the device mapper names /dev/dm-N, as

described in the Serviceguard documentation, are not persistent. That is, if the LUN associated with

/dev/dm-3 failed, then /dev/dm-4 would be renamed to /dev/dm-3 on the following reboot of the

system.