--- Begin Message ---
On 7/17/25 16:08, DERUMIER, Alexandre wrote:
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?
I think that qemevent should be as fast as possible. For my first
version, I was doing an exec of "qm extend ....", but I think it should
be even better if qmevent is simply write vmid/diskid in a text file
somewhere in /etc/pve. (the the other daemon can manage the queue)
Ok, are you thinking of having a local queue for each node as well?
since if there was a single queue for all nodes how would you manage the
concurrency of writes of each node? (is there a similar function to
cfs_lock_file but for C code?)
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.
The local daemon where the vm is running should resize the lvm, because
if the resize is done on another node, the lvm need to be
rescan/refresh to see the new size. AFAIK, It's not done automatically.
Ok, at first I was thinking of doing a FIFO like cluster wide queue
where the extends would be done in the order of arrival. But if I'm
understanding correctly, by doing a local queue and extend daemon, the
extends would be done in order but not in a global cluster sense right?
Where each extend daemon would be competing to acquire the storage lock
to proceed with the next extend. Please let me know if I'm understanding
your idea correctly.
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?
I have use same implementation than redhat, but it could be some
tunable value. It's really depend of how much fast is your storage.
as far I remember, it's was 50% of the size of the chunk (1GB).
so when you have 500MB free, it should add another 1GB.
of course, if you have fast nvme, and you write 2GB/s, it'll be too
short.
if you go with 10% of provisionned, if you have 2TB qcow2, it'll
increase when 200GB is free. (and how much do we want to increase ?
another 10% ? )
but if you want 2GB qcow2, it'll increase when 200MB is free.
so, we a fast nvme, it could not work with small disk, but ok with big
disk.
I think that's why redhat use percent of fixed chunksize (that you can
configure depending of your storage speed)
You're right that way makes the most sense.
--- End Message ---
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
