From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <a.lauterer@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 7E8FD82F38 for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 17:28:12 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 696DB1072E for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 17:27:42 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 64A7810721 for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 17:27:40 +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 3A29744144 for <pve-devel@lists.proxmox.com>; Wed, 1 Dec 2021 17:27:40 +0100 (CET) Message-ID: <b5c62567-72ba-1af4-734c-79690578bf3a@proxmox.com> Date: Wed, 1 Dec 2021 17:27:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Fabian Ebner <f.ebner@proxmox.com>, pve-devel@lists.proxmox.com References: <20211126101938.3992163-1-a.lauterer@proxmox.com> <b4049b97-2901-2ed7-3bf9-d9f28c83cb90@proxmox.com> From: Aaron Lauterer <a.lauterer@proxmox.com> In-Reply-To: <b4049b97-2901-2ed7-3bf9-d9f28c83cb90@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.066 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. [config.pm, proxmox.com] 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 16:28:12 -0000 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. > >> 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(-) >>