[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