From: "Hannes Dürr" <h.duerr@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-storage v4 2/2] fix #1611: implement import of base-images for LVM-thin Storage
Date: Wed, 10 Apr 2024 10:55:45 +0200 [thread overview]
Message-ID: <bcaa86a0-8669-4322-aad7-caca2f0d2661@proxmox.com> (raw)
In-Reply-To: <1706608112.tdnyjesknw.astroid@yuna.none>
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
>
>
next prev parent reply other threads:[~2024-04-10 8:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 14:03 [pve-devel] [PATCH qemu-server/storage v4 0/2] " Hannes Duerr
2023-12-19 14:03 ` [pve-devel] [PATCH qemu-server v4 1/2] migration: secure and use source volume names for deactivation Hannes Duerr
2024-01-30 9:42 ` [pve-devel] applied: " Fabian Grünbichler
2023-12-19 14:03 ` [pve-devel] [PATCH pve-storage v4 2/2] fix #1611: implement import of base-images for LVM-thin Storage Hannes Duerr
2023-12-19 14:10 ` Lukas Wagner
2024-01-30 10:00 ` Fabian Grünbichler
2024-04-10 8:55 ` Hannes Dürr [this message]
2024-04-18 13:24 ` [pve-devel] applied: " Fabian Grünbichler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bcaa86a0-8669-4322-aad7-caca2f0d2661@proxmox.com \
--to=h.duerr@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal