public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Aaron Lauterer <a.lauterer@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server v2 3/6] migration: fail when aliased volume is detected
Date: Wed, 24 May 2023 16:40:29 +0200	[thread overview]
Message-ID: <32149d4f-c698-b4be-529f-1f6f764cc870@proxmox.com> (raw)
In-Reply-To: <f326e48d-b65d-c8dc-2c8f-8676324d796c@proxmox.com>



On 5/22/23 16:17, Fiona Ebner wrote:
> Am 12.05.23 um 14:40 schrieb Aaron Lauterer:
>> Aliased volumes (referencing the same disk image multiple times) can
>> lead to unexpected behavior in a migration.
> 
> Not only migration, but snapshots, storage locking, etc. Should we
> actually care here? I still think it is rather something that people
> should be made aware for the storage layer. Maybe a big enough warning
> in the documentation is enough?
> 
> Since it's not only migration, should we add a warning during VM startup
> instead/additionally?
> 

I guess a warning in the docs would be a low-hanging fruit -> added to my TODO.
Snapshots should just fail the second time as we already have one with the same 
name, right?

AFAIU storage migration is a case where an aliased volume can lead to very 
unexpected behavior, like storages running full. So a check and die is probably 
a good idea.

An additional warning during startup could probably be a good idea. In that 
case, the checks should probably be factored out into their own method so we can 
call it from the start as well. Though that would probably mean, another round 
of iterating through the config instead of inlining it.





  reply	other threads:[~2023-05-24 14:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12 12:40 [pve-devel] [PATCH qemu-server, container v2 0/6] migration: don't scan all storages, fail on aliases Aaron Lauterer
2023-05-12 12:40 ` [pve-devel] [PATCH qemu-server v2 1/6] migration: only migrate disks used by the guest Aaron Lauterer
2023-05-22 11:59   ` Fiona Ebner
2023-05-24 15:00     ` Aaron Lauterer
2023-05-12 12:40 ` [pve-devel] [PATCH qemu-server v2 2/6] tests: add migration test for pending disk Aaron Lauterer
2023-05-22 14:02   ` Fiona Ebner
2023-05-12 12:40 ` [pve-devel] [PATCH qemu-server v2 3/6] migration: fail when aliased volume is detected Aaron Lauterer
2023-05-22 14:17   ` Fiona Ebner
2023-05-24 14:40     ` Aaron Lauterer [this message]
2023-05-25  8:14       ` Fiona Ebner
2023-05-25  8:15   ` Fiona Ebner
2023-05-12 12:40 ` [pve-devel] [PATCH qemu-server v2 4/6] tests: add migration alias check Aaron Lauterer
2023-05-22 14:25   ` Fiona Ebner
2023-05-24 14:41     ` Aaron Lauterer
2023-05-12 12:40 ` [pve-devel] [PATCH container v2 5/6] migration: only migrate volumes used by the guest Aaron Lauterer
2023-05-22 15:00   ` Fiona Ebner
2023-05-12 12:40 ` [pve-devel] [PATCH container v2 6/6] migration: fail when aliased volume is detected Aaron Lauterer

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=32149d4f-c698-b4be-529f-1f6f764cc870@proxmox.com \
    --to=a.lauterer@proxmox.com \
    --cc=f.ebner@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