[pve-devel] [RFC pve-storage/qemu-server 00/10] introduce thin provisioned drives to thick LVM storage

[DERUMIER, Alexandre]

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).