public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	"DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
	"pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Cc: "w.bumiller@proxmox.com" <w.bumiller@proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support
Date: Mon, 14 Jul 2025 13:46:47 +0200 (CEST)	[thread overview]
Message-ID: <144581945.5852.1752493607610@192.168.2.153> (raw)
In-Reply-To: <c6a065bb-1319-4a55-a3b0-0f9e12707c78@proxmox.com>


> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 14.07.2025 13:27 CEST geschrieben:
> 
>  
> Am 14.07.25 um 13:15 schrieb Fabian Grünbichler:
> >> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 14.07.2025 13:11 CEST geschrieben:
> >> Albeit, taking a step back, I'm not so sure if that really helps the user?
> >> I.e., what's something actionable they can do when seeing such a warning?
> >> Is it just to signal "this is a tech preview, be wary"? If, then I'd rather
> >> just signal that in the storage edit/add window.
> > 
> > for LVM, there is no new plugin or storage option, the plugin just gains
> > a new supported format and that has the experimental status. we could
> > guard that (like in the DirPlugin) with the external-snapshots flag, and
> > only allow qcow2 formatted volumes if that is set - that way, users would
> > need to "opt-in" to the experimental behaviour by creating a new storage
> > with that flag set. if we don't do that, then the only thing that we can
> > warn about is qcow2 *being used*, and there is no central place for that
> > as all existing LVM storages would get that support "over night" (once
> > they upgrade).
> 
> Ah okay, I actually thought it already worked that way when I saw the
> new flag getting added.
> 
> Might be indeed safer and more telling if we couple allowing it with that
> flag being set. We could then change the default of that flag for a future
> release, once we got more exposure and maybe improved UX polishing a bit
> and if we think it helps users. But it might not be bad to require an
> explicit decision for this.
> 
> If we really just enforce that check on volume creation, we could even
> allow changing the flag for an existing storage, as that would be a bit
> more convenient, and, more importantly, better than nudge the admin towards
> adding the same storage twice, which we do not support.

yes, for LVM the parameter would not need to be fixed, like for the DirPlugin.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2025-07-14 11:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 16:21 Alexandre Derumier via pve-devel
2025-07-10 15:09 ` [pve-devel] [PATCH FOLLOW-UP storage 1/3] helpers: make qemu_img* storage config independent Fabian Grünbichler
2025-07-10 15:09   ` [pve-devel] [PATCH FOLLOW-UP storage 2/3] helpers: move qemu_img* to Common module Fabian Grünbichler
2025-07-10 15:09   ` [pve-devel] [PATCH FOLLOW-UP storage 3/3] rename_snapshot: fix parameter checks Fabian Grünbichler
2025-07-14  6:34   ` [pve-devel] [PATCH FOLLOW-UP storage 1/3] helpers: make qemu_img* storage config independent DERUMIER, Alexandre via pve-devel
     [not found]   ` <6b7eaeb6af6af22ebdd034236e9e88bc1b5e1e3f.camel@groupe-cyllene.com>
2025-07-14 11:02     ` Fabian Grünbichler
2025-07-10 15:13 ` [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support Fabian Grünbichler
2025-07-10 15:46   ` DERUMIER, Alexandre via pve-devel
     [not found]   ` <c6c3457906642a30ddffc0f6b9d28ea6a745ac7c.camel@groupe-cyllene.com>
2025-07-10 16:29     ` Thomas Lamprecht
2025-07-11 12:04       ` DERUMIER, Alexandre via pve-devel
2025-07-14  6:25   ` DERUMIER, Alexandre via pve-devel
2025-07-14  8:18   ` DERUMIER, Alexandre via pve-devel
2025-07-14  8:42   ` DERUMIER, Alexandre via pve-devel
     [not found]   ` <26badbf66613a89e63eaad8b24dd05567900250b.camel@groupe-cyllene.com>
2025-07-14 11:02     ` Fabian Grünbichler
2025-07-15  4:15       ` DERUMIER, Alexandre via pve-devel
     [not found]   ` <719c71b1148846e0cdd7e5c149d8b20146b4d043.camel@groupe-cyllene.com>
2025-07-14 11:04     ` Fabian Grünbichler
2025-07-14 11:11       ` Thomas Lamprecht
2025-07-14 11:15         ` Fabian Grünbichler
2025-07-14 11:27           ` Thomas Lamprecht
2025-07-14 11:46             ` Fabian Grünbichler [this message]
2025-07-14 15:12   ` Tiago Sousa via pve-devel
     [not found] <20250709162202.2952597-1-alexandre.derumier@groupe-cyllene.com>
2025-07-16 15:15 ` Thomas Lamprecht
2025-07-17  8:01   ` DERUMIER, Alexandre via pve-devel
2025-07-17 14:49     ` Tiago Sousa via pve-devel
     [not found]     ` <1fddff1a-b806-475a-ac75-1dd0107d1013@eurotux.com>
2025-07-17 15:08       ` DERUMIER, Alexandre via pve-devel
     [not found]       ` <47b76678f969ba97926c85af4bf8e50c9dda161d.camel@groupe-cyllene.com>
2025-07-17 15:42         ` Tiago Sousa via pve-devel
     [not found]         ` <58c2db18-c2c2-4c91-9521-bdb42a302e93@eurotux.com>
2025-07-17 15:53           ` DERUMIER, Alexandre via pve-devel
2025-07-17 16:05           ` 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=144581945.5852.1752493607610@192.168.2.153 \
    --to=f.gruenbichler@proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    --cc=w.bumiller@proxmox.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