From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <s.hrdlicka@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 489898AAD5 for <pve-devel@lists.proxmox.com>; Fri, 5 Aug 2022 14:06:02 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3CCE22F0E5 for <pve-devel@lists.proxmox.com>; Fri, 5 Aug 2022 14:05:32 +0200 (CEST) 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 for <pve-devel@lists.proxmox.com>; Fri, 5 Aug 2022 14:05:31 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 613B642F03 for <pve-devel@lists.proxmox.com>; Fri, 5 Aug 2022 14:05:31 +0200 (CEST) Message-ID: <0b133104-f481-c72c-5cf7-b3b0fe8c2762@proxmox.com> Date: Fri, 5 Aug 2022 14:05:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US To: pve-devel@lists.proxmox.com References: <20220720144949.1568323-1-s.hrdlicka@proxmox.com> <e53cf62c-55fc-6b8e-cc78-3ad19cdee77e@proxmox.com> <20220725133118.rd75siwly4aoih4j@casey.proxmox.com> From: Stefan Hrdlicka <s.hrdlicka@proxmox.com> In-Reply-To: <20220725133118.rd75siwly4aoih4j@casey.proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.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 -0.001 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH pve-container 0/3] fix #3711: delete LXC container with missing storage 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: Fri, 05 Aug 2022 12:06:02 -0000 On 7/25/22 15:31, Wolfgang Bumiller wrote: > On Mon, Jul 25, 2022 at 12:40:21PM +0200, Fiona Ebner wrote: >> Am 20.07.22 um 16:49 schrieb Stefan Hrdlicka: >>> The patch adds a new option 'force-remove-storage' that stops pct >>> destory from dying if the storage is not available. This also adds a >>> menu option for the delete dialog of containers. >>> >> >> VMs are also affected, so we probably want the new option there too. >> Although for VMs, it is possible to work around the issue by detaching >> all non-existing disks first. > > Yeah, this is really mostly an issue with the `rootfs`, since you cannot > detach or remove it, so I think we could have this for VMs just for > consistency's sake. > >> So slightly related: when detaching a disk and the owner of the volume >> is different (it also happens when the storage/disk does not exist >> anymore), we drop the disk for VMs, but we register it as unused for >> containers. Should we make that consistent? > > Yeah I think consistency makes more sense there as well. Consistent in that case would be that we also register the disk as unused for the VMs as well, instead of dropping it?