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 E7A15C689 for ; Mon, 11 Apr 2022 12:39:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DE327324A for ; Mon, 11 Apr 2022 12:39:55 +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 id 599933241 for ; Mon, 11 Apr 2022 12:39:55 +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 27C7640843 for ; Mon, 11 Apr 2022 12:39:55 +0200 (CEST) From: Fabian Ebner To: pve-devel@lists.proxmox.com Date: Mon, 11 Apr 2022 12:39:50 +0200 Message-Id: <20220411103950.44029-1-f.ebner@proxmox.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.100 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 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: [pve-devel] [RFC container] api: create: disallow passing along existing disk for restore 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: Mon, 11 Apr 2022 10:39:56 -0000 For VMs, the plan is to allow passing along disk options (with the currently configured disks) for a restore operation to cause those disks to be kept instead of removing and restoring them from backup. Users might expect the same behavior for containers once that feature exists, but implementing it requires partial restore functionality and caution with the mount point structure, so for now, error out instead. This is a breaking change, but hopefully, the impact is limited: * Specifying a volume owned by a different container to have it (or rather its file system contents) be overwritten/merged during restore is a rather unusual use case. * Specifying a volume owned by the current container only worked if it was not referenced, because otherwise it would be removed when the container was destroyed just before restore_archive() is called. Signed-off-by: Fabian Ebner --- IMHO we cannot use the same syntax for VMs and containers if the behavior will be different, so if this change is not okay, I'll use an alternative to the one outlined above, for example, simply a list of drive keys to be left untouched. src/PVE/API2/LXC.pm | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm index ea4827f..5c8c83d 100644 --- a/src/PVE/API2/LXC.pm +++ b/src/PVE/API2/LXC.pm @@ -349,6 +349,11 @@ __PACKAGE__->register_method({ if ($mountpoint->{type} ne 'volume') { # bind or device die "Only root can pass arbitrary filesystem paths.\n" if !$is_root; + } elsif ($restore && $volid !~ $PVE::LXC::NEW_DISK_RE) { + raise_param_exc({ + $ms => "cannot specify existing disk for restore - use : ". + "syntax to allocate a new disk instead\n", + }); } else { my ($sid, $volname) = PVE::Storage::parse_volume_id($volid); &$check_and_activate_storage($sid); -- 2.30.2