A storage snapshot with the same VG and PV UUIDs as its source is invisible to LVM as a second volume group, it just looks like the same one twice. vgimportclone fixes that by turning a set of cloned physical volumes into a separately named group with fresh UUIDs. The original volume group must remain available, and the devices you pass in must be the clone, not the source.
This guide describes the vgimportclone shipped by package lvm2 version 2.03.16-3ubuntu3.2, reporting LVM version 2.03.16(2). Allow about twenty minutes for the checks, plus time to identify the correct snapshot devices.
Warning: The import changes metadata on the cloned PVs. It changes the associated VG and PV UUIDs and renames the VG. A wrong device path can therefore modify the live source. Do not guess device names. If the devices are not unquestionably the clone, stop and identify them through your storage platform before continuing.
Confirm the binary, package version and supported command shape. These are read-only checks:
$ command -v vgimportclone
/usr/sbin/vgimportclone
$ dpkg-query -W -f='${Package} ${Version}\n' lvm2
lvm2 2.03.16-3ubuntu3.2
$ vgimportclone --version
LVM version: 2.03.16(2) (2022-05-18)The positional arguments are one or more PV paths. The useful command form is vgimportclone --basevgname NEW_VG /dev/CLONE_PV1 /dev/CLONE_PV2. The command does not take the source VG name as an argument; it reads the VG metadata from the supplied cloned PVs.
Checkpoint: run vgimportclone --help. It should show vgimportclone PV ..., --basevgname VG, --import, --test and the common LVM options.
Write down the source PV paths and the corresponding clone PV paths before using any command that writes metadata. The manpage example has source PVs /dev/sda and /dev/sdb, with snapshot PVs at /dev/sdc and /dev/sdd. Your names will differ.
Use a read-only inventory command to inspect what LVM can see. Run it as root so device filtering and metadata access do not hide useful information:
# pvs -o pv_name,pv_uuid,vg_name,vg_uuid
PV PV UUID VG VG UUID
/dev/SOURCE_PV1 SOURCE-PV-UUID source-vg SOURCE-VG-UUID
/dev/CLONE_PV1 CLONE-PV-UUID source-vg SOURCE-VG-UUID
/dev/CLONE_PV2 CLONE-PV-UUID source-vg SOURCE-VG-UUIDThe exact columns and alignment vary. The important clue is that the clone initially reports the same VG identity as the source. Confirm every clone PV that belongs to the VG is available. Passing only part of a multi-PV group can leave the command unable to read complete metadata.
Checkpoint: label the paths in your shell without changing LVM state:
SOURCE_PV1=/dev/SOURCE_PV1
CLONE_PV1=/dev/CLONE_PV1
CLONE_PV2=/dev/CLONE_PV2
NEW_VG=source-vg-snap--test disables metadata writing while still returning success to the calling function. It is useful for checking device visibility and command construction, but it is not a perfect simulation: multi-stage operations may produce unusual messages because later stages cannot read metadata that was not written.
# vgimportclone --test --basevgname "$NEW_VG" "$CLONE_PV1" "$CLONE_PV2"
There may be warnings or no useful output, depending on the LVM configuration. Treat a non-zero status or a message about missing devices as a stop signal. Fix device visibility first. Do not add --nolocking to silence a lock problem: the manpage warns that concurrent LVM commands can produce incorrect results when locking is disabled.
Checkpoint: make sure the clone is not mounted or being used by a service. Stop any consumer that could open the cloned logical volumes before the real import. Record the service change so you can restart it after verification.
Run the real operation as root, using only the confirmed clone paths:
# vgimportclone --basevgname "$NEW_VG" "$CLONE_PV1" "$CLONE_PV2"
The command renames the VG associated with those PVs and changes the associated VG and PV UUIDs. The original VG is not the target when the paths are correct. If $NEW_VG already exists, LVM adds a numeric suffix to make the name unique. For example, a requested source-vg-snap may become source-vg-snap1. Do not assume the requested name won; read the command output or query LVM afterwards.
By default, an exported VG is not changed. Add --import only when these are exported cloned VGs that you deliberately need to import. This option changes the boundary of the operation, so do not add it as a general troubleshooting step.
Do not use --yes automatically in an interactive repair. It suppresses confirmation prompts and always answers yes. First run the command without it, read the confirmation and device list, and proceed only when both match your change record.
Query the clone paths and check that the VG name and UUIDs differ from the source:
# pvs -o pv_name,pv_uuid,vg_name,vg_uuid "$CLONE_PV1" "$CLONE_PV2"
# vgs -o vg_name,vg_uuid,vg_attr
There is no fixed output to copy: names, UUIDs and attributes are host-specific. The cloned PVs should now report the new VG name, or the numeric suffix LVM selected, and new PV and VG UUIDs. The source PVs should retain their original identities when checked separately.
Only after that check should you inspect logical volumes with lvs or activate the imported VG using the normal, documented procedure for your environment. Activation can create device nodes and make filesystems visible. If the snapshot contains filesystems also mounted from the source, do not mount both copies read-write: duplicate filesystem UUIDs can confuse discovery and can corrupt data if both copies are written.
If you discover that the paths were wrong, stop immediately. Do not run vgimportclone again and do not try to restore the old identity with guessed UUID values. Keep the affected devices offline, preserve the command output, and restore the clone from the original snapshot or storage-level copy. A filesystem or VG backup may help with metadata recovery, but it is not a substitute for identifying which physical devices were changed.
If the command fails before changing metadata, correct the specific visibility or locking problem and repeat the test. If it fails after writing some metadata, treat the clone as a recovery case: do not activate it until its PV and VG identities have been inspected and compared with the source. Never use --nolocking while another LVM command could be running.
When you stopped a service for the import, restart it only after the clone is verified and mounted deliberately. The undo for this guide is operational rather than a reverse flag: discard the modified clone and recreate it, then leave the unchanged source VG in service.