Converting LVM Volume Groups to VxVM Disk Groups

This section outlines the process for converting LVM volume groups to VxVM disk groups.




	NOTE: It is recommended that you read through this section carefully before beginning any volume group conversion.

The conversion process involves many steps. Though there are tools to help you with the conversion, some of these steps cannot be automated. You should be sure to understand how the whole conversion process works, and what you will need to do in the process before beginning a volume group conversion.

The tool used for conversion is vxvmconvert. This interactive, menu-driven program walks you through many of the steps of the process of converting volume groups for use by VxVM. Using vxvmconvert can reduce the downtime associated with converting from LVM to VxVM. Without the vxvmconvert tool, the only possible method of conversion would be to take full backups of user data, destroy the existing LVM configuration leaving only raw disks, recreate the configuration in VxVM, and then reload the user data.

The vxvmconvert process converts LVM volume groups to VxVM disk groups in place. In reality, the utility changes disks within LVM volume groups to VxVM disks by taking over the areas of the disks used for LVM configuration information, and creating the equivalent VxVM volume configuration information. User data, the portions of the disks used for file systems, databases, etc., are not affected by the conversion.

The act of conversion changes the names by which your system refers to the logical storage. For this reason, the conversion process is necessarily an off-line one. There can be no application access to user data in the volume groups undergoing conversion. Access to the LVM configuration itself (the metadata of LVM) must also be limited to the conversion process.

Volume Group Conversion Limitations

There are certain LVM volume configurations that cannot be converted to VxVM. Some of the reasons a conversion could fail are:

A volume group with insufficient space for metadata.
In the conversion of LVM to VxVM, the areas of the disks used to store LVM metadata are overwritten with VxVM metadata. If the VxVM metadata that needs to be written will not fit the space occupied by the LVM metadata, the group containing the disk cannot be converted. If you have just enough space for the conversion, you probably would want to have more space for future configuration changes.
A volume group containing the root volume.
vxvmconvert does not convert any volume group that contains a rootable volume, identified by the presence of the LIF area as created by mkboot(1M). Not only is the current root volume off limits, but any volume that might be used as an alternate root volume is rejected as well.
A volume group containing mirrors using the Mirror Write Cache feature for volume consistency recovery.
Users should be aware that when converting mirrored LVM volumes to VxVM, some of these volumes will likely have the Mirror Write Cache consistency recovery method in force on the volume. The vxvmconvert utility can convert these volumes, but must use the Dirty Region Logging (DRL) feature to obtain the same level of functionality. However, since Dirty Region Logging requires some user space to be available for the log, a conversion could fail due to an MWC volume being full, leaving no space for the DRL log. Note that the MWC and DRL are used only when the system crashes or is improperly shut down, to quickly bring all mirrors in the volume back into a consistent state.
A volume group containing the /usr file system.
For this release a volume group containing the /usr file system cannot be converted, because vxvmconvert needs access to files in /usr.
Volume groups with any dump or primary swap volumes.
vxvmconvert will not convert any volume group with dump or primary swap volumes. These are volumes known to the boot process. However, swap volumes on volumes other than the root volume can be converted (as long as this volume is not in the same volume group as the root volume).
Volume group disks used in MC/ServiceGuard clusters.
The conversion process does not support conversion of any volume group that is marked as a member of a MC/ServiceGuard or OPS Edition high availability cluster. The volume group must be deactivated and removed from membership in the high availability cluster before it can be converted.
Volume groups used for cluster lock disks.
The conversion process does not support conversion of a volume group that contains a disk that is being used for a cluster lock disk for an MC/ServiceGuard cluster.
Volume groups with any disks that have bad blocks in the bad block directory.
Unlike LVM, VxVM does not support bad block revectoring at the physical volume level. If there appear to be any valid bad blocks in the bad block directory of any disk used in an LVM volume group, the group cannot be converted. See Appendix A “Conversion Error Messages” for actions to take in this situation.
Not enough disk space on the root file system to save a copy of each physical disk's LVM metadata.
For large volume groups, for example, 200 GB, using approximately twenty 9GB drives, the space needed could be as much as 30 MB.
Volume groups with mirrored volumes.
A conversion fails if the LVM volume group being converted has mirrored volumes, but the system does not have a valid license installed that enables mirroring for VxVM.

The analyze option in vxvmconvert, which is described in later sections, aids you in identifying which volume groups can be converted.

Conversion Process Summary

