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:

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.

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 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:

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:

Backing up user data

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

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:

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:

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

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.

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.

To unmount a file system, use the following command:

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.

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:

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," on .

As described earlier in "step 2. Analyzing an LVM volume group to see if conversion is possible," on , 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.

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 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 on " 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.