From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <h.duerr@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 09E3793E90
for <pve-devel@lists.proxmox.com>; Wed, 10 Apr 2024 10:56:17 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id D71BCA77B
for <pve-devel@lists.proxmox.com>; Wed, 10 Apr 2024 10:55:46 +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
for <pve-devel@lists.proxmox.com>; Wed, 10 Apr 2024 10:55:46 +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 EB8B043A99
for <pve-devel@lists.proxmox.com>; Wed, 10 Apr 2024 10:55:45 +0200 (CEST)
Message-ID: <bcaa86a0-8669-4322-aad7-caca2f0d2661@proxmox.com>
Date: Wed, 10 Apr 2024 10:55:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
=?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= <f.gruenbichler@proxmox.com>
References: <20231219140306.188937-1-h.duerr@proxmox.com>
<20231219140306.188937-3-h.duerr@proxmox.com>
<1706608112.tdnyjesknw.astroid@yuna.none>
Content-Language: en-US
From: =?UTF-8?Q?Hannes_D=C3=BCrr?= <h.duerr@proxmox.com>
In-Reply-To: <1706608112.tdnyjesknw.astroid@yuna.none>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.370 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_ASCII_DIVIDERS 0.8 Email that uses ascii formatting dividers and possible
spam tricks
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
Subject: Re: [pve-devel] [PATCH pve-storage v4 2/2] fix #1611: implement
import of base-images for LVM-thin Storage
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: Wed, 10 Apr 2024 08:56:17 -0000
On 1/30/24 11:00, Fabian Grünbichler wrote:
> On December 19, 2023 3:03 pm, Hannes Duerr wrote:
>> for base images we call the volume_import of the parent plugin and pass
>> it as vm-image instead of base-image, then convert it back as base-image
>>
>> Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
>> ---
>> src/PVE/Storage/LvmThinPlugin.pm | 50 ++++++++++++++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/src/PVE/Storage/LvmThinPlugin.pm b/src/PVE/Storage/LvmThinPlugin.pm
>> index 1d2e37c..96f619b 100644
>> --- a/src/PVE/Storage/LvmThinPlugin.pm
>> +++ b/src/PVE/Storage/LvmThinPlugin.pm
>> @@ -383,6 +383,56 @@ sub volume_has_feature {
>> return undef;
>> }
>>
>> +sub volume_import {
>> + my ($class, $scfg, $storeid, $fh, $volname, $format, $snapshot, $base_snapshot, $with_snapshots, $allow_rename) = @_;
>> +
>> + my ($vtype, $name, $vmid, $basename, $basevmid, $isBase, $file_format) =
>> + $class->parse_volname($volname);
>> +
>> + if (!$isBase) {
>> + return $class->SUPER::volume_import(
>> + $scfg,
>> + $storeid,
>> + $fh,
>> + $volname,
>> + $format,
>> + $snapshot,
>> + $base_snapshot,
>> + $with_snapshots,
>> + $allow_rename
>> + );
>> + } else {
>> + my $tempname;
>> + my $vg = $scfg->{vgname};
>> + my $lvs = PVE::Storage::LVMPlugin::lvm_list_volumes($vg);
>> + if ($lvs->{$vg}->{$volname}) {
>> + die "volume $vg/$volname already exists\n" if !$allow_rename;
>> + warn "volume $vg/$volname already exists - importing with a different name\n";
>> +
>> + $tempname = $class->find_free_diskname($storeid, $scfg, $vmid);
>> + } else {
>> + $tempname = $volname;
>> + $tempname =~ s/base/vm/;
> couldn't we simply do this part unconditionally, and then call the SUPER
> method? that one already checks whether $volname exists, does the same
> die/warn and then unsets $volname in case of a collision, so that
> alloc_image gets to pick a free one? then we just need to create_base on
> the returned $volid and be done, making this a very thin wrapper..
If we simply rename base-image-x to vm-image-x and pass it on to the parent
image, we may not be able to create a base image of the imported volume
vm-image-x, as there may already be a base-image-x, which we have not
checked
before.
The patch still applies on master
> but, I just realized a bigger issue with all of this code here - AFAICT
> nothing ensures the storage is actually locked, so two parallel
> imports (or an import racing with an alloc/..) could actually end up
> trying to use the same volname. but we don't want to hold the lock for
> the full duration of the import, just for the part covering the "find
> free slot -> alloc_image" time span. this is not limited to LVM, but
> properly handling it would require splitting up volume_import into two
> plugin methods (breaking the storage plugin ABI) which might not even
> work for all storage types.
>
Created a patch for this issue:
https://lists.proxmox.com/pipermail/pve-devel/2024-April/062581.html
>> + }
>> +
>> + ($storeid,my $newname) = PVE::Storage::parse_volume_id($class->SUPER::volume_import(
>> + $scfg,
>> + $storeid,
>> + $fh,
>> + $tempname,
>> + $format,
>> + $snapshot,
>> + $base_snapshot,
>> + $with_snapshots,
>> + $allow_rename
>> + ));
>> +
>> + $volname = $class->create_base($storeid, $scfg, $newname);
>> + }
>> +
>> + return "$storeid:$volname";
>> +}
>> +
>> # used in LVMPlugin->volume_import
>> sub volume_import_write {
>> my ($class, $input_fh, $output_file) = @_;
>> --
>> 2.39.2
>>
>>
>>
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>>
>>
>>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>