Recover an Exported LVM Volume Group with vgimport

Disks get moved between hosts, and LVM will not just start using a group it does not recognise as its own. vgimport is the command that registers an exported volume group on its new host, once the physical volumes have arrived and the move was deliberate. The examples use LVM 2.03.16(2), from Ubuntu package lvm2 version 2.03.16-3ubuntu3.2.

Allow 10 to 20 minutes if the disks are already attached and visible.

1. Confirm the installed command

Check the version and the command forms before touching metadata:

$ vgimport --version
LVM version:     2.03.16(2) (2022-05-18)
Library version: 1.02.185 (2022-05-18)

$ vgimport --help

The installed command accepts either a volume group, a tag or a selection expression. It also has an --all form for every visible volume group. The version output can contain build and configuration details as well, so do not compare the whole output as a fixed string in a script.

Checkpoint: If vgimport is missing, stop here and use the package supplied by your distribution. Installing packages is outside this guide. If the version differs, reread the local manual before applying examples to automation.

2. Find the moved group without importing it

Make the disks visible to the operating system and ask LVM to list the groups it can see:

# pvs
# vgs -o vg_name,vg_systemid

These are discovery commands. They do not register an exported group. Record the exact group name and check the device paths before proceeding. A group name alone is not enough when several hosts can see similarly named storage.

The system ID column is the useful clue. An exported group has no system ID, while an imported group has the ID assigned to the host running the import when that host uses system IDs. The exact display depends on the local LVM reporting configuration, so use the column heading rather than relying on spacing or colour in terminal output.

If the group is absent, do not guess with --all. Check that the expected PVs are attached and visible to LVM. On installations using the LVM devices file, inspect its managed device set with the normal lvmdevices workflow. A device that is visible to the kernel can still be hidden from LVM.

3. Preview the exact import

Use test mode with the recorded group name:

# vgimport --test vg_data

Replace vg_data with the real group name. Test mode disables metadata writing, but the manual warns that a multi-stage command can produce unusual messages because later stages may read metadata that was not actually changed. Treat a successful test as a useful rehearsal, not proof that the real import will succeed.

It is also normal for a test from an unprivileged shell or a restricted container to fail while opening the device-mapper control interface. That failure says something about the execution environment, not necessarily about the VG. Run the test with the same privilege and device access that the real operation will have.

Checkpoint: The preview must name the intended group and must not show an unexpected set of PVs. If LVM reports missing devices, stop and repair visibility first. Do not use --force to hide an incomplete disk set.

4. Import one known group

When the PV set is complete and the move is deliberate, run the import as root:

# vgimport vg_data

vgimport makes an exported VG known to the system again. In a configuration with a host system ID, it sets the VG system ID to match the host running the command. This is a metadata change, so it requires elevated access and should be performed with the host's normal LVM locking in place.

If the command asks for confirmation, stop and read the affected VG and device information. Continue only when it matches the storage move you authorised. If you reject the operation, no import should be completed; verify the state with the reporting command in the next step.

5. Verify ownership and visibility

Run the report again:

# vgs -o vg_name,vg_systemid
# pvs

The target VG should now be visible with the local system ID where system IDs are enabled. Its PVs should be present rather than marked missing. This checks registration and device visibility, not whether a filesystem is mounted or whether an application can safely use an LV.

If you need machine-readable reporting for a script, ask LVM for JSON:

# vgs --reportformat json -o vg_name,vg_systemid

Parse the JSON structure rather than scraping aligned columns. Keep the VG name explicit in operational commands even if a later script uses a selection expression, because an accidental broad selection can process more storage than intended.

Checkpoint: Confirm the imported group, every expected PV, and the system ID before activating logical volumes or mounting filesystems. Those are separate actions with their own recovery and service-impact decisions.

6. Import several groups only when the scope is known

The command can import all visible exported groups:

# vgimport --all

This is appropriate only when every visible exported VG belongs to this host and the complete device set for each one is available. It is a poor default for a recovery shell, a shared SAN host or a machine that can see storage from more than one owner. Prefer one explicit VG at a time when you can name the target.

Tags and --select can narrow processing when your environment already uses them consistently. Test that selection first and inspect the selected objects. Do not paste an unreviewed selection expression into a privileged recovery command.

7. Recover from a wrong or premature import

If you imported the wrong VG or discovered that the disk set is incomplete, stop using the group and preserve the evidence. Do not try random combinations of --force, --nolocking and repeated imports. First record:

# vgs -o vg_name,vg_systemid,vg_attr
# pvs -o pv_name,vg_name,pv_attr
# vgdisplay vg_data

Then follow your storage recovery procedure. Reversing an import is not a harmless toggle: changing ownership metadata on a group that another host is using can cause competing access to the same disks. If the group was imported on the wrong host, isolate the storage and consult the platform owner before changing its system ID or exporting it again.

Keep normal LVM locking enabled while investigating. If a service was already using the group, coordinate a controlled stop and unmount before any further metadata or activation work. The safest undo is often to stop, isolate the devices and restore from the recorded storage change plan, rather than issuing another mutating command immediately.

Done means