From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id F39771FF187 for ; Mon, 8 Sep 2025 22:08:42 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 681631A101; Mon, 8 Sep 2025 22:08:43 +0200 (CEST) Date: Mon, 8 Sep 2025 16:08:01 -0400 To: Fiona Ebner , Proxmox VE development discussion References: In-Reply-To: MIME-Version: 1.0 Message-ID: List-Id: Proxmox VE development discussion List-Post: From: Andrei Perapiolkin via pve-devel Precedence: list Cc: Andrei Perapiolkin X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: , List-Unsubscribe: , List-Archive: Reply-To: Proxmox VE development discussion List-Help: Subject: Re: [pve-devel] Handling 'path' requests during VM deletion Content-Type: multipart/mixed; boundary="===============8428890477319323216==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" --===============8428890477319323216== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.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 14FE6D58E1 for ; Mon, 8 Sep 2025 22:08:42 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E3D7E1A064 for ; Mon, 8 Sep 2025 22:08:11 +0200 (CEST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 8 Sep 2025 22:08:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=open-e.com; s=s1-ionos; t=1757362083; x=1757966883; i=andrei.perepiolkin@open-e.com; bh=DBt3CDLW2iHb+tjMq58z9NDZ0mxjFV3aLXgL4YFv/NA=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=1g7wPqdXSYLa25bDr3FunM1P4C8GzUZrp++G1HuIrREYJNzYyzng05tGy1aIqzTW osQMOcrI8U8vU3kSvU0qF6xEO+auu7sQFD8dfNhx7F/HAXeSYHpSlEk//hBu3CxuI Pyo5BSXQtKdc/ONJVcVSRxCJoA6CKBDVRvHpQyJBAqZIvEz63suGhxRy4HJlQ2l7U JgbYpgMB+q6nSHP61w4N5e9x7xSrKiIDuIJjp7baWroIYDoyqnPSCLKbTDhXz8SVJ 3XEUjZOSR854WJNFp/CJBoj7w0OC1rcZKKjoZ+lmDxwxL4qfK7M2b4SXJ+/JcJCUk moX1t287ZQ/9gHTKJQ== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from [10.137.0.75] ([149.102.246.31]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MYLqs-1uzZmj2m7G-00UKAz; Mon, 08 Sep 2025 22:08:03 +0200 Message-ID: <472f7cfb-f105-4e71-834f-8c3352ee82df@open-e.com> Date: Mon, 8 Sep 2025 16:08:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] Handling 'path' requests during VM deletion To: Fiona Ebner , Proxmox VE development discussion References: Content-Language: en-US From: Andrei Perapiolkin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:03Hh9R31kUDJxuONYO2dEbZiIvuyRLlxeMPMr+/BLF7L9a56wwj TIbqSPcZSw2rF6fB1KkvnDbhOSwU6BoIo9HtPNctJd91wFaDJiuDwgQginFhhjtSvnUWuB2 ufEZdX0Hr9yiR9e3px6/mSyrFUjSZa75aC+TfOtQ+56BZQxd86Bd1kplS/I0G211DZvl7ZU vo5AzQbRfCZrQDcgD3F3A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:SuUwg+HRpjM=;ik5rA5/Xmj4LHaKLYcQaonVF1y4 SSuREjxcnykGuP/d7vzGA0keRd5Otahrl2vHZe9YH16ZC8QNDUmb3xlExVxgThv0Q6iU2WR/Q WeaTgehLnExCOv1/qlaBal3tvj5rWSPu2q3APiOQhEs1txp/z6SW/zQ8grWnp1C34NQFDg4pb /T/yT6heTzkuhsQu96GTs9SrDf37T0ORZ/AYxXtsBmFWYdvv4Zo7NEAjmsrCHOJ6o9tTTrcYo bHb/29AUHG80sszogmsqzRpY5o9WcmUX+/Mp6NsV6ePlulWmDum3wQLvQb8o5SIqIgzj7JJeZ 35560Vub+KI7HiVHpGGQPX0W59KIwQ08k1PUCQ+1CBJ+QwQN+VAn1gFnBE/Q4nPj3pG/zYyoA fw2rG73frP5yvGNjXPPZsgeC4d8MF6hbzombvt/DPBrt9pKkNpVPe2mtDvXq+mAdxDcDSYmnY ifXzAhTz3lDjmouvchw9rhh3i0ImJaQ1gd3NNfRekz5DdfkBcBcenu9tKYxaD/AF1/GhOovif sxBEOUTxtvFTiHYqJI/L6Bzlj8dPvKusOD0/SHC6FSqIQtvCi4JmqS7wpt8ratfB8TQM1N10i xgbTQjSly9LX9LxqXe3fPOR2q5uITYBqZP0CPEYA7yqRuzhecPWIBL7MVE5kV4QhFLrZLkGQg ieNg/0UYNAaxyWukMXEQHpe7U3+qlzvTruxdwn8LfYLnUn60XEUGBC7klIQXnl2U9T7+QyLuO MfYQc/+lpApmP4+odbesnV41xuHbizhFwK2qQbiCmvQDUBpMIYqu7LtsARRNOFhfdRL6Nydnz T7LQw/SrhA4YJBPB+MRP8ljrS2UXVj6P7/70kBasD+gnFcJZHY9d5Z4uDU5f8wmy5WHfk9pn5 5j2owcfjLneK7QFu4m4vGjn8fMZfsQqlGIYl0xmDsE+uAQNvjqQVl81iPXV/Y4MIG5kJ+YmLA hT/oWld4+JO3FrD85z2sprhkLj0iJsxVxRE4Vxh9vQIS+11qYVsThApODzynZzEVGlPmujhoo SDv+XGDVxk+5I+xdW76Ju/TaUDdFH2mSRjNb+Te/9zlWNt+pFaOB9xggBa1BSsrv+09LW7dxo 7Ps7+ObRmJY0+7OUTs74o6zqQJ3e3cIA93qBg/B3cql9yqkdB2KVgOVT3mlzYCdi6yedQUOdi 85/D4i0w7UE2LVhxPg+UuEZxM/bq0mhe5oVxdbaMDMLkwd2r12uaVGp//dX225U4FmHsE57E2 955mbAwsiLapjn7DvldmKbu3hqaPcv2F3WkUGNaGl8CmodfqyYocZ3p+dr119vJz9fdTbqcj8 uKe6436Gi1qolfzY7AdbLmKKrR1FenMFCCZqfSk23flP//dAMWUHK94IUIQ2Eake/1n3o8bzC 5LOIc6hROmEabpLgtZUx0azEXreSyiNf7ttPFkI8bo/5ZIjgvd6LUIh+z/SHx4Zuka2rFkAgE eHqovQR2321mkEjgwqrvd93p9vCwx4Yw8lQ5tcbHnN0BGSO2O/meqNc2hBE9cIUzLZ1NwPzje i0Bq1s9YaLC4LMTcYMCIZmQGO/NLHZyQOXdhjaL0QBY+1ctVfXpAmT2ehpAKTisFcz3mt0++x nYuTE8l+DOkLWYzY3Ge94b9En1pv/OQvDbUoRerZBqJs8kLn9g0paZfQPYKZQFk9mBlYUG69p K2SpP8nTm8LRjClbDP7vkJnLHihIfLJSg3V+ciLWALHi2BUT26mmjLmnf1Go5m1L4e1XgKHtt vzLS4bTntQj/3sWcujIelbaVWDes2od85PB/NlLzVQSI4PgMaVn/5QQOWXsMKhGjmyVWyc71u MXRb X-SPAM-LEVEL: Spam detection results: 0 AWL 0.002 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust RCVD_IN_HOSTKARMA_BL 1.5 Sender listed in HOSTKARMA-BLACK RCVD_IN_MSPIKE_H4 -0.01 Very Good reputation (+4) RCVD_IN_MSPIKE_WL -0.01 Mailspike good senders RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Hi Fiona, Thank you for your reply. I have added a bug report: https://bugzilla.proxmox.com/show_bug.cgi?id=3D= 6776 I also decided to return an empty string ('') for volumes that do not exis= t. My reasoning is that if I return any path that might actually exist,=20 some parts of the Proxmox system could try to open, read, or write to=20 this "file,"=C2=A0 unintentionally creating it. This could corrupt the server=E2=80=99s file system, or consume disk space= if=20 the server has limited local storage =E2=80=94 for example, when the opera= tion=20 involves cloning a multi-terabyte data block. I would like to hear your opinion regarding this conclusion. Is it acceptable, or should I re-evaluate it? Best regards, Andrei Perepiolkin On 8/14/25 11:11, Fiona Ebner wrote: > Hi Andrei, > > Am 07.08.25 um 11:39 PM schrieb Andrei Perapiolkin via pve-devel: >> Hi, >> >> VM deletion retries 'path'/'free_image' for already-removed volumes; ex= pected plugin behavior on missing volumes is unclear. >> >> When deleting a VM with multiple attached volumes, Proxmox deletes volu= mes sequentially (one at a time) and >> updates the VM record only after all deletions complete. > Could you please file a bug for this: https://bugzilla.proxmox.com ? > >> If a volume deletion fails mid-process (e.g., network error), the VM re= cord is not updated even though some volumes may have been successfully re= moved. >> A subsequent delete attempt repeats all operations, including 'path' (a= nd 'free_image') calls for volumes that were already deleted. >> >> >> What is the proper response to 'path' and 'free_image' calls for a volu= me that no longer exists? >> For path, should the call fail (e.g., 'die'), succeed with an empty str= ing, or return a 'storage path'? > (Most) implementations of path() for plugins shipped by us [0] do not do > any I/O at all and thus don't check if the image actually exist. So you > can return the path, even if the volume does not exist. > > Some of our implementations of free_image() fail if the volume does not > exist, some do not. Nothing should break if you indicate success when > free_image() is called and the image does not exist. > > [0]: > https://git.proxmox.com/?p=3Dpve-storage.git;a=3Dtree;f=3Dsrc/PVE/Storag= e;h=3D26012be26cb3c24515e99a02e7ad438f29c81646;hb=3DHEAD > > Best Regards, > Fiona > --===============8428890477319323216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============8428890477319323216==--