Several steps are used to convert LVM volume groups to VxVM disk groups. Most of these steps can be done with the vxvmconvert utility. All the steps are not compulsory, and some may have to be followed only if there are problems during conversion. Some of them (e.g. backing up user data) are left to you to accomplish through your regular administrative processes.

The steps in the conversion process are:

Identifying LVM volume groups for conversion.
Analyzing an LVM group to see if conversion is possible.
Taking actions to make conversion possible if analysis fails.
Backing up your LVM configuration and user data.
Planning for new VxVM logical volume names.
Stopping application access to volumes in the volume group to be converted.
Converting a volume group.
Taking actions if conversion fails.
Implementing changes for new VxVM logical volume names
Restarting applications on the new VxVM volumes.
Tailoring your VxVM configuration.

These steps are described in detail in later sections of this chapter. Annotated examples on how to use vxvmconvert are shown in “Examples”. For information on restoring back to your original LVM configuration refer to “Restoring the LVM Volume Group Configuration”.

Conversion Steps Explained

1. Identifying LVM disks and volume groups for conversion

The obvious first step in the conversion process is to identify what you want to convert. The native LVM administrative utilities like vgdisplay and SAM can help you identify candidate LVM volume groups as well as the disks that comprise them.

You can also use the vxvmconvert and vxdisk commands to examine groups and their member disks. The information presented through the vxvmconvert and vxdisk utilities and their interpretation is shown in “Examples”.

You can also list the LVM disks with the following VxVM command:

# vxdisk list

2. Analyzing an LVM volume group to see if conversion is possible

After you have selected a volume group for conversion, you need to analyze it to determine if conversion for VxVM use is possible.

Use the analyze option of vxvmconvert to check for problems that would prevent the conversion from completing successfully. This option checks for all the conditions listed in “Volume Group Conversion Limitations”.

The analysis calculates the space required to add the volume group disks to a VxVM disk group, and to replace any existing disks and volumes with VxVM volumes, plexes, and subdisks. If you don't have the required space to convert the disks, the conversion would fail.

Analysis can be run on a live system while users are accessing their data. To analyze LVM volume groups, choose option 1 of the vxvmconvert utility.




	NOTE: The analysis option is presented as a separate menu item in `vxvmconvert`, but there is an implicit analysis with any conversion. If you simply select the "Convert LVM Volume Groups to VxVM" menu option, `vxvmconvert` will go through analysis on any group you specify. When you are using the convert option directly, you are given a chance to abort the conversion after analysis, and before any changes are committed to disk. For more information, see “Converting LVM Volume Groups to VxVM Disk Groups”. The analysis option is useful when you have a large number of groups/disks for conversion and some amount of planning is needed before the actual conversion. Installations with many users or critical applications can use the analyze option on a running system. Then conversion downtime can be better planned and managed. Smaller configurations may be better served by using the convert option directly while in a downtime period.

Sample examples of the analyze option are shown in “Examples”.

3. Taking actions to make conversion possible if analysis fails

Analysis may fail for any of the reasons listed in the section “Volume Group Conversion Limitations”".

Messages from vxvmconvert will explain the type of failure and any actions that can be taken before retrying the analysis. Refer to Appendix A “Conversion Error Messages” for complete details of specific error messages and actions.

4. Backing up your LVM configuration and user data

After analysis you know which volume group or groups you want to convert to VxVM disk groups. Up to this point, you have not altered your LVM configuration.

By taking the next step (completing the conversion to VxVM), you are significantly changing access to your storage.

Although the conversion process does not move, or in any other way affect user data, you are strongly encouraged to back up all data on the affected disks. Similarly, you should back up the LVM configuration itself.

During a conversion, any spurious reboots, power outages, hardware errors or operating system bugs can have unpredictable and undesirable consequences. You are advised to be on guard against disaster with a set of verified backups.

Backing up an LVM configuration

Use the vgcfgbackup(1M) utility before running vxvmconvert to save a copy of the LVM configuration.

You can back up the LVM volumes using the following command:

# vgcfgbackup -f pathname/filename vol_grp_name

Be sure to use the -f option to save the data into a file other than the default. vxvmconvert uses LVM utilities which themselves save the configuration using vgcfgbackup. If you do not use the -f option when you attempt to backup the configuration, the conversion process will overwrite your attempted backup.

A copy of this LVM configuration should be kept off-line on tape or some other medium for use in the event of a disaster during conversion.

For example, to put a copy on tape, use the following command:

