public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Aaron Lauterer <a.lauterer@proxmox.com>
To: Fabian Ebner <f.ebner@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH container 0/2] Improve volume deactivation
Date: Thu, 2 Dec 2021 08:49:45 +0100	[thread overview]
Message-ID: <ffb5231a-2ab8-3a04-8e6a-a1e8d68a8c73@proxmox.com> (raw)
In-Reply-To: <0badc51b-ae20-d3e1-ede4-bf2e95dbb74f@proxmox.com>



On 12/2/21 08:40, Fabian Ebner wrote:
> Am 01.12.21 um 17:27 schrieb Aaron Lauterer:
>>
>>
>> On 12/1/21 11:12, Fabian Ebner wrote:
>>> Am 26.11.21 um 11:19 schrieb Aaron Lauterer:
>>>> While working on the reassign feature we (F.Ebner & I) discovered that
>>>> it is possible, mainly with RBD volumes, to get into situations where it
>>>> is not possible to remove that volume as an old orphaned RBD mapping
>>>> still exists.
>>>>
>>>> Mainly when converting a container on RBD storage to a template and when
>>>> adding a new MP to a container that is not running and reassigning that
>>>> MP right away to another container.
>>>>
>>>
>>> I feel like cleaning up such things should be the responsibility of the storage plugin itself. It knows best when a volume gets a new name and what needs to happen if there is still something using the old name around.
>>>
>>> For example, after a full clone, volumes from both containers will be active and then reassigning or converting to template will lead to the issue again. There are likely other places where we don't cleanly deactivate. Of course we could try and hunt them all down ;), but quoting from [0]:
>>>
>>> this is fundamentally how volume activation works in PVE - we activate (and skip the expensive parts if already activated) often, but are very careful about de-activating only where necessary (shared volumes when migrating) or clearly 100% right (error handling before removing a newly allocated volume for example).
>>>
>>> [0]: https://bugzilla.proxmox.com/show_bug.cgi?id=3756#c3
>>
>> Hmm okay yeah, definitely valid regarding the second patch. But the first one would still be valid AFAIU because I don't understand why we activate the volumes when creating a template for containers only, but not for VMs if we don't need to do anything in the volume. So not activating it in the first place would help at least in that case.
>>
> 
> Sorry, I didn't mean to imply that the patches were wrong, just wanted to point out that they don't fully address the issue.

No need to excuse yourself, I came across much meaner than I intended to. :) I'll have to think about how to handle the second patch better to avoid these issues of potentially deactivating a storage when we shouldn't.

>>>
>>>> Aaron Lauterer (2):
>>>>    template_create: remove volume activation
>>>>    apply_pending_mountpoint: deactivate volumes if not running
>>>>
>>>>   src/PVE/LXC.pm        | 2 --
>>>>   src/PVE/LXC/Config.pm | 2 ++
>>>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>>>




      reply	other threads:[~2021-12-02  7:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 10:19 Aaron Lauterer
2021-11-26 10:19 ` [pve-devel] [PATCH container 1/2] template_create: remove volume activation Aaron Lauterer
2021-11-26 10:19 ` [pve-devel] [PATCH container 2/2] apply_pending_mountpoint: deactivate volumes if not running Aaron Lauterer
2021-12-01 10:12 ` [pve-devel] [PATCH container 0/2] Improve volume deactivation Fabian Ebner
2021-12-01 16:27   ` Aaron Lauterer
2021-12-02  7:40     ` Fabian Ebner
2021-12-02  7:49       ` Aaron Lauterer [this message]

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=ffb5231a-2ab8-3a04-8e6a-a1e8d68a8c73@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