Migrate an entire volume group

From the earliest days of AIX, the LVM has made management of disks, logical volumes, and file systems easy. The LVM lets you group disks together into volume groups. You can slice off an entire volume group from an AIX system with the exportvg command. When you export the volume group, you effectively package all its logical volumes and file systems along with the directories and files in them. You can then remove the disks from the source system and assign them to the target.

On the target LPAR, you do the reverse by importing the volume group with the importvg command. This also makes the volume group active and updates the new LPAR with details of file systems associated with the logical volumes. You can then do an integrity check of those file systems before you mount them ready for use.

In short, there are three steps to moving a volume group:

1. Remove the volume group and its disks from the source LPAR.
2. Reassign the disks to the target LPAR.
3. Configure the disks, volume group, and file systems on the target LPAR.

This article focuses on steps 1 and 3, which address the AIX-specific procedures at the LVM level. The reassignment of the disks (step 2) varies, depending on your storage configuration.

Back to top

The fine print

Before getting into the detail of the commands to run, there are some hints and warnings that are worth keeping in mind.

What are disks?

The disks that belong to a volume group are what AIX knows as physical volumes. But they may not be dedicated physical disks. The physical volumes may be SAN logical unit numbers (LUNs) or file-backed devices presented via the Virtual I/O Server. Whatever sort of disks they are, you need to make them available to the target LPAR before you can do the import of the volume group.

The whole volume group gets moved

When you export a volume group, the whole volume group becomes unavailable until it is imported again. This means the volume group to be exported can only contain data you don't need to keep on the original LPAR.

Migrating between sites

The procedure outlined here works between two LPARs on the same physical server. It works just as well if the disks are being assigned to a different server. You could export a volume group, use SAN replication to copy the data to a server on a remote site, and then import the volume group. You can even use the AIX LVM to migrate to a completely new SAN storage subsystem (see Resources).

Helpful commands

The AIX commands used are shown below in Table 1. Check the AIX command documentation for the syntax for these commands (see Resources).

Back to top

Move or copy?

One benefit of using the volume group export and import procedure is that it allows you to move data rather than copy it. That saves you having to allocate additional storage to hold a copy of your data. It also saves you time. If you have a large amount of data or many thousands of files to move, the time saving can be significant.

But maybe you do want to create a spare volume group on the source LPAR and create a file system and copy data to it. You could then export your spare volume group so you can make it available on the target LPAR.

If you choose to do that, consider turning off JFS logging on your new file system before you start copying to it.

Improve performance with JFS2 NOLOG

You can speed up writes to a file system by mounting it with the NOLOG option. This feature of the IBM enhanced journaled file system (JFS2) was introduced with AIX V6.1. The NOLOG option is only intended for data you can easily copy or restore again or for temporary file systems with data that is not important or is easy to reproduce.

To mount a JFS2 file system without logging, use:

# mount -o log=NULL /mountpoint

Writes to this file system should be faster because journaling does incur a small performance penalty.

When the file system contains all the data it requires, you can export the volume group from the source LPAR and import it on the target. You should then mount the file system on the target LPAR using the normal JFS logging (without using the NOLOG option).

For more information about turning off JFS2 logging, see Resources.

Back to top

Remove a volume group from the source LPAR

When you have your data ready to move, remove the volume group and its physical volumes from the source LPAR. To do that, the logical volumes belonging to that volume group must be closed. That requires you to unmount the file systems that belong to the volume group you are going to export.

List file systems in the volume group

To identify the file systems belonging to a volume group, use the lsvgfs command:

# lsvgfs sparevg

# /scratch

Unmount file systems

Unmount any file systems in the volume group using the umount command:

# umount /scratch

You also need to deactivate any paging spaces and de-configure any system dump devices that belong to the volume group (see Resources for details).

When the logical volumes are closed, you should be able to deactivate the volume group.

Deactivate the volume group

You can make the volume group inactive with the varyoffvg command:

# varyoffvg sparevg

You can check the volume group status by listing physical volumes with lspv. This shows the volume group name. The volume group status is no longer listed as active.

# lspv
# hdisk0          00cb07a4cee0b389                    rootvg          active
# hdisk1          00cb07a42fb87e1d                    sparevg

Export the volume group

You should now be able to export the volume group using exportvg:

# exportvg sparevg

After you run exportvg, lspv displays the volume group as None:

# lspv
# hdisk0          00cb07a4cee0b389                    rootvg          active
# hdisk1          00cb07a42fb87e1d                    None

You could import the volume group again on the source LPAR using importvg. However, because you're planning to move it to another LPAR, you need to remove the references to the disks from the operating system on the source LPAR.

