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

[Tiago Sousa via pve-devel <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 5936 bytes --]

From: Tiago Sousa <joao.sousa@eurotux.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support
Date: Thu, 17 Jul 2025 15:49:05 +0100
Message-ID: <1fddff1a-b806-475a-ac75-1dd0107d1013@eurotux.com>

Hi,

I'm starting to develop the thin provisioning feature to integrate with 
the new snapshot feature for LVM. The architecture I'm following is very 
similar to the one Alexandre mentioned here

https://lore.proxmox.com/pve-devel/mailman.380.1750053104.395.pve-devel@lists.proxmox.com/

However I have some questions:

1. When qmeventd receives the BLOCK_WRITE_THRESHOLD event, should the 
extend request (writing the nodename to the extend queue) be handled 
directly in C, or would it be preferable to do it via an API call such 
as PUT /nodes/{node}/qemu/{vmid}/extend_request, passing the nodename as 
a parameter?

2. If we use a local daemon for each node how is it decided which node 
will preform the extend operation?
Another option is to use a centralized daemon (maybe on the quorum 
master) that performs every extend.

3. Is there any specific reason for the event only be triggered at 50% 
of last chunk, in your implementation? I was thinking of implementing it 
with 10% of the current provisioned space to be safe. Any options on this?

In terms of locking I'm planning to use the cfs_lock_file to write to 
the extend queue and cfs_lock_storage to perform the extend on the 
target disk.


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel