< Previous  | TOC | Index | Next  >

Restrictions on using rootability with Linux

Bootable root disks with msdos disk labels can contain up to four primary partitions: /dev/sdx1 through /dev/sdx4 for SCSI disks, and /dev/hdx1 through /dev/hdx4 for IDE disks. If more than four partitions are required, a primary partition can be configured as an extended partition that contains up to 11 logical partitions (/dev/sdx5 through/dev/sdx15) for SCSI disks and 12 logical partitions (/dev/hdx5 through/dev/sdx16) for IDE disks.

  Note   Extensible Firmware Interface (EFI) disks with GUID Partition Table (GPT) labels are not supported for root encapsulation.

To encapsulate a root disk, VxVM requires one unused primary partition entry to represent the public region, plus one unused primary partition or one unused logical partition for the private region.

The entry in the partition table for the public region does not require any additional space on the disk. Instead it is used to represent (or encapsulate) the disk space that is used by the existing partitions.

Unlike the public region, the partition for the private region requires a relatively small amount of disk space. By default, the space required for the private region is 32MB, which is rounded up to the nearest whole number of cylinders. On most modern disks, one cylinder is usually sufficient.

To summarize, the requirements for the partition layout of a root disk that can be encapsulated are:

• One unused primary partition entry for the public region.
• Free disk space or a swap partition, from which space can be allocated to the private region. If the free space or swap partition is not located within an extended partition, one unused primary partition entry is required for the private region. Otherwise, one unused logical partition entry is required.

The following error message is displayed by the vxencap or vxdiskadm commands if you attempt to encapsulate a root disk that does not have the required layout:

Cannot find appropriate partition layout to allocate space
for VxVM public/private partitions.

The following sections show examples of root disk layouts for which encapsulation is either supported or not supported:

• Sample supported root disk layouts for encapsulation
• Sample unsupported root disk layouts for encapsulation

Note the following additional important restrictions on using rootability with Linux:

• Root disk encapsulation is only supported for devices with standard SCSI or IDE interfaces. It is not supported for most devices with vendor-proprietary interfaces, except the COMPAQ SMART and SMARTII controllers, which use device names of the form /dev/ida/cXdXpX and /dev/cciss/cXdXpX.
• Root disk encapsulation is only supported for disks with msdos or gpt labels. It is not supported for disks with sun labels.
• The root, boot, and swap partitions must be on the same disk.
• Either the GRUB or the LILO boot loader must be used as the boot loader for SCSI and IDE disks.
• The menu entries in the boot loader configuration file must be valid.
• The boot loader configuration file must not be edited during the root encapsulation process.
• The /boot partition must be on the first disk as seen by the BIOS, and this partition must be a primary partition.
• The boot loader must be located in the master boot record (MBR) on the root disk or any root disk mirror.
• If the GRUB boot loader is used, the root device location of the /boot directory must be set to the first disk drive, sd0 or hd0, to allow encapsulation of the root disk.
• If the LILO or ELILO boot loader is used, do not use the FALLBACK, LOCK or -R options after encapsulating the root disk.
  Warning: Using the FALLBACK, LOCK or -R options with LILO may render your system unbootable because LILO does not understand the layout of VxVM volumes.
  
• Booting from an encapsulated root disk which is connected only to the secondary controller in an A/P (active/passive) array is not supported.
• The default Red Hat installation layout is not valid for implementing rootability. If you change the layout of your root disk, ensure that the root disk is still bootable before attempting to encapsulate it.

  See "Example 5" on page 115.

• Do not allocate volumes from the root disk after it has been encapsulated. Doing so may destroy partition information that is stored on the disk.