VERITAS Volume Manager 3.1 Administrator's Guide

Volume Manager Operations
Hot-Relocation
Chapter 3104
When a failure occurs, it triggers a hot-relocation attempt.
A successful hot-relocation process involves:
Step 1. Detecting Volume Manager events resulting from the failure of a disk,
plex, or RAID-5 subdisk.
Step 2. Notifying the system administrator (and other designated users) of the
failure and identifying the affected Volume Manager objects. This is done
through electronic mail.
Step 3. Determining which subdisks can be relocated, finding space for those
subdisks in the disk group, and relocating the subdisks. Notifying the
system administrator of these actions and their success or failure.
Step 4. Initiating any recovery procedures necessary to restore the volumes and
data. Notifying the system administrator of the outcome of the recovery
attempt.
NOTE Hot-relocation does not guarantee the same layout of data or the same
performance after relocation. The system administrator may make some
configuration changes after hot-relocation occurs.
How Space is Chosen for Relocation
A spare disk must be initialized and placed in a disk group as a spare
before it can be used for replacement purposes. If no disks have been
designated as spares when a failure occurs, Volume Manager
automatically uses any available free space in the disk group in which
the failure occurs. If there is not enough spare disk space, a combination
of spare space and free space is used.
The free space mentioned in hot-relocation is always the free space not
excluded from hot-relocation use. Disks can be excluded from
hot-relocation use by using the Storage Administrator interface:
vxdiskadm or vxedit.
The system administrator can designate one or more disks as
hot-relocation spares within each disk group. Disks can be designated as
spares by using the Storage Administrator interface, vxdiskadm, or
vxedit. Disks designated as spares do not participate in the free space
model and should not have storage space allocated on them.