# tar cvf /dev/rmt/c3t0d0BEST /vgbackups/vg08




	NOTE: The `vxvmconvert` utility itself also saves a snapshot of the LVM metadata in the process of conversion for each disk. This data is saved in a different format from that of `vgcfgbackup`. It can only be used via the `vxvmconvert` program. With certain limitations, you can reinstate the LVM volumes after they have been converted to VxVM using this data. (See section “Example: displaying the `vxvmconvert` menu”.) Even though `vxvmconvert` provides this level of backup of the LVM configuration, you are advised to use `vgcfgbackup` before running `vxvmconvert`.

Backing up user data

To back up user data, use your regular backup processes.




	CAUTION: Before you do the backup, you should carefully review "step “9. Implementing changes for new VxVM logical volume names”." Backup processes and systems themselves may have dependencies on the volume names currently in use on your system. The conversion to VxVM changes those names. You are advised to understand the implications name changes have for restoring from the backups you are about to make.

File system back up of user data

You can use the backup utility that you normally use to back up data on your logical volumes. For example, to back up logical volumes that contain file systems, the fbackup(1M) command can be used to back up the data to tape.

For example, to backup the data on /dev/vg01/lvol3 mounted on /foodir, use the following command:

# fbackup -0i /foodir -f /dev/rmt/c0t0d0BEST

Non-file system back up

If a logical volume you are converting does not contain a file system, and is being used directly by an application (such as a database application), use the backup facilities provided by the application. If no such facility exists, consider using the dd command.

5. Planning for new VxVM logical volume names

When you change from LVM volumes to VxVM volumes, the device names by which your system accesses data are changed. LVM creates device nodes for its logical volumes in /dev under directories named for the volume group. VxVM creates its device nodes in /dev/vx/dsk and /dev/vx/rdsk. When conversion is complete, the old LVM device nodes are gone from the system, and the system will access data on the device nodes in /dev/vx.

This change in names can present problems. Any application that refers to specific device node names will be at risk when these names change. Similarly, any files that record specific device node names for use by applications can be problematic.

The most obvious area where this problem arises is in /etc/fstab. To handle this problem, vxvmconvert will rewrite the fstab with the new VxVM names when conversion is done so that fsck, mount, and related utilities will behave as they did prior to the conversion.

There are potentially many other applications, though, that may be put at risk by the name changes in conversion. vxvmconvert cannot help with these. The system administrator must examine the mechanisms used in each of the following areas to see if they reference LVM device names:

Databases run on raw logical devices may record the name of that device node.
Backup systems may do device level backups based on device node names recorded in private files. Also labeling of the backups may record device names.
Scripts run by cron(1M).
Other administrative scripts.

A Workaround

vxvmconvert records a mapping between the names of the LVM device nodes and VxVM device nodes. This data can be used to create symbolic links from the old LVM volume to the new VxVM device names. The mapping is recorded in the file:

/etc/vx/reconfig.d/vgrecords/vol_grp_name/vol_grp_name.trans

This file provides information on how to proceed further to link the old LVM volume names to the new VxVM device names.




	CAUTION: This method of resolving the naming problem has risks. The symbolic links can become stale. For example, if a database refers to `/dev/vx/rdsk/vol1` through a symbolic link `/dev/vg00/rvol1(`"the old LVM name)", and if the underlying VxVM volume configuration is changed in any way, the database could refer to a missing or different volume.




	NOTE: You may want to use this symbolic link approach to ease the transition to VxVM. You can set up the symbolic links after the successful conversion to VxVM. Then, you can do the investigation on a case by case basis for each volume. Once you are satisfied that there are no problems introduced by the name change, the symbolic link to that volume can be removed. You must be careful to maintain a static VxVM volume configuration during this transition period.

Over time, the ultimate goal should be that the underlying VxVM naming is used by all applications, and that there are no indirect references to those volumes.

6. Stopping application access to volumes in the volume group to be converted

No applications can be active on the LVM volume group undergoing conversion. Before attempting to convert any volume group, you must ensure that applications using that group are down. This involves stopping databases, unmounting file systems, etc.




	NOTE: If you are converting a volume with swap space on it, the conversion requires a reboot. The swap space cannot be taken out of control of the operating system with a shutdown to single user mode.

