From: "DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Cc: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [RFC pve-storage/qemu-server 00/10] introduce thin provisioned drives to thick LVM storage
Date: Thu, 13 Nov 2025 14:09:48 +0000 [thread overview]
Message-ID: <mailman.1090.1763043995.362.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <1682e2358c7051877ca1dafaa2adb9a207886eef.camel@groupe-cyllene.com>
[-- Attachment #1: Type: message/rfc822, Size: 13957 bytes --]
From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC pve-storage/qemu-server 00/10] introduce thin provisioned drives to thick LVM storage
Date: Thu, 13 Nov 2025 14:09:48 +0000
Message-ID: <f85630ffdc70fecc7765be6e6cd3aba3f8fffcd4.camel@groupe-cyllene.com>
Hi,
>>- qmeventd writes to the queue aren’t cluster-safe. I couldn’t find
>>any
>> primitives in the C code to lock the file via pmxcfs (like
>> cfs_lock_file in Perl). Is there any function that handles this?
Thinking about that, the qmeventd shouldn't write directly to /etc/pve
, because it'll hang if the machine don't have quorum. (and we don't
want to loose notifications in case of poweroff)
Maybe it could be better to write to a local queue file, then your
pvestord daemon could pull to local queue and push to the central queue
with the cfs lock.
(and in parrallel, pvestord is also dequeuing the top of the queue to
do the extend)
Also, about the central queue, what happen if a node is down (or loose
quorum but vm is still running), and can't process the top of queue if
the top vm to resize was on this node ?
I don't have verified, but it should need to kind of ttl, or requeue at
the bottom of queue, to not lock the other nodes
Another way could be to only have only local queue for each node,
and a simple cfs_lock on storageid to avoid parallel resize.
(so no real resize order across cluster, but anyway resize is not so
slow).
in case of crash, if the vm is restarted by HA on another node, we need
to check if we need to resize at start looking at qcow2 vs lvm size. (I
think we should do it by defaul at start in any case).
[-- 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
prev parent reply other threads:[~2025-11-13 14:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 11:25 Tiago Sousa via pve-devel
2025-11-12 15:20 ` DERUMIER, Alexandre via pve-devel
[not found] ` <1682e2358c7051877ca1dafaa2adb9a207886eef.camel@groupe-cyllene.com>
2025-11-13 14:09 ` DERUMIER, Alexandre via pve-devel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mailman.1090.1763043995.362.pve-devel@lists.proxmox.com \
--to=pve-devel@lists.proxmox.com \
--cc=alexandre.derumier@groupe-cyllene.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox