public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Fabian Ebner <f.ebner@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [RFC v10 qemu-server 6/7] api: support VM disk import
Date: Thu, 27 Jan 2022 11:43:37 +0100	[thread overview]
Message-ID: <1643279965.hlbmvc1uq3.astroid@nora.none> (raw)
In-Reply-To: <3dc0288b-9fad-669a-9076-3e011da6e575@proxmox.com>

On January 27, 2022 9:21 am, Fabian Ebner wrote:
> Am 26.01.22 um 13:42 schrieb Fabian Grünbichler:
>> 
>> that way we can skip deactivation altogether (it's only relevant for
>> shared storages that require it for migration, and by locking the owning
>> VM and having a requirement for it to be on the same node at import-time,
>> no migration can happen in parallel anyway..). or we could deactivate if
>> an owning VM exists and is not running, like we do at the end of full
>> clones.
> 
> Sounds good. We actually only deactivate at the end of full clone if the
> clone was to a different target node. Since the new config moves to a
> different node then, deactivating the cloned volumes is required of
> course, but I /think/ deactivating the source volumes is actually
> optional (why should it depend on whether there's a target or not?).

yeah, that is a bit strange. the source can stay activated IMHO.

of course the target for full_clone needs to be de-activated if the 
clone is a cross-node operation, but that is never the case for 
importing (if we require owning VMs of source volumes to be on the 
current node), so we could also leave those activated or just do 
whatever we do in the regular creation path ;)




  reply	other threads:[~2022-01-27 10:44 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
2022-01-26 12:42     ` Fabian Grünbichler
2022-01-27  8:21       ` Fabian Ebner
2022-01-27 10:43         ` Fabian Grünbichler [this message]
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=1643279965.hlbmvc1uq3.astroid@nora.none \
    --to=f.gruenbichler@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal