Support for snapshots with raw backing disk on thick LV

[gplechuck]

Hey folks,

I understand we currently need qcow2 format disks to avail of the new snapshot-as-volume-chain feature. I wanted to check if this is a hard requirement or a limitation of the current implementation? From reading the description of how the snapshots operate, it sounds like in principle, a qcow2 overlay stored on a thick LV could use a raw LV as it's backing disk. As I understand, QEMU should be able to handle qcow2 overlays on raw backing images.

I created a VM with disk stored as a raw image on a thick LV, but the snapshot option is greyed out. Snapshots are enabled in the backing datastore config (snapshot-as-volume-chain 1).

Did some digging after attempting to create a snapshot with the CLI and I suspect a check in /usr/share/perl5/PVE/Storage/LVMPlugin.pm may be preventing the snapshot operation from being attempted if the backing disk type is raw.

Is there a design reason raw backed volume chains are not supported, or is this something that could potentially be enabled in the future?

Cheers

 

[UdoB]

A raw block device like a physical harddisk (in itself, without a filesystem with -for example- a .qcow file, or LVM-thin) can never have native snapshots. Where should the differential data go???

The current table has some remarks: https://pve.proxmox.com/pve-docs/chapter-pvesm.html#_storage_types

 

[gplechuck]

Thanks @UdoB . Just to clarify, I'm not talking about wholly raw volume chains, I'm specifically asking if a qcow2 overlay can use a raw LV as its backing device when using the new snapshot-as-volume-chain implementation - the differential data would live in the qcow2 overlay. I tested a similar concept (outside of Proxmox) with a qcow2 overlay backed by raw disk image and it worked under QEMU.

I'm wondering if there is any technical limitation to using a raw backing device with snapshot chains, or if its simply not supported by the storage plugin.

 

[bbgeek17]

Hi @gplechuck , welcome to the forum.

Technically, a qcow2 overlay can use a raw image as a backing file. PVE doesn't implement it that way for volume-chain snapshots.

One of the pitfalls of of using RAW vs QCOW base is during creation of a fresh, empty LV, unlike qcow2, a freshly-provisioned raw LV has no guarantee of returning zeros on unwritten reads. So it can't safely serve as a base layer the way a qcow2 image can.

We did a case study on QCOW2-on-LVM chains, if you have not seen it yet: https://kb.blockbridge.com/technote/proxmox-qcow-snapshots-on-lvm

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[gplechuck]

Hey @bbgeek17 , thanks for the explanation and link to the case study, very helpful.

I think I have a better handle now on why raw backing disk support is not implemented today. In the scenario I was considering, no snapshots would be taken until after the raw backing disk has been initialized (eg by an OS installer or imported image) , so zero read issue could be less of a concern, but there probably are cases where we would need to account for reads from sectors that have never been written (eg utilities that bypass the filesystem or disk resizing operations) . Perhaps zeroing the backing disk LV before use would mitigate some of the risk .

 

[fabian]

raw volumes as base layer were intentionally not implemented, because besides the issues already mentioned, it would complicate the code.