As described in “Conversion and Reboot”, vxvmconvert tries to unmount mounted file systems during the conversion. Bear in mind though, that vxvmconvert makes no attempt to close down running applications on those file systems, nor does it attempt to deal with applications (e.g., databases) running on raw LVM volumes.




	NOTE: It is strongly recommended that you do not rely on `vxvmconvert`'s mechanisms for unmounting file systems. Conversion will be simpler if you close applications, and unmount file systems before running `vxvmconvert`.

To unmount a file system, use the following command:

# umount filesystem

Conversion and Reboot

During conversion, after the analysis phase is complete, the disks to be converted are deemed to be conversion ready. The vxvmconvert program asks if you are ready to commit to the conversion changes. If you choose to complete the conversion, the system will try to unmount all of the associated mounted file systems, stop and export the volume group, and then install the VxVM configuration.

If vxvmconvert is unable to stop and export volume groups or unmount file systems, the conversion cannot be completed without rebooting the system. You will have the option of aborting the conversion or completing the conversion by rebooting the system. If you choose to reboot, vxvmconvert will trigger the completion of the conversion automatically, during reboot, when it can be guaranteed that no processes have access to the volumes that are being converted.

If you choose to abort rather than reboot to complete the conversion, vxvmconvert will return to the main menu.




	NOTE: The LVM logical volumes to be converted must all be available to the `vxvmconvert` process. You should not deactivate the volume group or any logical volumes before running `vxvmconvert`.

To Activate a Volume Group

If you are not certain if the LVM volumes or the corresponding volume groups are active, you can activate them with the following command:

# vgchange -a y vol_grp_name

7. Converting a volume group

To do the actual conversion of LVM volume groups to VxVM disk groups, choose option 2 of the vxvmconvert utility.

vxvmconvert will prompt for a name for the VxVM disk group that will be created to replace the LVM volume group you are converting. This is the only object naming that is done through vxvmconvert. For details on modifying VxVM volume names, see "step “11. Tailoring your VxVM configuration”.

As described earlier in "step “2. Analyzing an LVM volume group to see if conversion is possible”," on page 12, the volume groups selected for conversion are analyzed to ensure that conversion is possible. After a successful analysis phase, vxvmconvert will ask you to commit to the change or abort the conversion. When you select to commit to conversion, the new VxVM metadata is written.




	NOTE: It is good practice to convert one volume group at a time to avoid errors during conversion.

The details of the conversion process are shown in “Examples”.

8. Taking actions if conversion fails

Conversion can fail for any of the reasons detailed in the “Volume Group Conversion Limitations”" section. Messages from vxvmconvert will explain the type of failure, and any actions you can take before retrying the conversion.

See Appendix A “Conversion Error Messages” for complete details of specific error messages.

9. Implementing changes for new VxVM logical volume names

You must be sure that all applications and configuration files refer properly to the new VxVM logical volumes. See step “5. Planning for new VxVM logical volume names” for details.

10. Restarting applications on the new VxVM volumes

Once the conversion to VxVM is complete, file systems can be mounted on the new devices and applications can be restarted.

If you unmounted file systems before running vxvmconvert, you need to remount them by the new volume names. vxvmconvert will have updated /etc/fstab with the new names. When you started vxvmconvert, you may have left file systems mounted that are associated with the volumes you converted. vxvmconvert remounts these with the new VxVM volume names.

11. Tailoring your VxVM configuration

vxvmconvert provides a default name for naming the newly formed VxVM disk group during conversion only as an option. However, you will be given the choice of choosing your own VxVM disk group name. By default, vxvmconvert renames the LVM volume group by replacing the prefix vg in the volume group name with the prefix dg. For example, vg08 would become dg08. If there is no vg in the LVM volume group name, vxvmconvert simply uses the same volume group name for its disk group.

The disks in the new VxVM disk group are given VxVM disk media names (see vxintro(1M)) based on this disk group name. If your new VxVM disk group is dg08, it will have VxVM disks with names like dg0801, dg0802, etc. The VxVM plexes within the logical volumes will be dg0801-01, dg0801-02, etc.

If you do not like the default object names generated by the conversion, use the standard VxVM utilities to rename these objects. See the rename option in the vxedit(1M) man page for more details on renaming the disk groups.




	NOTE: You must only rename objects in the VxVM configuration after you are fully satisfied with that configuration. In particular, you should never use menu option 3 of `vxvmconvert` (Roll back) after name changes. If you have chosen to set up symbolic links to the VxVM volumes as described in "step “5. Planning for new VxVM logical volume names” avoid renaming VxVM objects. These symbolic links are made invalid if the underlying VxVM device node name changes.