From: "Hannes Dürr" <h.duerr@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-storage] fix #1611: implement import of base-images for LVM-thin Storage
Date: Mon, 13 Nov 2023 14:13:31 +0100 [thread overview]
Message-ID: <d86ee66a-1dd1-41c1-bf63-2e9d5c1c6ccb@proxmox.com> (raw)
In-Reply-To: <5f42156e-a80c-411b-9ce9-782fa72ffb61@proxmox.com>
On 11/3/23 11:39, Fiona Ebner wrote:
[...]
> This essentially duplicates most of the same function in the parent
> plugin, i.e. LVMPlugin. What you can do to avoid it, is introduce new
> helper functions for the parts that are different, call those in
> LVMPlugin's implementation and overwrite the helpers appropriately in
> LvmThinPlugin. Then call the parent plugin's function here and do the
> base conversion at the end.
yes makes sense to work with the LVMPlugin implementation
rather then duplicating all the code, good point.
>> +sub volume_import {
> (...)
>
>> +
>> + # Request new vm-name which is needed for the import
>> + if ($isBase) {
>> + my $newvmname = $class->find_free_diskname($storeid, $scfg, $vmid);
>> + $name = $newvmname;
>> + $volname = $newvmname;
>> + }
> So this is one of the parts that needs to be different.
>
> You could also just set the name to undef and alloc_image will call
> find_free_diskname itself. Might be slightly nicer and avoids a new
> find_free_diskname call. We could also set the name to vm-XYZ-disk-N
> instead of base-XYZ-disk-N for the allocation I think. Or the whole
> function could even be:
>
> 1. check if base
> 2. check if already exists/rename allowed
> 3. call parent plugin's volume_import function passing along
> vm-XYZ-disk-N (or undef if it should be renamed) instead of base-XYZ-disk-N
> 4. if it was a base image, handle the conversion to base image
>
> Then there's no need for new helpers either. But this is just a sketch
> of course, didn't think through all details. What do you think?
that sounds good so far, but you can't get around the
"find_free_diskspace()" call, can you ?
Not specifying a name leads to an error in the volume_import of the LVM
plugin,
because without a name no plugin can be parsed and to get a new name in
the style
of "vm-XYZ-disk-N" you need "find_free_diskspace()" to make sure that
the name does not yet exist,
or am I missing something ?
So I'd propose:
1. check if base
2. check if already exists/rename allowed
3. call parent plugin's volume_import function passing along
vm-XYZ-disk-N generated with "find_free_diskspace(), instead of
base-XYZ-disk-N
4. if it was a base image, handle the conversion to base image
next prev parent reply other threads:[~2023-11-13 13:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 11:59 Hannes Duerr
2023-11-03 10:39 ` Fiona Ebner
2023-11-13 13:13 ` Hannes Dürr [this message]
2023-11-13 13:39 ` Fiona Ebner
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=d86ee66a-1dd1-41c1-bf63-2e9d5c1c6ccb@proxmox.com \
--to=h.duerr@proxmox.com \
--cc=f.ebner@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.