Safely Split an LVM Volume Group with vgsplit

A volume group has outgrown its job, and moving a couple of physical volumes out with vgsplit beats rebuilding it from a backup. You will move one or more complete physical volumes (PVs) from an existing LVM volume group (VG) into a new or existing VG, then verify the result. The installed command is from lvm2 2.03.16(2), dated 18 May 2022. Allow 15 to 30 minutes for the checks, plus however long your metadata backup and maintenance window require.

Warning: This changes LVM metadata and can affect the storage presented to services. Take a tested backup, stop or quiesce workloads that use the affected logical volumes (LVs), and use a maintenance window. The examples use placeholder names and devices. Replace every placeholder after checking it against your host.

1. Inventory the source VG and its PVs

Run the read-only inventory commands as an ordinary user first. Elevated privileges are not normally needed for these displays, although a host's device permissions may require sudo.

$ vgs
$ pvs -o pv_name,vg_name,pv_size,pv_free
$ lvs -a -o lv_name,vg_name,lv_size,devices

Choose a source VG, a destination VG name, and the complete PVs to move. For example, the intended operation might be:

source VG:      vg_data
destination VG: vg_archive
PVs to move:    /dev/sdb /dev/sdc

Do not infer LV placement from a PV name alone. The lvs output shows which devices back each LV. A PV is indivisible for vgsplit: this command cannot move only part of a PV.

Checkpoint: Write down the exact source VG, destination VG and PV paths. Confirm that every LV you intend to leave behind is entirely on the remaining source PVs, and every LV you intend to move is entirely on the selected PVs.

2. Check the split boundary

Every LV must remain wholly in one VG. LVM will reject a layout where an LV would be split between the source and destination VGs. If only part of a PV needs to move, vgsplit is the wrong tool; investigate pvmove first to rearrange extents, then reassess the complete-PV boundary.

For a read-only planning pass, use the same command with --test. This disables metadata writing but can still produce unusual messages in a multi-stage operation because later stages cannot read back changes that were not made:

$ sudo vgsplit --test --verbose vg_data vg_archive /dev/sdb /dev/sdc

A successful test is useful evidence, not a substitute for checking the layout and backups. The command's test mode is deliberately not a transaction preview with a guaranteed copy of all normal output.

3. Back up LVM metadata

Automatic metadata backup is enabled by default in normal configurations, and the manual strongly advises keeping it enabled. Make an explicit backup before the live change so the recovery point is easy to identify:

$ sudo vgcfgbackup vg_data

Check where the backup was written according to your LVM configuration, and preserve it with your other recovery material. A metadata backup is not a filesystem backup and does not replace one. Keep copies of the data and the LVM configuration needed to restore the host.

4. Move complete PVs to a new VG

When the destination VG does not exist, vgsplit creates it. The source VG is the first VG argument, the destination is the second, and the PVs follow:

$ sudo vgsplit vg_data vg_archive /dev/sdb /dev/sdc

Use the exact PV paths from pvs. Do not add --yes to a first run: that option automatically answers prompts with yes and is intended for carefully reviewed automation. The command may also accept new-VG properties such as --maxphysicalvolumes, --maxlogicalvolumes, --alloc or --vgmetadatacopies, but set them only when you have a specific requirement.

Checkpoint: If the command stops with an LV placement error, do not force it. Return to the lvs -o ... devices output and resolve the extent layout before trying again.

5. Move the PVs used by one LV

There is a second form for selecting the PVs that underlie a named LV. It still moves complete PVs, and the source and destination VGs remain in the same order:

$ sudo vgsplit --name appdata vg_data vg_app

Use this only after checking exactly which PVs back appdata. If that LV spans more PVs than you expected, all of those underlying PVs are candidates for the move, subject to the command's complete-PV and whole-LV rules. This option does not extract an LV into a separate VG while leaving its PVs shared.

6. Verify both volume groups

Refresh the inventory and confirm that the source and destination now contain the intended PVs:

$ vgs
$ pvs -o pv_name,vg_name,pv_size,pv_free
$ lvs -a -o lv_name,vg_name,lv_size,devices

Check the filesystems and services that depend on the moved LVs using your normal operational checks. A successful vgsplit reports that the metadata operation completed; it does not prove that an application mounted every expected filesystem or that a service recovered correctly.

Recovery and common traps

If the live command has not completed, stop and preserve its error output. Do not run repeated variants with --yes or disable locking. The manual warns that --nolocking can let concurrent commands produce incorrect results. Ensure no other LVM operation is running, then correct the layout or device visibility problem.

If the metadata change completed but the result is wrong, stop dependent workloads and use the matching vgcfgbackup file with the documented vgcfgrestore procedure for your host. Restore is a destructive metadata operation: verify the backup, PV identities and current state before using it, and do not guess at a filename. If only a planned test was run, no metadata should have been written by vgsplit --test.

Done means