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 445E0DA62 for ; Tue, 19 Apr 2022 11:54:31 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 42187268BF for ; Tue, 19 Apr 2022 11:54:31 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 4C500268B6 for ; Tue, 19 Apr 2022 11:54:30 +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 2A2D0421C5 for ; Tue, 19 Apr 2022 11:54:30 +0200 (CEST) Date: Tue, 19 Apr 2022 11:54:23 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20220411103950.44029-1-f.ebner@proxmox.com> In-Reply-To: <20220411103950.44029-1-f.ebner@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1650360047.hzaewxwuea.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.175 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: Re: [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: Tue, 19 Apr 2022 09:54:31 -0000 On April 11, 2022 12:39 pm, Fabian Ebner wrote: > 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. >=20 > 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. it might be a (valid, previously working) pattern used by some=20 orchestration tools? 1. allocate volume(s) using storage API or directly however 2. format volume(s) 3. create container referencing volume(s) from 1.) 2. can be skipped for storages like ZFS/dir subvols, but might be=20 needed instead of the new volume syntax when users want to experiment=20 with non-ext4 containers (there are some people out there that use XFS,=20 for example) or fine-tune the ext4 parameters or ... although I have to say, the existing behaviour is also a bit confusing=20 ;) maybe making it explicit via some additional option to differentiate - format and restore (like when allocating a new volume, but without the=20 alloc part) - keep existing volume as is, ignoring that part of the backup archive=20 (partial restore) - restore into existing volume (current behaviour/default?) default could then be switched on next major release, since arguably the=20 first two options are saner candidates than the current behaviour.. > Signed-off-by: Fabian Ebner > --- >=20 > 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. >=20 > src/PVE/API2/LXC.pm | 5 +++++ > 1 file changed, 5 insertions(+) >=20 > 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 =3D> "cannot specify existing disk for restore - use : ". > + "syntax to allocate a new disk instead\n", > + }); > } else { > my ($sid, $volname) =3D PVE::Storage::parse_volume_id($volid); > &$check_and_activate_storage($sid); > --=20 > 2.30.2 >=20 >=20 >=20 > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >=20 >=20 >=20