Proxmox VE 9 LVM snapshot feature still tech preview?

H

hambuergaer

Member
Jan 18, 2022
6
2
23
45
Hi guys,

I already started to test Proxmox VE 9 with underlying Purestorage SAN and shared LVM on top of a SAN Lun. HA features for VMs are working fine with this storage type. I also started to test LVM snapshot feature snapshot-as-volume-chain. In the web-ui it is still commented with "Tech Preview" but in the Proxmox VE documentation it's not marked as such any longer.
So I'm wondering if its now officially supported?

- https://pve.proxmox.com/pve-docs/chapter-pvesm.html#storage_lvm
- https://pve.proxmox.com/pve-docs/chapter-pvesm.html#_storage_types

Best regards

Frank
 
  • Like
Reactions: CS- and ririmia
Hi, Proxmox VE 9.1 has been released: https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1.

Unfortunately snapshots as volume chains are still just a technology preview: https://pve.proxmox.com/pve-docs/chapter-pvesm.html#pvesm_lvm_config

I will test the LVM snapshot feature further after updating my cluster to Proxmox VE 9.1. In the current version there is a bug when deleting disks with snapshots enabled. It takes ages to wipe the disk bacause the current implementation has a limit of 10 Mb/s write speed on this specific disk action.
 
Hi,
hambuergaer said:
I will test the LVM snapshot feature further after updating my cluster to Proxmox VE 9.1. In the current version there is a bug when deleting disks with snapshots enabled. It takes ages to wipe the disk bacause the current implementation has a limit of 10 Mb/s write speed on this specific disk action.
Click to expand...
the bug was fixed and wiping was improved in Proxmox VE 9.1 thanks to @spirit:

https://git.proxmox.com/?p=pve-storage.git;a=commit;h=728d8f39925d2c694ee49c79d65c2156f2553a9a
https://git.proxmox.com/?p=pve-storage.git;a=commit;h=d5995ffbf73235840fdbd281aeb5034f669a410f
 
hambuergaer said:
I will test the LVM snapshot feature further after updating my cluster to Proxmox VE 9.1.
Click to expand...
Rolling out a new feature set that impacts data handling is naturally a significant undertaking. It carries a different risk profile than, say, introducing a new GUI option. I imagine the team wants to ensure that a few remaining details are fully worked out before releasing it.

For example, this recent discussion highlights some of the considerations involved: https://forum.proxmox.com/threads/u...emu-cache-none-in-proxmox.175933/#post-816074

I’m confident the feature will make its way into a release once the team feels it’s ready.

Cheers

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: Johannes S
Any updates on this? I'm using proxmox with thick LVM over ISCSI and it works good, but still a little bit worried, because it's "technology in preview".
 
Last edited:
  • Like
Reactions: TommyL
Hi @deskr,
yes, it's mostly working well. But there are still a few issues to be ironed out before we would like to drop the disclaimer. For example:
Some improvements have just landed too:
Code: 
libpve-storage-perl (9.1.12) trixie; urgency=medium
...
  * fix #7339: lvm: add an 'on-volume-remove' storage option with a 'discard'
    action. Removed volumes then get discarded (TRIM) in the background task
    before their final removal, so that thin-provisioned SAN LUNs can reclaim
    the space. Discards are issued in batches aligned to the device's discard
    granularity, and a volume on a device that turns out to not support
    discard is removed without it.

  * lvm: improve removing volumes with 'saferemove' enabled:
    - zero out volumes range by range with the kernel's zero-out operation,
      falling back to writing zeroes if the storage does not support it.
    - the 'saferemove_throughput' limit now also applies to the kernel's
      zero-out operation, not only to the fallback. For example, a configured
      '-10485760' limits wiping to 10 MiB/s, so zeroing out a 1 TiB volume
      takes about 29 hours. Remove the setting to wipe at full speed.
    - validate 'saferemove_throughput' in the configuration. Values with the
      k, m and g unit suffixes are still accepted, other spellings like '10mb'
      are rejected.
    - keep volumes that could not be zeroed out, renamed to
      'failed-<N>-del-<name>', for a manual zero-out instead of freeing their
      space with the old data on it.
    - refuse to wipe or discard a volume that is still in use on the node,
      like a direct removal does.
    - retry acquiring the storage lock for the final removal, and continue
      with the remaining volumes if removing one fails.

  * fix #7295: lvm: snapshot rollback: keep the original volume if allocating
    the new one fails, for storages with 'snapshot-as-volume-chain'.

  * lvm: snapshot delete: report errors from cleaning up after merging the
    snapshot, instead of reporting success.

  * lvm: snapshot: warn if renaming a volume back fails after the new top
    volume could not be allocated.

  * partially fix #7554: lvm: refuse to export or import qcow2 volumes as raw,
    which silently produced an unbootable guest on storage migration.

...

 -- Proxmox Support Team <support@proxmox.com>  Sat, 03 Oct 2026 19:40:00 +0200
 
  • Like
Reactions: Johannes S and deskr
You must log in or register to reply here.
Top Bottom
Back