Safely Change LVM Volume Group State with vgchange

You will use vgchange to inspect the installed command, activate or deactivate logical volumes, and make one controlled volume group attribute change. The examples are for the LVM2 release installed here, version 2.03.16(2) from package lvm2 2.03.16-3ubuntu3.2.

Allow about fifteen minutes for a read-only check, or longer if you are changing activation on a production host. You need root access for most operations, a known volume group name, and a maintenance window before changing availability. This guide assumes the VG is local and not being used concurrently by another host.

1. Confirm the command and its version

First run the version query. It is read-only, although LVM may still print environment or device warnings on a restricted shell:

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

The exact build line can differ. The useful check is that the LVM version matches the behaviour you are about to rely on. Read the local help when working on another release:

$ vgchange --help

vgchange has several jobs. It changes VG attributes, changes LV activation in the kernel, and provides other VG maintenance operations. The option you choose determines which of those jobs it performs.

2. Record the current state

Use vgs and lvs before changing anything. These commands are ordinary inspection commands, but use sudo if the device scan or metadata is not readable as your user:

$ sudo vgs -o vg_name,vg_attr,lv_count,pv_count
$ sudo lvs -o vg_name,lv_name,lv_attr,lv_size,lv_active
  VG_NAME  LV_NAME  LV_ACTIVE
  vg0      root     active
  vg0      data     inactive

Your columns and rows will differ. Keep the output as a before-and-after record. In particular, do not confuse an inactive LV with a missing LV, or a VG attribute with the filesystem mounted above it.

3. Activate all LVs in a known VG

Activation creates or removes device-mapper block devices and the usual /dev/VG_NAME/LV_NAME links. It can make data available to applications, so check mounts and services first. This is an elevated, service-affecting operation:

$ sudo vgchange --activate y VG_NAME
  2 logical volume(s) in volume group "VG_NAME" now active

The count and wording vary with the VG. Verify the result instead of relying on the message:

$ sudo lvs -o vg_name,lv_name,lv_active VG_NAME
  VG_NAME  LV_NAME  LV_ACTIVE
  VG_NAME  root     active
  VG_NAME  data     active

The short form is sudo vgchange -a y VG_NAME. The command documented by this installed version also accepts -a ay, which requests autoactivation behaviour rather than ordinary activation. Do not use ay as a synonym without checking your boot and event-activation design.

To undo this particular change, stop anything using the logical volumes, unmount their filesystems, and then deactivate them:

$ sudo vgchange --activate n VG_NAME
  2 logical volume(s) in volume group "VG_NAME" now inactive

4. Control autoactivation deliberately

Autoactivation is separate from whether an LV happens to be active now. By default, LVs are autoactivated. You can set the property on the VG with:

$ sudo vgchange --setautoactivation n VG_NAME
$ sudo vgs -o vg_name,autoactivation VG_NAME
  VG_NAME  AUTOACTIVATION
  VG_NAME  no

This changes future commands that perform autoactivation; it does not mean that an already active LV is immediately deactivated. To restore the property:

$ sudo vgchange --setautoactivation y VG_NAME

If lvm.conf defines auto_activation_volume_list, that configuration also limits what can be autoactivated. An undefined list has no effect; an empty list disables autoactivation. Review that configuration before treating a successful property change as proof that a boot-time activation will occur.

5. Change a VG limit only with a recorded plan

For an inactive VG, --logicalvolume sets the maximum number of LVs. For example, this sets the limit to 128:

$ sudo vgchange --logicalvolume 128 VG_NAME

Check the resulting metadata:

$ sudo vgs -o vg_name,max_lv VG_NAME
  VG_NAME  MAX_LV
  VG_NAME     128

The equivalent short option is -l 128. The man page's example specifically describes changing this limit on an inactive vg00. Treat this as a metadata change, not a capacity increase: it does not create space and it does not resize existing logical volumes.

Other general attributes use the same pattern, but their safety boundaries differ. --maxphysicalvolumes Number changes the maximum PV count, --resizeable y|n controls adding or removing PVs, and --uuid generates a new random VG UUID. Do not use the UUID operation to solve a duplicate-device problem without a recovery plan, because identifying the wrong VG afterwards can make storage unavailable.

6. Use dry-run and diagnostics without pretending they changed state

When reviewing a planned metadata operation, add --test. It disables metadata writing but still returns success to the calling function, so it is useful for checking command flow, not for proving that the real change will succeed:

$ sudo vgchange --test --logicalvolume 128 VG_NAME
$ sudo vgs -o vg_name,max_lv VG_NAME

The second command should still show the old value. That is the point of the test mode. It can produce unusual messages in multi-stage operations because later code may expect a write that never happened.

If a command reports missing PVs, do not jump straight to --partial. The man page limits that option to doing the best it can to activate LVs with missing extents and says metadata may not be changed with it. Use it only as part of a recovery procedure. Likewise, --nolocking is not a performance switch: concurrent commands can produce incorrect results.