4. Spares, Hot Relocation, and Disk Reservation

You've probably seen by now that there are two different worlds in Veritas depending on whether you use VxAssist or VxMake. As you've seen, when you use VxAssist disks are just "magically" allocated the way you ask VxAssist to do so. Where do these disks come from? The spare pool. When initializing a disk you assign the disk to a disk group, and at that point it's made a member of the spare pool for the disk group. For the VxMake fan's out there, we'd simply say that it's not being used yet. When VxAssist preforms an operation that requires using a new disk it pulls a disk from the spare pool, creates a subdisk, and does what ever it needs to do. In some situations you might not want specific disks to just get freely yanked into service, maybe it had problems at some point, or you are saving it for something else. Whatever the reason, if you don't want to mark a disk "off limits" you can simply reserve it. This is done with vxedit. When you reserve a disk, your actually just marking a flag on the VM Disk. The syntax is:

vxedit set reserve=on <diskname>

To un-reserve it, the syntax would be:

vxedit set reserve=no <diskname>

Note that reserves can will be ignored if you assign it by name, as in the following example:

vxassist make vol01 500m disk03

Even if disk03 was reserved, it will be used.

Hot Relocation is also know as Hot Sparing. When a VM Disk is make a hot spare, it become a life raft for the disk group it is assigned to. If VxVM detects, or suspects a failure (or if a drive flat dies) the drive will be logically replaced with the hot spare.

And example, if you had a mirrored volume and one of the disks failed, normally you'd loose on of the mirrors (the plex would fail) and you'd have lost your redundancy, so if another disk failed on the other mirror (assuming you only had 2 mirrors) the volume would be lost. However, if you had a hot spare assigned to the disk group, when the disk failed, the hot spare would immediately take it's place and the mirror would re-sync. What does this do? Buy you time. This simply gives you more time to respond to the problem and replace the failed component. Note that there is no limit to the number of spares you can assigned to each disk group, but that hot spares will only relocate failed disks in it's diskgroup. Sparing is enabled by either answering "yes" the question "Is this disk a hot spare?" during disk initialization, or after it's initialized by using the syntax:

	
vxassist set spare=on <diskname>

Hot sparing can be disabled for a disk, by using:

vxassist set spare=off <diskname>

A handy side note, hot sparing also reserves the disk so it can not be used as a member of the spare disk pool. Often when I want to make disks "hands off", I'll make them hot spares instead of reserving them, at least then their being useful.