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

[DERUMIER, Alexandre]

Hi Tiago,
Sorry I was super busy theses last weeks.
I don't have read your code yes, but first reponses to your questions:


>>Some problems and questions:
>>- Thin provisioning is currently hardcoded for drives that have a
>>parent
>>  snapshot.
>>- The thin variable that is introduced in the drive config needs
>>  review before wider implementation.
>>- Consider making thin optional via snapshot prompt checkbox.
>>- Could eventually offer the option for all qcow2 disks on LVM.


The thin option should be defined at storage level,  as drive config is
generic for any storage.   
They are already a "thin" option in zfs storage plugin for example.

If user really need some vm with or without thin provisioning, he can
create 2 differents storage.


>>- Re-evaluate blockdev name generation: sha256 vs reversible
>>  encoding (like base64) to identify drives and allow offline
>>extends.
not possible because the blockdev is space limited (15char max).

I don't have read your code yet, but why do you need that ?

for offline extend, we can compare manually qcow2 size vs lvm size.
could be done at vm start for example

>>- Since all extend requests share the same queue, drives on different
>>  LVM storages must wait for their turn, even though actions on
>>  separate storages could run concurrently.

use 1 queue by storage ? 


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

I really don't known