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 995A097DED for ; Wed, 6 Mar 2024 14:14:41 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6990017A68 for ; Wed, 6 Mar 2024 14:14:11 +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, 6 Mar 2024 14:14:10 +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 20464485DB for ; Wed, 6 Mar 2024 14:14:10 +0100 (CET) Message-ID: Date: Wed, 6 Mar 2024 14:14:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Proxmox VE development discussion , Fiona Ebner , Hannes Duerr References: <20240306104703.115366-1-h.duerr@proxmox.com> <1f999e2b-7ada-4978-9f40-27481a81bd3b@proxmox.com> From: Friedrich Weber In-Reply-To: <1f999e2b-7ada-4978-9f40-27481a81bd3b@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.079 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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 qemu-server 1/1] fix 1734: clone VM: if deactivation fails demote error to warning 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, 06 Mar 2024 13:14:41 -0000 On 06/03/2024 13:40, Fiona Ebner wrote: > Am 06.03.24 um 11:47 schrieb Hannes Duerr: >> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({ >> >> if ($target) { >> # always deactivate volumes - avoid lvm LVs to be active on several nodes >> - PVE::Storage::deactivate_volumes($storecfg, $vollist, $snapname) if !$running; >> + eval { >> + PVE::Storage::deactivate_volumes($storecfg, $vollist, $snapname) if !$running; >> + }; >> + my $err = $@; >> + if ($err) { >> + log_warn("$err\n"); >> + } >> PVE::Storage::deactivate_volumes($storecfg, $newvollist); > > We might also want to catch errors here. Otherwise, the whole clone > operation (which might've taken hours) can still fail just because of a > deactivation error. But when failing here, we shouldn't move the config > file (or the LV can get active on multiple nodes more easily). I think succeeding but not moving the config file when deactivating $newvollist fails sounds like it could lead to unexpected behavior. Right now, when running `qm clone 101 [...] --target node2` on node1 succeeds, one can be sure there will be an VM 101 on node2. But if we cannot deactivate $newvollist and thus don't move the config file, the command succeeds but VM 101 instead exists on node1 (correct me if I'm wrong), which may be confusing e.g. if the clone is automated. To avoid that, I'd lean towards keeping the behavior of failing the task if deactivating $newvollist fails. After all, at least in case of LVM not being able to deactivate because the device is in use, we just created $newvollist so hopefully nobody else should be accessing it.