Safely Convert LVM Logical Volumes with lvconvert

lvconvert turns a plain linear LVM volume into RAID1, attaches a cache pool, or repairs a failed mirror leg, live, on disk. This guide walks through checking the current segment type, backing up metadata, rehearsing the command with --test, then running and watching the real conversion. The examples use LVM 2.03.16(2), package lvm2 2.03.16-3ubuntu3.2, as installed on this machine.

Allow 15 minutes for a read-only review, longer for a real conversion. You need an LVM volume group, enough free extents on suitable physical volumes, and a maintenance window. Most useful commands need root because they inspect or change device-mapper state. The examples use placeholder names such as vgdata/lvhome; replace them with values from your host.

Warning: lvconvert changes storage layout. A wrong type, missing extent or failed conversion can interrupt I/O or lose access to data. Take a tested backup, record the current layout, and make sure you can restore the LVM metadata before changing anything. Do not use --force or --yes to silence a warning you have not understood.

1. Confirm the installed command and available volumes

Check the exact tool version, then list visible logical volumes and their segment types. Neither command alters LVM metadata:

$ lvconvert --version
  LVM version:     2.03.16(2) (2022-05-18)
$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,segtype,devices
  VG     LV       Attr       LSize  Type   Devices
  vgdata lvhome   -wi-ao---- 80.00g linear /dev/sda2(0)

The output is host-specific. The segtype column is the starting point: it tells you whether the visible LV is linear, striped, RAID, thin, cache or another supported type. -a also shows hidden sub-LVs, which matter for RAID, cache and thin-pool operations.

Checkpoint: save the output of sudo lvs -a -o+devices vgdata/lvhome and sudo vgs vgdata. If the LV name or current type is not exactly what you expect, stop here.

2. Make a metadata backup and inspect allocation

Ask LVM to write a text backup of the volume group's metadata before the change:

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

The backup records LVM metadata, not the file contents of the LV. It helps repair an incorrect metadata change, but it is not a substitute for a filesystem or application backup. Confirm where your host stores the backup and protect it from the same disk failure. Then check free space and physical volume placement before choosing a destination:

$ sudo vgs -o vg_name,vg_size,vg_free
$ sudo pvs -o pv_name,vg_name,pv_size,pv_free
$ sudo lvs -a -o name,segtype,devices vgdata/lvhome

lvconvert can accept physical volume arguments to constrain where new extents are allocated. That is useful for deliberate placement, but a device name is not automatically a safe destination: verify the PV belongs to the intended volume group and has enough free extents.

3. Choose the narrowest conversion

Use --type when you are changing the layout type. A linear LV can become a two-way RAID1 LV with:

$ sudo lvconvert --type raid1 --mirrors 1 vgdata/lvhome

Here --mirrors 1 means one additional image, making two copies in total. The same form with --type mirror requests the older mirror type; the installed manual recommends RAID1 in most cases. A type conversion may need free extents and can run as a monitored operation.

For an existing RAID LV, change only the property you need. These are separate examples, not a command pair to paste blindly:

$ sudo lvconvert --stripes 3 vgdata/lvarchive
$ sudo lvconvert --stripesize 256 vgdata/lvarchive

The manual limits --stripes and --stripesize forms to RAID LVs. RAID level changes also have layout constraints, so read lvmraid(7) and check the current type before attempting one.

Thin and cache conversions carry extra metadata and failure modes. Converting an existing LV to a thin LV uses the original LV as an external, read-only origin:

$ sudo lvconvert --type thin --thinpool vgdata/tpool vgdata/lvhome

Attaching a cache pool changes the I/O path:

$ sudo lvconvert --type cache --cachepool vgdata/cpool vgdata/lvarchive

Warning: do not select writeback caching casually. A cache device or cache-pool failure can affect availability and recovery. Use writethrough when the extra write latency is acceptable and resilience is the priority, and test the cache design before production use.

4. Rehearse the command before changing metadata

Add --test to a candidate command when you want LVM to validate its path without updating metadata or activating and deactivating volumes:

$ sudo lvconvert --test --type raid1 --mirrors 1 vgdata/lvhome
  TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.

A successful test is not proof the real operation will finish. It does not replace checking backups, free space, device health, filesystem support or the maintenance window, and it can also be blocked by locking or device visibility even when the syntax is correct.

Checkpoint: run the test as the same account and with the same device restrictions as the real command. If you use --devices or --devicesfile, include them in both. Treat a non-zero status as a stop condition.

$ sudo lvconvert --test --type raid1 --mirrors 1 vgdata/lvhome
$ status=$?
$ printf 'lvconvert test status: %s\n' "$status"
lvconvert test status: 0

5. Run the conversion and monitor it

Remove --test only after the plan and output are recorded. Keep the terminal attached for the first run so errors are visible:

$ sudo lvconvert --type raid1 --mirrors 1 vgdata/lvhome
  Logical volume vgdata/lvhome converted.

Exact messages vary by operation and version. If the command starts polling, wait for it to finish. --background returns before a polled operation completes, so use it only when you have a separate monitoring plan. For a foreground check, inspect the LV and its hidden images:

$ sudo lvs -a -o name,lv_attr,segtype,copy_percent,health_status,devices vgdata/lvhome
  LV              Attr       Type  Cpy%Sync Health Devices
  lvhome          rwi-a-r--- raid1 100.00           lvhome_rimage_0(0),lvhome_rimage_1(0)

copy_percent reaching 100.00 is a useful progress check, but also inspect health and device placement. A conversion that is still syncing is not finished just because the command returned.

6. Use recovery operations deliberately

For a failed PV in a RAID or mirror LV, --repair is an intervention, not a generic health check:

$ sudo lvconvert --repair vgdata/lvhome

First inspect the failure and identify replacement storage. To replace a specific PV in a RAID LV, the installed syntax is:

$ sudo lvconvert --replace /dev/sdb1 vgdata/lvhome /dev/sdf1

Check that /dev/sdf1 is the intended PV and has the right capacity before running this. Do not improvise a replacement from a similarly named disk.

Splitting a RAID1 image creates a separate LV and changes redundancy; merging it later is a separate operation:

$ sudo lvconvert --splitmirrors 1 --name lv_split vgdata/lvhome
$ sudo lvconvert --mergemirrors vgdata/lvhome_rimage_1

Use these only with a documented purpose and a clear rollback. For a cache, --splitcache detaches and keeps the cache pool, while --uncache detaches and removes it. Neither is an undo for unrelated conversions.

7. Verify the finished state

After the operation, compare the recorded layout with the live result:

$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,segtype,copy_percent,health_status,devices vgdata
$ sudo lvdisplay vgdata/lvhome
$ sudo vgs vgdata
  VG     #PV #LV #SN Attr   VSize   VFree
  vgdata   2   3   0 wz--n- 200.00g 20.00g

Then check the filesystem and application at the layer that owns the data. LVM reporting cannot prove a filesystem is consistent or that an application can use the volume correctly. If the conversion failed, leave the LV untouched while you capture lvs output and logs; do not repeatedly rerun --repair or add --force without diagnosing the state first.

Done means