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:
- Remove the volume group and its disks from the source LPAR.
- Reassign the disks to the target LPAR.
- 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.
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).
Table 1. Commands for relocating volume groups
|cfgmgr||Discover and configure new devices on the target LPAR.|
|df||Display file systems.|
|exportvg||Remove the volume group definition from the system.|
|fsck||Check the file system consistency.|
|importvg||Import a volume group definition from the system and activate the volume group.|
|lspv||List physical volume.|
|lsvgfs||List the file systems belonging to a volume group.|
|mount||Mount a file system.|
|rmdev||Remove the physical volume definitions from the source LPAR.|
|umount||Unmount a file system.|
|varyoffvg||Deactivate a volume group.|
|varyonvg||Activate a volume group.|
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.
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 sparevg # /scratch
Unmount file systems
Unmount any file systems in the volume group using the
# 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 sparevg
You can check the volume group status by listing physical volumes with
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 sparevg
After you run
lspv displays the volume group as
# 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
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.
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:
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
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
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.
fsck on all file systems
You should check the file system consistency for each file system. You can do this with the
# 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
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.
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.
- 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.
- Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.