Safely Change LVM Physical Volume Attributes with pvchange

pvchange flips whether an LVM physical volume can still receive new extents, handy before pulling a disk from a live volume group. This guide gets you a controlled way to make that change, plus a safe method for checking the target before you write any metadata. The examples use LVM 2.03.16(2), from Ubuntu package lvm2 2.03.16-3ubuntu3.2, installed on this machine.

Allow about fifteen minutes for a planned attribute change, longer if you need to identify the correct disk. You need an LVM volume group with the physical volume already initialised, and sudo access for commands that write its metadata. This guide does not create, remove, resize or move data on a volume.

1. Identify the physical volume

Start with a read-only inventory. Do not copy a device path from an unrelated host: names such as /dev/sdb1 can point to a different disk after a reboot or hardware change.

$ pvs --readonly
  PV         VG       Fmt  Attr PSize   PFree
  /dev/sdb1  vgdata   lvm2 a--  <1.00t  128.00g

The exact columns and values depend on your host, so confirm the path, volume group and free space against your own output. Need more identity information? Ask pvs for selected fields:

$ pvs --readonly -o pv_name,vg_name,pv_attr,pv_uuid,pv_tags /dev/sdb1

Checkpoint: the path in the next commands must be the PV you intend to change. If you cannot explain why that device is the right one, stop here. A successful command against the wrong PV is still a successful command.

2. Back up the volume group metadata

Before changing LVM metadata, take a metadata backup. This is ordinary administrative caution, and the backup itself needs access to the volume group and its configured backup directory:

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

The message format can vary; check the exit status immediately if you need a scriptable result:

$ printf 'backup status: %s\n' "$?"
backup status: 0

Do not treat this backup as a copy of the data on the PV: it records LVM metadata, not filesystem contents. Keep a separate data backup and know where the LVM backup landed before making a change.

3. Preview the allocation change

The most common use of pvchange is to stop new physical extents being allocated on a PV while it is investigated or prepared for removal:

$ sudo pvchange --test --allocatable n /dev/sdb1
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  1 physical volume changed

Test mode disables metadata writing and reports success to the calling function, though a multi-stage command can still produce unusual messages. Treat this as a syntax and target check, not proof the real command will succeed. On a host where the device is unavailable, the output and exit status will instead describe the discovery or locking problem.

Checkpoint: confirm the test command named the intended PV and its output explicitly says metadata was not updated. If it reports a missing device, permission problem or locking failure, fix that first. Do not add --nolocking just to make the error disappear: the manpage warns that concurrent LVM commands can then produce incorrect results.

4. Disable or restore allocation

Once the preview makes sense, run the real change with elevated privileges:

$ sudo pvchange --allocatable n /dev/sdb1
  Physical volume "/dev/sdb1" changed
  1 physical volume changed / 0 physical volumes not changed

• Existing extents do not move. The PV does not become empty; it just stops accepting future LVM allocation.
• Existing logical volumes keep working. They can continue using extents already placed there.
• Removal is a separate job. If you are preparing to remove the disk, use pvmove separately and verify it completed before treating the device as removable.

To allow allocation again, use the inverse value, which is the normal undo for this guide's change:

$ sudo pvchange --allocatable y /dev/sdb1

Verify it rather than relying on memory:

$ pvs --readonly -o pv_name,pv_attr /dev/sdb1
  PV         Attr
  /dev/sdb1  a--

The attribute output is compact and can look different when other PV properties are set. Find the allocatable position in your installed pvs output and compare it with the state before the change.

5. Use tags and metadataignore deliberately

--addtag TAG and --deltag TAG add or remove LVM tags on the PV. A tag is metadata used by LVM selection and administration; it is not a filesystem label and does not rename the block device:

$ sudo pvchange --addtag maintenance /dev/sdb1
$ pvs --readonly -o pv_name,pv_tags /dev/sdb1
$ sudo pvchange --deltag maintenance /dev/sdb1

Choose tags that describe an operational state, and document who consumes them. Removing a tag is only reversible if you know its previous spelling and purpose. These commands change metadata too, so include them in the same backup and review process as the allocation change.

--metadataignore y tells LVM to ignore metadata areas on the PV and stop storing metadata there; --metadataignore n restores normal use. This is a specialised layout decision, not a general repair switch. Do not use it to hide a damaged PV or silence an activation failure without understanding the volume group's metadata copies.

6. Avoid the high-risk options

--uuid generates a new random UUID for the specified PV. Treat that as a recovery or cloning operation, not routine housekeeping: scripts, device filters and metadata can depend on PV identity. Do not run it on a live system just because the current UUID looks untidy. Preserve the metadata backup and a tested recovery plan before considering it.

Warning: also avoid combining --force, --yes or --nolocking with an uncertain target. They suppress protections, confirmations or coordination, and an unattended command is not safer just because it cannot pause for a question.

Done means

• Target confirmed. You matched the target path to a current pvs --readonly inventory.
• Metadata backed up. You created and located a volume group metadata backup.
• Preview checked. You previewed the change with --test and understood any discovery or locking errors.
• Attribute set correctly. The PV's allocatable state now matches the intended maintenance state.
• Undo known. You know that --allocatable y is the normal undo for --allocatable n.
• Risky options avoided. You left UUID changes, forced confirmation and disabled locking out of routine work.