From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 AF0E089AB for ; Wed, 16 Nov 2022 11:09:19 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8B6021D78C for ; Wed, 16 Nov 2022 11:08:49 +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 for ; Wed, 16 Nov 2022 11:08:48 +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 B147243D5B for ; Wed, 16 Nov 2022 11:08:48 +0100 (CET) Message-ID: <0b497cdf-5fc1-419e-38d1-abc0c3aa4aa6@proxmox.com> Date: Wed, 16 Nov 2022 11:08:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Content-Language: en-US To: Stefan Hrdlicka , pve-devel@lists.proxmox.com References: <20221115105526.3428334-1-s.hrdlicka@proxmox.com> <20221115105526.3428334-5-s.hrdlicka@proxmox.com> <94fa3244-7649-aa49-534b-0f1eebb5fab0@proxmox.com> <61cfcb3d-ceef-0325-4152-6e0a26d99be2@proxmox.com> From: Fiona Ebner In-Reply-To: <61cfcb3d-ceef-0325-4152-6e0a26d99be2@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: =?UTF-8?Q?0=0A=09?=AWL 0.028 Adjusted score from AWL reputation of From: =?UTF-8?Q?address=0A=09?=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 =?UTF-8?Q?Alignment=0A=09?=NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF =?UTF-8?Q?Record=0A=09?=SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH V3 qemu-server 4/6] add ignore-storage-errors for removing VM with missing storage X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2022 10:09:19 -0000 Am 15.11.22 um 15:22 schrieb Stefan Hrdlicka: > On 11/15/22 13:17, Fiona Ebner wrote: >> Am 15.11.22 um 11:55 schrieb Stefan Hrdlicka: >>>   @@ -2370,7 +2375,8 @@ sub destroy_vm { >>>       include_unused => 1, >>>       extra_keys => ['vmstate'], >>>       }; >>> -    PVE::QemuConfig->foreach_volume_full($conf, $include_opts, >>> $remove_owned_drive); >>> +    eval { PVE::QemuConfig->foreach_volume_full($conf, >>> $include_opts, $remove_owned_drive); }; >>> +    die "Couldn't remove one or more disks: $@\n" if $@ && >>> !$ignore_storage_errors; >> >> So, $removed_owned_drive already ignores all storage errors beside if >> PVE::Storage::path() fails right? Can't we just add an eval around that >> and be done? No need for a new ignore-storage-errors parameter. Most >> storage errors are already ignored even without that parameter right >> now! I don't think it's a big issue to start ignoring the few missing >> ones as well? > > Well I wasn't sure. Safe option was to tell the user that there is a > problem and then the user decides if something should be forced deleted. > But if you think this is fine without user input lets pretend this never > existed :). > When there are storage errors, the VM config is removed and the user is warned about failed volume removal, *except* when the storage errors are in path() (which can only happen if the storage is gone from the config or in very few plugins like RBD), where it leads to the VM config removal failing. But I don't see why errors in path() should be fundamentally different here and feel like we should just align the behavior for those too. After all, that was the intention behind the eval block + warning around vdisk_free() in commit 31b52247 ("destroy_vm: allow vdisk_free to fail") To make the warnings more visible, we can switch to log_warn() instead of plain warn. For containers, all storage errors just propagate right now (or?), so the new parameter can be fine there. We could also align the behavior with what we do for VMs instead (if we do that, it should be done for a point release), but we don't have to of course.