[pve-devel] [PATCH-SERIES v6 pve-storage/qemu-server/pve-qemu] add external qcow2 snapshot support

DERUMIER, Alexandre alexandre.derumier at groupe-cyllene.com
Mon Jun 16 07:50:52 CEST 2025


>>I was thinking the same way (probably influenced by oVirt's way of
>>achieving this)

Yes, I don't have reinvented the wheel. I have customers with ovirt in
production with this setup, and I known that it's working 

> The only complex thing is to manage some kind of queue in this daemon
> and manage
> lvm cluster lock, as we can't resize multiple lvm volume at the same
> time.
> (Not sure if it need a central daemon, or a distributed daemon on
> each
> node with a shared queue in /etc/pve ...)

>>The solution that makes the most sense to me at the moment would be a
>>"distributed daemon", as in a daemon running on each node of the
>>cluster. Each node would maintain its own local queue for disk
>>extends
>>related to the VMs hosted there. When an extend is needed, the node
>>would
>>acquire the storage lock, perform the task, and then release the lock
>>so other nodes can proceed with their operations.
>>
>>What are your thoughts on this approach?

yes, I was thinking about something like that too.

Worst case could be all vms extendend at the same time, and extend
could not be enough fast, that's why I have also a check in pvestatd
about vm error (if storage is full, the vm will be pause). I think this
could send a notification to the resize daemon too, with high priority
queue.

so maybe something like:

qemu---->qmeventd------> resize queue(/etc/pve/..)<----- resize daemon
         pvestatd------>



>>The help is much appreciated :)

No problem ! (Note that you don't need all the snapshots && blockdev
patches to work  on it, I think that pve-storage patches to add support
on qcow2-lvm should be enough to start)




More information about the pve-devel mailing list