Two volume groups that should have been one is a common leftover from a hasty build. vgmerge fixes it by moving one VG's metadata into another. It is a storage change, not a harmless reporting command, so this guide stops at a test run unless you have a maintenance window and a verified recovery plan.
This guide targets LVM tools 2.03.16(2), from package lvm2 version 2.03.16-3ubuntu3.2 on the machine used for this article. Allow about 20 minutes for preparation, longer if you need to check mounted filesystems, clustered locking or backups.
DESTINATION_VG is the VG that remains, and SOURCE_VG is the inactive VG that is consumed.Warning: Do not run the real merge against production names until you have confirmed that the source is the one you intend to consume. A mistaken destination changes the result. Do not use --yes just to suppress a prompt.
Start with read-only checks. These do not need sudo:
$ command -v vgmerge
/usr/sbin/vgmerge
$ vgmerge --version
LVM version: 2.03.16(2) (2022-05-18)
$ vgmerge --help
vgmerge - Merge volume groupsThe synopsis is vgmerge VG VG. The first name is the destination and the second is the source, matching the installed manual's example, vgmerge -v databases vg00. Write the order down before substituting real names. A shell variable makes the intended order easier to review:
$ DESTINATION_VG='data-vg'
$ SOURCE_VG='old-vg'
$ printf 'destination=%s source=%s\n' "$DESTINATION_VG" "$SOURCE_VG"
destination=data-vg source=old-vgCheckpoint: the printed destination must be the VG you intend to keep. If it is not, stop and correct the variables.
Use elevated privileges for LVM inspection if your account cannot read the devices. The physical extent size is a hard compatibility requirement: vgmerge only merges VGs when the sizes are equal. Check both summaries and retain the output for review:
$ sudo vgs -o vg_name,vg_attr,vg_size,vg_free,vg_extent_size "$DESTINATION_VG" "$SOURCE_VG"
VG Attr VSize VFree Ext
data-vg wz--n- 1.00t 120.00g 4.00m
old-vg wz--n- 500.00g 80.00g 4.00mThe exact columns and spacing can vary with LVM reporting settings. The useful checks are that both names are present, the Ext values match, and the source has no active workload that must remain separate. The manual also requires the combined physical-volume and logical-volume summaries to fit within the destination VG's limits. A successful size comparison alone is not enough.
Inspect the logical volumes and physical volumes before changing anything:
$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,devices "$DESTINATION_VG" "$SOURCE_VG"
$ sudo pvs -o pv_name,vg_name,pv_size,pv_free,pv_pe_count "$DESTINATION_VG" "$SOURCE_VG"
Record mount points, services and backup jobs using the source VG. Stop those users according to your normal operating procedure. The source VG must be inactive when the merge runs. If a logical volume is mounted or an application still has files open there, do not force your way through the change. Fix the workload boundary first.
Before a state-changing command, create or confirm a metadata backup. The vgmerge manual strongly advises automatic metadata backup, enabled with --autobackup y, which is the explicit form used below. You can also make a deliberate backup with vgcfgbackup:
$ sudo vgcfgbackup "$DESTINATION_VG" "$SOURCE_VG"
Volume group "data-vg" successfully backed up.
Volume group "old-vg" successfully backed up.
$ sudo ls -l /etc/lvm/backup/"$DESTINATION_VG" /etc/lvm/backup/"$SOURCE_VG"
Output wording can differ by package configuration. Check that both named files exist and have a recent timestamp. This is a metadata recovery aid, not a filesystem backup: it does not copy the contents of logical volumes. Keep your filesystem and application backups separate.
Checkpoint: do not proceed until the metadata backups are present and you know where the corresponding recovery process is documented. The merge itself has no simple rename-style undo. Restoring metadata may require deactivating volumes and can make later changes disappear, so treat restoration as an emergency procedure rather than a routine rollback.
Run the exact operation with --test and verbose output. Use sudo because the real command must inspect and lock LVM devices, even though test mode disables metadata writing:
$ sudo vgmerge --test --verbose --autobackup y "$DESTINATION_VG" "$SOURCE_VG"
A test run returning success is useful, but it is not a guarantee that the live operation will succeed. The installed manual says test mode disables metadata writing while still returning success to the calling function, and multi-stage commands can print unusual messages when a later stage reads metadata that was not actually changed. Read the full output rather than checking only the exit status.
Do not add --nolocking to make a test pass. That option disables LVM locking and the manual warns that concurrent commands can then produce incorrect results. Likewise, --devices and --devicesfile restrict which devices LVM can see; use them only when you have a deliberate device-filtering setup, because hiding a PV can make an otherwise healthy VG look incomplete.
After reviewing the test output, stop remaining users of both VGs, confirm the source is inactive, and take a final backup or snapshot according to your site procedure. Then run the same command without --test:
$ sudo vgmerge --verbose --autobackup y "$DESTINATION_VG" "$SOURCE_VG"
--autobackup y asks LVM to back up metadata after the change. It does not replace the deliberate backup from the previous step. Avoid --yes unless the command is being run from a reviewed, non-interactive procedure. A prompt is a useful last chance to catch reversed VG names.
If the command fails, do not immediately retry with weaker safety options. Capture the complete error, inspect vgs and lvs, and check whether the source is active, the extent sizes differ, a PV is missing, or the combined summaries exceed the destination's limits. Do not run a metadata restore while volumes are active.
When the merge reports success, confirm that the destination is visible and that the source name no longer represents a separate working VG:
$ sudo vgs "$DESTINATION_VG"
$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,devices "$DESTINATION_VG"
$ sudo pvs -o pv_name,vg_name,pv_size,pv_free
Compare the logical volumes and physical volumes with the inventory from step 2. Check filesystem devices with your normal mount and service checks before starting applications. If a mount or service uses a device path containing the old VG name, update it only if your configuration requires that change, then test it before the next reboot. Do not assume that a successful metadata merge has repaired unrelated mount, fstab or application configuration.
If verification finds a missing LV or an unexpected device assignment, stop dependent services and preserve the command output and metadata backups. Escalate to your storage recovery procedure. Repeated retries can turn a diagnosable state into a harder recovery problem.
--test run.