Remove the physical volumes from the ODM

The ODM still keeps a record of the physical volumes at the operating system level. It is now safe to delete the physical volumes belonging to the volume group using rmdev. This removes references to the disks on the source LPAR, but it doesn't affect the data on the disks.

Volume group descriptor area and volume group status area

Each of the disks in the volume group has management data, including a volume group descriptor area and a volume group status area. This management data is stored on each physical volume of the volume group. When you remove the disks from the ODM, the disk management data remains intact.

# rmdev -d -l hdisk1
# hdisk1 deleted

Back to top

Assign storage to target LPAR

The next step is to assign the storage to the target LPAR. How you do this depends on your storage configuration. Whoever is responsible for your storage subsystem should be able to present the disks to the new LPAR.

Back to top

Import data on target LPAR

After you assign the disks to the target LPAR, you need to identify them at the operating system level and then make the volume group and file systems available.

Identify new disks on target LPAR

The new disks need to be discovered on the operating system of the target LPAR. A reboot of the LPAR would do this, but that's not necessary. You can run cfgmgr to configure the new devices:

# cfgmgr

The lspv command should show these disks with their Physical Volume Identifier (PVID). The volume group is shown as None, and the volume group status doesn't display as active.

# lspv
# hdisk0          00cb07a4b24eb714                    rootvg          active
# hdisk1          00cb07a42fb87e1d                    None

The disk name on the target LPAR (hdiskN) may not be the same name as the source LPAR. However, the PVID should be the same on the source and the target because it is a unique identifier for each physical volume.

Import the volume group on the target LPAR

Use the importvg command and a PhysicalVolume parameter to import the volume group. You only need to specify one physical volume, even if there are several physical volumes in the volume group. The importvg command finds any remaining physical volumes belonging to the same volume group and includes them in the import.

# importvg -y sparevg hdisk1

The system automatically runs the varyonvg command to activate the volume group after it is imported. If the volume group is concurrent capable, you will be prompted by the importvg command to activate the imported volume group manually using varyonvg.

Updating file systems

If the volume group has file systems in it, the /etc/filesystems file is updated with information for the imported volume group's logical volumes and mount points. This saves you rebuilding the logical volumes and file systems yourself, as you would need to do before running a traditional restore or copy operation. The logical volume and file system characteristics are also inherited.

Before mounting the file systems, you need to verify their integrity.

Run fsck on all file systems

You should check the file system consistency for each file system. You can do this with the fsck command:

# fsck /scratch

Mount the file systems on target LPAR

You are now ready to mount the file systems, check permissions, and verify the file system contents. Once again, you can list all the file systems belonging to the volume group with lsvgfs. The mount command makes the file system available, along with all of its contents.

# mount /scratch

You can check the mounted file systems using df. Be sure to check the permissions on the mount points, directories, and files.

Back to top

Summary

The AIX LVM provides a simple way of moving large amounts of data from one LPAR to another. It can reduce or even eliminate system downtime when you want to do data migration.

You can use the volume group export and import to refresh a database or to perform a disaster recovery test. It has plenty of uses when you need to move data quickly without requiring additional disk or making unnecessary demands on your backup infrastructure.

Resources

Learn

• For a comprehensive treatment of how to migrate AIX systems from old to new SAN storage subsystems, see "Using the AIX Logical Volume Manager to perform SAN storage migrations" (developerWorks, July 2010).
  
  
• The IBM Technote T1012643 explains how to mount a JFS2 file system without using a file system log device. If you decide to back up your data to a volume group before moving it, the NOLOG option can improve performance significantly.
  
  
• For details on command syntax and flags, see the AIX 7.1 Commands documentation.
  
  
• Get an overview of logical volume storage concepts.
  
  
• The AIX 7.1 Information Center provides documentation about how to configure, add, or remove paging space.
  
  
• Learn how to change a system dump device.
  
  
• Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
  
  
• Attend a developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
  
  
• Follow developerWorks on Twitter.
  
  
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
  
  

Get products and technologies

• Try out IBM software. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.
  
  

Discuss

• Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
  
  

About the author

Anthony English is an independent contractor from Sydney, Australia. He has worked on AIX systems since 1991 and writes the IBM developerWorks blog, AIX Down Under. You can reach Anthony at anthonyenglish@levitar.com.au.

Rate this article

Comments

Back to top

Table of contents

• Migrate an entire volume group
• The fine print
• Move or copy?
• Remove a volume group from the source LPAR
• Assign storage to target LPAR
• Import data on target LPAR
• Summary
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into AIX and UNIX on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers