From: Fabian Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [RFC v10 qemu-server 6/7] api: support VM disk import
Date: Wed, 26 Jan 2022 12:40:38 +0100 [thread overview]
Message-ID: <a927af07-2f95-caa1-7ce6-f2b16b17dc11@proxmox.com> (raw)
In-Reply-To: <20220113100831.34113-8-f.ebner@proxmox.com>
Am 13.01.22 um 11:08 schrieb Fabian Ebner:
> +
> + if (my $source = delete $disk->{'import-from'}) {
I'm adding a comment here in v11, because otherwise it's not clear where
volume activation happens:
+ # abs_filesystem_path also calls activate_volume when
$source is a volid
I'm also adding "The source should not be actively used by another
process!" to the description of the import-from parameter in v11.
> + $source = PVE::Storage::abs_filesystem_path($storecfg, $source, 1);
But there are a couple of issues here:
1. There's no protection against using a source volume that's actively
used by a guest/other operation. While it's not possible to detect in
general, I wonder if we should behave more like a full clone and lock
the owning VM?
1a. we could check if the volume is referenced in the config/snapshots,
but migration picks up everything, so it might be preferable not to.
1b. the volume might be configured in a VM that doesn't own it...
2. Related: avoiding concurrent activation of volumes on a shared LVM.
3. Related: cannot deactivate any volumes as the might be used by
something else.
4. abs_filesystem_path does not work for RBD when krbd=0, because the
plugin produces an "rbd:XYZ" path and the -f || -b check doesn't like
that. But full clone does work, passing the volid to qemu_img_convert
and that's likely what we should do here as well, when we are dealing
with an existing volid rather than an absolute path.
5. Add your own ;)
TL;DR: I'd like to behave much more like full clone, when we are dealing
with a volid rather than an absolute path.
> + my $src_size = PVE::Storage::file_size_info($source);
> + die "Could not get file size of $source" if !defined($src_size);
> +
> + my (undef, $dst_volid) = PVE::QemuServer::ImportDisk::do_import(
next prev parent reply other threads:[~2022-01-26 11:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 10:08 [pve-devel] [RFC v10 qemu-server/manager] API for disk import and OVF Fabian Ebner
2022-01-13 10:08 ` [pve-devel] [PATCH v10 qemu-server 1/7] schema: add pve-volume-id-or-absolute-path Fabian Ebner
2022-01-13 10:08 ` [pve-devel] [PATCH v10 qemu-server 2/7] parse ovf: untaint path when calling file_size_info Fabian Ebner
[not found] ` <<20220113100831.34113-3-f.ebner@proxmox.com>
2022-01-17 15:38 ` Fabian Grünbichler
2022-01-13 10:08 ` [pve-devel] [PATCH v10 qemu-server 3/7] api: add endpoint for parsing .ovf files Fabian Ebner
2022-01-13 10:08 ` [pve-devel] [PATCH v10 manager 1/1] api: nodes: add readovf endpoint Fabian Ebner
[not found] ` <<20220113100831.34113-5-f.ebner@proxmox.com>
2022-01-17 15:38 ` Fabian Grünbichler
2022-01-18 8:35 ` Fabian Ebner
2022-01-18 9:56 ` Fabian Grünbichler
2022-01-13 10:08 ` [pve-devel] [PATCH v10 qemu-server 4/7] image convert: allow block device as source Fabian Ebner
2022-01-13 10:08 ` [pve-devel] [RFC v10 qemu-server 5/7] schema: drive: use separate schema when disk allocation is possible Fabian Ebner
2022-01-13 10:08 ` [pve-devel] [RFC v10 qemu-server 6/7] api: support VM disk import Fabian Ebner
[not found] ` <<20220113100831.34113-8-f.ebner@proxmox.com>
2022-01-17 15:39 ` Fabian Grünbichler
2022-01-18 8:51 ` Fabian Ebner
2022-01-26 11:40 ` Fabian Ebner [this message]
2022-01-26 12:42 ` Fabian Grünbichler
2022-01-27 8:21 ` Fabian Ebner
2022-01-27 10:43 ` Fabian Grünbichler
2022-02-22 12:11 ` Fabian Ebner
2022-02-22 15:33 ` Fabian Grünbichler
2022-01-13 10:08 ` [pve-devel] [RFC v10 qemu-server 7/7] api: create disks: factor out common part from if/else Fabian Ebner
[not found] ` <<20220113100831.34113-1-f.ebner@proxmox.com>
2022-01-17 15:43 ` [pve-devel] [RFC v10 qemu-server/manager] API for disk import and OVF Fabian Grünbichler
2022-01-18 9:08 ` Fabian Ebner
2022-01-18 10:19 ` 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=a927af07-2f95-caa1-7ce6-f2b16b17dc11@proxmox.com \
--to=f.ebner@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox