Rename an LVM Volume Group Without Losing Track of Its Devices

A renamed volume group is easy for LVM to handle and easy for a forgotten mount unit to trip over. vgrename does the rename cleanly; keeping every reference to the old name in sync is the part you have to do yourself. Allow about 15 minutes for a quiet host with a known volume group, longer if the group holds a root filesystem, active services or shared storage.

This guide follows the installed lvm2 package, version 2.03.16-3ubuntu3.2, whose command reports LVM version 2.03.16(2).

1. Check the command and plan the change

Confirm which executable will run and read its version:

$ command -v vgrename
/usr/sbin/vgrename
$ vgrename --version
  LVM version:     2.03.16(2) (2022-05-18)
  Library version: 1.02.185 (2022-05-18)

The exact build details can vary, but the two positional arguments are stable for this installed command: the existing volume group name, followed by its new name. Do not confuse this with lvrename, which renames a logical volume inside a group.

Warning: Renaming the group changes the name used in common LVM device paths. A mounted filesystem is not copied, but a service, mount unit, /etc/fstab entry or script that spells the old group name can stop finding its device. Schedule the change, record the old name, and have console or out-of-band access if this is a server.

2. Record the group name and UUID

List the visible volume groups and their UUIDs before touching metadata:

$ sudo vgs -o vg_name,vg_uuid
  VG       VG UUID
  vg_old   q1w2e3-r4t5-y6u7-i8o9-p0a1-s2d3-f4g5h6

Your UUID will be different. Copy it carefully. All visible volume groups must have different names. Duplicate names can occur after disks move between machines or device filters change. In that situation, the UUID is the unambiguous selector.

Checkpoint: write down these three values before continuing:

Use a name accepted by your LVM configuration and keep it simple. Do not paste a shell prompt, whitespace or an explanatory label into the argument.

3. Back up LVM metadata

vgrename enables automatic metadata backup by default in the normal configuration, and the manual strongly advises keeping it enabled. Make that choice explicit for this change:

$ sudo vgs --foreign -o vg_name,vg_uuid
$ sudo vgrename --autobackup y --test vg_old vg_data
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.

--test disables metadata writing while still exercising the command path. It can produce unusual messages in multi-stage operations because later stages may expect a change that was deliberately not written. Treat it as a syntax and planning check, not as proof that the real rename will succeed.

For a separate, deliberate backup, use the installed vgcfgbackup command and note where it writes the archive:

$ sudo vgcfgbackup vg_old
  Volume group "vg_old" successfully backed up.

The exact status text may differ with the local configuration. If the backup fails, stop and fix that problem before renaming. Do not disable automatic backup to make the command quieter.

4. Check references to the old name

Search configuration and service definitions for the old group name. This is an inspection step and does not require a change:

$ sudo rg -n --hidden --glob '!*.log' 'vg_old' /etc /usr/lib/systemd/system 2>/dev/null

Review each match rather than replacing every occurrence. A comment or historical backup name may not need editing. Pay particular attention to /etc/fstab, systemd mount units, container definitions, monitoring checks, backup jobs and scripts that construct paths under /dev/vg_old/ or /dev/mapper/vg_old-.

If the group contains the root filesystem or a live service, do not proceed from a casual SSH session. Make the change in the maintenance window, with a tested way to reach the machine if a boot or mount reference needs repair.

5. Perform the rename

When the old name, new name and references are confirmed, run the real operation:

$ sudo vgrename --autobackup y vg_old vg_data
  Processing VG vg_old because of matching UUID.
  Volume group "vg_old" successfully renamed to "vg_data"

The wording and diagnostic detail can vary. The useful result is a zero exit status and a success message. The command changes the volume group metadata; it does not move the physical extents or copy logical-volume contents.

Warning: do not add --force or --yes just because a prompt is inconvenient. The manual describes both as overriding protections or confirmations. Investigate the reason for a refusal first. Likewise, do not use --nolocking for speed: concurrent LVM commands can produce incorrect results.

6. Verify the new identity and paths

Immediately check both the new name and the UUID:

$ sudo vgs -o vg_name,vg_uuid
  VG       VG UUID
  vg_data  q1w2e3-r4t5-y6u7-i8o9-p0a1-s2d3-f4g5h6
$ sudo lvs -o lv_name,vg_name,lv_path
  LV      VG       Path
  root    vg_data  /dev/vg_data/root

The UUID should be unchanged. The group column and the usual name-based logical-volume path should show the new name. If your system uses device-mapper names, inspect the actual paths rather than assuming a particular escaping rule.

Now revisit the references found in step 4. Replace only confirmed old-name references, then reload or restart the affected service according to its normal operating procedure. A rename is complete only when the workloads that use the group can still access their devices.

7. Recover if the command fails

A failed command does not mean the name changed. Check the exit status and query the group again:

$ sudo vgrename vg_old vg_data
$ status=$?
$ printf 'vgrename exit status: %s\n' "$status"
$ sudo vgs -o vg_name,vg_uuid

If the old name is still listed, correct the reported issue and retry. Common causes include a misspelled name, a duplicate VG name, incomplete device visibility, active locking conflicts or insufficient privileges. If duplicate names exist, use the UUID form documented by vgrename:

$ sudo vgrename q1w2e3-r4t5-y6u7-i8o9-p0a1-s2d3-f4g5h6 vg_data

Use the real UUID from vgs, not the example. If you need to undo a successful rename, run the same command in reverse after checking that the old name is available:

$ sudo vgrename --autobackup y vg_data vg_old

That reverses the name change, but it does not undo edits made to service files or mount configuration. Keep the metadata backup until the new arrangement has survived a normal service restart and, where relevant, a planned reboot.

Done means