How to Safely Remove an LVM Disk from an Azure/AWS VM

Managing storage in production environments requires precision, especially when working with LVM-backed filesystems on cloud infrastructure. This guide documents a production-safe procedure to:

  • Shrink a logical volume
  • Migrate data off selected physical volumes
  • Remove those PVs from the volume group
  • Detach the correct Azure-managed disks using LUN mapping
  • Reclaim and extend remaining storage

This process ensures zero data loss and controlled disk decommissioning.

Step 1: Stop the Application

Before performing any filesystem shrink or LVM modification, stop the service using the volume.

systemctl stop cassandra.service #Taken as example

This ensures no open file handles or write operations interfere with filesystem operations.

Step 2: Shrink the Logical Volume Safely

Shrinking an LVM-backed ext4 filesystem must follow the correct sequence:

  1. Unmount filesystem
  2. Run filesystem check
  3. Shrink filesystem
  4. Shrink logical volume
umount /DATADISK
e2fsck -f /dev/vg1/DATADISK
resize2fs /dev/vg1/DATADISK 7T
lvreduce -L 7T /dev/vg1/DATADISK
mount /DATADISK
df -h
vgs

Explanation

  • e2fsck -f ensures filesystem integrity before resizing.
  • resize2fs reduces the ext4 filesystem size.
  • lvreduce reduces the logical volume to match the new filesystem size.
  • vgs confirms free extents are now available in the volume group.

Important: Always shrink the filesystem before shrinking the logical volume.

Step 3: Migrate Data from a Physical Volume

To remove a disk from LVM, all data must first be migrated off that physical volume.

Example:

pvmove /dev/sda

This relocates all extents from /dev/sda to other available PVs within vg1.

After successful migration:

vgreduce vg1 /dev/sda
pvremove /dev/sda

At this point:

  • The volume group no longer references /dev/sda
  • The disk is safe to detach from Azure

Step 4: Identify the Correct Azure Disk Using LUN Mapping

In Azure, disks are attached using Logical Unit Numbers (LUNs). Linux maps these to /dev/sdX devices.

To verify the mapping:

ls -l /dev/disk/azure/scsi1/

Example output:

lun0 -> ../../../sda
lun3 -> ../../../sdb
lun4 -> ../../../sdc

Interpretation

Azure LUNLinux Device
lun0/dev/sda
lun3/dev/sdb
lun4/dev/sdc

If /dev/sda was removed from LVM, then LUN 0 is the disk that must be detached in the Azure portal.

This verification step is critical to prevent accidental detachment of active disks.

Step 5: Extend the Remaining Logical Volume

Once unwanted PVs are removed, reallocate all free extents to the primary logical volume:

lvextend -l +100%FREE /dev/vg1/DATADISK
resize2fs /dev/vg1/DATADISK

This expands the logical volume and filesystem to utilize all available space within the volume group.

Validation and Verification

After completing the procedure, validate the storage configuration:

pvs
vgs
lvs -a -o +devices
lsblk

Confirm:

  • Removed devices are no longer part of the volume group
  • Logical volumes reference only intended physical volumes
  • Filesystem size matches expected allocation
  • No unintended mounts remain

Common Mistakes to Avoid

  • Shrinking logical volume before shrinking filesystem
  • Running lvreduce on a mounted filesystem
  • Detaching Azure disk before removing it from LVM
  • Failing to verify LUN-to-device mapping
  • Skipping filesystem integrity checks

Conclusion

This approach provides a controlled and production-safe method for:

  • Decommissioning Azure data disks
  • Rebalancing LVM storage
  • Reclaiming unused capacity
  • Avoiding downtime and data loss

By combining LVM best practices with Azure LUN validation, storage changes can be executed safely and predictably in enterprise environments.