public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 2/2] pve6to7: storage content: ignore misconfigured unreferenced volumes
Date: Thu, 8 Jul 2021 09:37:24 +0200	[thread overview]
Message-ID: <a3b90fef-2cd0-971e-1682-16b4f9c96dfd@proxmox.com> (raw)
In-Reply-To: <1625729074.m9x7ql96rs.astroid@nora.none>

On 08.07.21 09:29, Fabian Grünbichler wrote:
> On July 7, 2021 12:22 pm, Fabian Ebner wrote:
>> If the same local storage is configured twice with content type
>> separation, migration in PVE 6 would lead to the volumes being
>> duplicated. As that would happen for every migration, such an issue
>> would likely be noticed already, and in PVE 7 such configuration is
>> not problematic for migration anymore. Also, misconfigured
>> unreferenced volumes are not an issue with respect to the upgrade
>> itself, just drop the check.
> 
> but those checks also catch storages that are misconfigured for which no 
> such inverse storage with opposite content type and otherwise identical 
> settings exists? we can't just drop them altogether?
> 
> we COULD skip them conditionally for storage pairs (same type, same 
> 'path'/pool/pool+mons/.., one with images on with rootfs), but such 
> setups are still wrong and not properly separated IMHO. and stuff like 
> dir-storage on-top of other dir-like storage with volumes stored in the 
> same path are not really "detectable" in a reliable and cheap fashion 
> and should really be fixed by the user (e.g., by moving the dir storage 
> into a non-confusable sub-dir of the backing storage).

as long as the content types are non-overlapping it is separated though,
a user in the forum had a GlusterFS entry used by QEMU directly and that
GlusterFS mounted on the system for containers, both added as storage but
strictly separating content types.

I.e., an OK setup where changing anything could actually lead to breakage,
but the warning as it was did not really reflect that. If that can be
improved then OK, but as is it was just not worth for what I perceive as
rather small in-practice risk of that change.




  reply	other threads:[~2021-07-08  7:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 10:22 [pve-devel] [PATCH manager 1/2] pve6to7: storage content: skip scanning storage if shared Fabian Ebner
2021-07-07 10:22 ` [pve-devel] [PATCH manager 2/2] pve6to7: storage content: ignore misconfigured unreferenced volumes Fabian Ebner
2021-07-08  7:29   ` Fabian Grünbichler
2021-07-08  7:37     ` Thomas Lamprecht [this message]
2021-07-08  7:23 ` [pve-devel] [PATCH manager 1/2] pve6to7: storage content: skip scanning storage if shared Fabian Grünbichler
2021-07-08  7:26 ` [pve-devel] applied: " Thomas Lamprecht

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=a3b90fef-2cd0-971e-1682-16b4f9c96dfd@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pve-devel@lists.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