all lists on lists.proxmox.com
 help / color / mirror / Atom feed
* [pve-devel] [RFC storage/qemu-server] Thin provisioning on LVM
@ 2025-07-25 10:00 Joao Sousa via pve-devel
  2025-07-25 14:46 ` Tiago Sousa via pve-devel
  0 siblings, 1 reply; 7+ messages in thread
From: Joao Sousa via pve-devel @ 2025-07-25 10:00 UTC (permalink / raw)
  To: Proxmox VE development discussion; +Cc: Joao Sousa

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

From: Joao Sousa <joao.sousa@eurotux.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: [RFC storage/qemu-server] Thin provisioning on LVM
Date: Fri, 25 Jul 2025 11:00:40 +0100
Message-ID: <1b1df67f-4c6a-4cf5-942f-b2ed752506a6@eurotux.com>

Hi,

As previously discussed with Alexandre, we talked about an architecture 
that enables the use of thin-provisioned LVs with LVM. The idea is to 
implement a daemon that processes LV extend requests from a queue.

We considered two possible implementations for the queue and the daemon:

1. One queue and daemon per node. This approach increases complexity, 
particularly for live migrations and node failures. If a node fails, 
other nodes would need to "steal" pending requests from the failed 
node’s queue. It also introduces challenges in preserving the execution 
order of extend operations, since multiple daemons would compete for a 
storage lock without a guaranteed order.

2. A centralized queue in /etc/pve and one daemon per node. Each daemon 
would check the first entry in the queue and process the extend request 
only if the target volume is local to that node. This approach is 
simpler and easier to manage. However, we’d need to ensure proper 
locking when writing to the queue. Is there a C-based alternative to 
cfs_lock_file that we can use to coordinate writes to the queue from 
qmeventd and pvestatd?

For both implementations, we need to configure a write threshold for 
each VM's block devices. When this threshold is reached, it should 
trigger an event that qmeventd catches. As a fallback, if a VM is locked 
due to an I/O error, pvestatd should also submit an extend request. This 
one should be prioritized by placing it at the front of the queue.

The write threshold must be applied to the top node of the block device 
chain (drive-$drive_id) during the QemuServer::Blockdev::attach function 
when the VM starts. It should also be updated each time the volume is 
extended, so the daemon must reset it accordingly.

Here’s a simplified flow of the architecture:

qemu -> qmeventd -> extend_queue <- storage_monitor_daemon
      -> pvestatd

I’m currently implementing the write threshold in the attach function 
but running into issues with debugging. Are there any recommended 
methods or tools for debugging qemu-server functions? I’m not seeing any 
relevant logs in syslog.


[-- 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2025-08-11 20:33 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-25 10:00 [pve-devel] [RFC storage/qemu-server] Thin provisioning on LVM Joao Sousa via pve-devel
2025-07-25 14:46 ` Tiago Sousa via pve-devel
2025-08-02 16:42   ` [pve-devel] [PATCH qemu-server 0/2] set write threshold logic Tiago Sousa via pve-devel
2025-08-04  9:14     ` Fiona Ebner
2025-08-11 20:34       ` Joao Sousa via pve-devel
     [not found]   ` <20250802164240.21751-1-joao.sousa@eurotux.com>
2025-08-02 16:42     ` [pve-devel] [PATCH qemu-server 1/2] blockdev: add set write threshold Tiago Sousa via pve-devel
2025-08-02 16:42     ` [pve-devel] [PATCH qemu-server 2/2] qmeventd: add block write threshold event handling Tiago Sousa via pve-devel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal