From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id CA45A82D0F for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 11:12:33 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AE1EDA988 for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 11:12:33 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id EE25AA979 for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 11:12:32 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id C297B44324 for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 11:12:32 +0100 (CET) To: pve-devel@lists.proxmox.com, Aaron Lauterer <a.lauterer@proxmox.com> References: <20211126101938.3992163-1-a.lauterer@proxmox.com> From: Fabian Ebner <f.ebner@proxmox.com> Message-ID: <b4049b97-2901-2ed7-3bf9-d9f28c83cb90@proxmox.com> Date: Wed, 1 Dec 2021 11:12:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20211126101938.3992163-1-a.lauterer@proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.158 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.977 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [lxc.pm, proxmox.com, config.pm] Subject: Re: [pve-devel] [PATCH container 0/2] Improve volume deactivation X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Wed, 01 Dec 2021 10:12:33 -0000 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 > 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(-) >