public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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: Wed, 12 Nov 2025 15:20:16 +0000	[thread overview]
Message-ID: <mailman.1019.1762960826.362.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <mailman.52.1760700908.362.pve-devel@lists.proxmox.com>

[-- Attachment #1: Type: message/rfc822, Size: 14173 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: Wed, 12 Nov 2025 15:20:16 +0000
Message-ID: <1682e2358c7051877ca1dafaa2adb9a207886eef.camel@groupe-cyllene.com>

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





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

  reply	other threads:[~2025-11-12 15:19 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 [this message]
     [not found] ` <1682e2358c7051877ca1dafaa2adb9a207886eef.camel@groupe-cyllene.com>
2025-11-13 14:09   ` DERUMIER, Alexandre via pve-devel

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.1019.1762960826.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal