- Introduction
- Hardware Configuration
- System Disk Partitioning
- Two-Disk Configuration
- Three-Disk Configuration
- Four-Disk Configuration
- Comparison of Solaris Volume Manager Software and VERITAS Volume Manager
- Runbook for Creating the Solaris Volume Manager Software State Database
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Comparison of Solaris Volume Manager Software and VERITAS Volume Manager
VERITAS Volume Manager (VxVM) software is widely used for logical volume management on systems with large amounts of data. One of the main reasons is its flexibility. Until the introduction of soft partitioning in the Solaris 9 Operating Environment, the logical volumes of Solaris Volume Manager software were based on partitions. Changing a Solaris Volume Manager software configuration involved the use of the format utility, a primitive command line tool where a fatal mistake was never far away. VxVM software replaces partitions with subdisks, which are unlimited in number, internally managed, and automatically allocated.
Despite the popularity of VxVM software, we strongly discourage its use on the system disk. VERITAS volumes do not, by default, correspond to partitions. In the situation, irrespective of the cause, where the system no longer boots, the system administrator must be able to gain access to the file systems on the system disk without the drivers of the volume management software. This is guaranteed to be possible when each volume corresponds to a partition in the volume table of contents (VTOC) of the system disk. You can then use the fsck command and mount the partition while booted from a CD, boot server, or contingency disk, without dependency on the logical volume configuration database.
Moreover, Solaris Volume Manager drivers are integrated in the Solaris 9 Operating Environment. Therefore, Solaris Volume Manager volumes can be accessed even when booted from CD-ROM. This eliminates the need of breaking off a mirror during upgrades, thus reducing downtime and complexity of such an operation.
Solaris Volume Manager software preserves the correspondence between the volumes defined in its state database, and the disk partitions defined in the disk label (VTOC), at all times; disaster recovery is always possible by a standard method, without extra complications.
VxVM software also preserves partition information, but not under all circumstances. Examples of how partition information in the VTOC breaks with VxVM software include:
It is easy to grow /var using the VxVM graphical tool. This can be done by anyone at any time, to solve a disk space problem. However, this breaks the volume-partition relation as the /var volume is now a concatenation of two (not necessarily contiguous) subdisks.
When a disk breaks, the replacement disk is initialized. Slices 3 and 4 become the VxVM private and public region, and subdisks are allocated to be mirrored with the surviving disk. Partitions may be created by VxVM software for these n subdisks, but not necessarily in the same VTOC slots. At that point there may be a partition for the file system, but nobody knows where (the vfstab file that was saved before encapsulation is incorrect).
Shrinking the swap device to create, for example, to /opt, produces a volume without corresponding partition in the VTOC of the system disk.
The system administrator can, in each of the preceding circumstances, take actions to preserve the correspondence between VERITAS volumes and disk partitions. However, this is not the default behavior and requires specific procedures and commands, as well as a better than average understanding of the behavior of VxVM software. We recommend reading the Sun BluePrints book "Boot Disk Management — A Guide for the Solaris Operating Environment" by John S. Howard and David Deeths for more information about this topic.
There are two drawbacks to using Solaris Volume Manager software in combination with VxVM software:
First, using Solaris Volume Manager software and VxVM software on the same system has a cost: VxVM software requires a mandatory disk group, rootdg, which should not be used to contain data (a basic best practice of VxVM software). If the system disk is mirrored with VxVM software, rootdg is automatically populated with the system disk and its mirror. If the system disk is mirrored with Solaris Volume Manager software, two other disks must be put in rootdg. Since rootdg may not survive certain problems with VxVM software, these disks should only contain volatile data (like swap space or a scratch file system, analogous to /tmp). If there is no need for this, these two disks are an extra cost.
Second, Solaris Volume Manager software requires that a majority of the state databases be found at boot time (the quorum rule). When all data disks are under VxVM software, only two disks may be left under Solaris Volume Manager software. If one of these disks breaks, there is no state database quorum and the system will not boot without manual intervention. The intervention consists of removing the inaccessible state database copies (using the metadb -d command) and rebooting.
For this reason, and only in the two-disk configuration, we recommend that you disable the quorum rule in /etc/system. The system will then boot unattended, even with one disk. The following section describes this feature.