From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.schauer@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 8AB259785A for <pve-devel@lists.proxmox.com>; Tue, 5 Mar 2024 14:13:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 62FCA84D9 for <pve-devel@lists.proxmox.com>; Tue, 5 Mar 2024 14:12:41 +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 for <pve-devel@lists.proxmox.com>; Tue, 5 Mar 2024 14:12: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 2B38241DCD for <pve-devel@lists.proxmox.com>; Tue, 5 Mar 2024 14:12:40 +0100 (CET) Message-ID: <3c974db2-6f9e-4b55-9cb1-ba7bba6a2120@proxmox.com> Date: Tue, 5 Mar 2024 14:12:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20240219111140.40722-1-f.schauer@proxmox.com> <20240219111140.40722-2-f.schauer@proxmox.com> <db712622-4884-42a7-ae9e-c7032a418892@proxmox.com> From: Filip Schauer <f.schauer@proxmox.com> In-Reply-To: <db712622-4884-42a7-ae9e-c7032a418892@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.101 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 #1905: Allow moving unused disks 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: Tue, 05 Mar 2024 13:13:11 -0000 After a bit of research, here is a more descriptive commit message: Allow moving unused disks to another storage In the past, moving unused disks to another storage was prohibited due to oversights in the handling of unused disks. This commit rectifies this limitation by allowing the movement of unused disks. Historical context: * 16 Sep 2010 r5164 qemu-server/pve2: The disknames sub was removed. * 17 Sep 2010 r5170 qemu-server/pve2: Unused disks were introduced. * 28 Jan 2011 r5461 qemu-server/pve2: The same disknames sub that was removed in r5164 was brought back. Since unused disks were not around yet in r5164 the disknames sub did not consider unused disks. * 6-8 Aug 2012 c1175c92..f91b2e45 qemu-server.git: Disk resize was introduced. In commit c1175c92 in sub qemu_block_resize unused disks were not taken into account and in commit 2f48a4f5 (8 Aug 2012) the resize API call was changed to only allow disks matching the ones in the disknames sub. Since sub disknames did not contain any unused disks, those were not allowed at all in the resize API call. * 27 May 2013 586bfa78 qemu-server.git: Disk move was introduced. The API call implementation borrowed heavily from disk resize, including the behaviour of not taking unused disks into account. Thus, unused disk could not be moved, which persists to this day. In summary, this behaviour was introduced because the handling of unused disks was overlooked and it was never changed. There is no inherent reason why unused disks should be restricted from being moved to another storage. These disks cannot use the qemu_drive_mirror, but they can still be moved with qemu_img_convert, the same way as any other disk of a stopped VM. On 19/02/2024 13:22, Thomas Lamprecht wrote: > Am 19/02/2024 um 12:11 schrieb Filip Schauer: >> Allow moving unused/detached disks to another storage. > this is a repetition of the commit subject, while that is on it's > own OK, I'd rather see a description about why this is OK to do, i.e., > why was the original check added, what changed since then, what are > the drawbacks, e.g., as the QEMU block-mirror cannot be used I imagine > only a limited set of source storage to target storage can be used > for this?