Safely Export an LVM Volume Group Before Moving Its Disks

Pulling disks out of a live host and plugging them into another one is how volume groups end up double-mounted and corrupted. vgexport marks a group offline first so the move is boring.

This guide gets a volume group into the exported, offline state, ready for its physical volumes to be moved to another machine. It uses vgexport from LVM2 2.03.16(2), installed here with library version 1.02.185. Allow about fifteen minutes for the command and checks, plus whatever time you need to stop the services using the volume group.

You need root access, the LVM2 tools, the volume group name, and a maintenance window. Exporting is a metadata change that makes the group unusable on this host. It is not a disk wipe and it does not remove the volume group, but it can interrupt applications and automounting. Do not run the examples against a live production group until its users are stopped and its data is backed up.

1. Confirm the volume group and its logical volumes

Replace VG_NAME with the exact group you intend to move. First inspect it as root:

$ sudo vgs VG_NAME
$ sudo lvs VG_NAME

Use the output to confirm that the name and physical volumes are the ones you expect. Record the output somewhere accessible during the move. A typo here is not harmless: LVM accepts tags and selection expressions as well as ordinary volume group names, so a broad selector can match more than one group.

Checkpoint: every logical volume in the target group must be inactive before export. Stop the services that use it, unmount filesystems backed by it, and deactivate any remaining logical volumes using your normal LVM procedure. Do not force a filesystem offline while it still has writes in flight.

2. Prove that no logical volume is active

Check the state again after stopping users:

$ sudo lvs -o lv_name,lv_attr,lv_active VG_NAME
  LV       Attr       Active
  data     -wi------- not available

The precise rows depend on your group, but the active column should not show an active logical volume. If the command reports that a volume is still active, find the process or mount holding it and resolve that first. vgexport refuses to export a group until all its logical volumes are inactive.

For a dry run of the next operation, use the installed command's test mode:

$ sudo vgexport --test VG_NAME
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.

Test mode is a useful rehearsal, not proof that the real command will succeed later. It disables metadata writing, and locking, device visibility or a changed system can still affect the result. Treat any test-mode error as a stop sign.

3. Export one named group

When the maintenance checks are complete, export only the named group:

$ sudo vgexport VG_NAME

The command changes the group to an exported state. LVM commands on this host will ignore it or report an error when asked to use it. The export also clears the volume group's system ID. That is part of the hand-off: when the group is imported on another host, vgimport sets its system ID to match that host when the host has one.

Warning: Do not add --yes merely to make a script quiet. That option answers prompts affirmatively and the manpage describes it as requiring extreme caution. Keep the normal confirmation and review output unless you have a tested, tightly scoped automation path.

4. Verify the exported state

Ask both the volume group and physical volume reports to show their export fields:

$ sudo vgs -o vg_name,vg_attr,vg_exported VG_NAME
$ sudo pvs -o pv_name,vg_name,pv_exported

For the target group, vgs should show x in the third volume group attribute and exported in its export report field. The physical volumes belonging to it should likewise show x in the second physical volume attribute and exported in their export report field. The exact column layout is controlled by the report command, so use the named fields rather than trying to parse a fixed character position from default output.

Checkpoint: save the verification output with the change record. Also confirm that the group is not being used by a service, mount unit, backup job or monitoring action. Export protects against accidental use by LVM, but it does not replace service coordination or a physical-disk inventory.

5. Move the disks and import them on the destination

Only after the verification succeeds should you detach and move the physical volumes, following the storage system's safe removal procedure. Label the disks or enclosure with the volume group name. The export state is recorded in LVM metadata on the physical volumes; it is not a special marker held only in this machine's cache.

On the destination host, make the disks visible to LVM, check that the expected physical volumes are present, and import the exported group:

$ sudo pvs
$ sudo vgimport VG_NAME

Then verify the group and activate its logical volumes using the destination's normal procedure. Do not activate a group until you have confirmed that the disks are complete and that the destination is the only host which should use them. Shared storage needs additional locking and fencing decisions; vgexport alone does not make simultaneous access safe.

Common traps and recovery

"The group still appears in a scan" does not mean it is usable. An exported group can remain visible on disk, while LVM marks it exported and ignores it for ordinary operations. Check vg_exported and pv_exported, rather than relying on a device path appearing in a scan.

Do not confuse export with removal. vgexport does not delete metadata, remove physical volumes from the group, or erase data. Never substitute vgremove or pvremove; those are different and potentially destructive operations.

If the move is cancelled, keep the disks attached to the original host and restore normal use with the matching import operation:

$ sudo vgimport VG_NAME
$ sudo vgs -o vg_name,vg_attr,vg_exported VG_NAME

Run that only when the group is no longer expected to be used elsewhere. If import fails, do not repeatedly activate devices or alter metadata at random. Check disk visibility, LVM locking, system IDs and the command's diagnostic output before escalating.

Done means