all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
	"Ciro Iriarte" <cyruspy@gmail.com>,
	pve-devel@lists.proxmox.com
Subject: Re: [RFC storage, qemu-server] offload full/live clone to storage backend
Date: Wed, 8 Jul 2026 10:17:31 +0200	[thread overview]
Message-ID: <90aae63f-8d67-4a26-ab6b-ed32fd1537ce@proxmox.com> (raw)
In-Reply-To: <1783430000.wo44ge3ggk.astroid@yuna.none>

Adding on top of Fabian's feedback:

Am 07.07.26 um 3:48 PM schrieb Fabian Grünbichler:
> On June 30, 2026 9:20 pm, Ciro Iriarte wrote:
>> -------------------------------
>> - Add an optional plugin method, copy_image($scfg, $storeid,
>>   $src_volname, $vmid, $dst_format, $opts), that allocates and copies
>>   on the backend atomically and returns the new volname. Base class
>>   returns undef (unsupported), so existing plugins are unaffected --
>>   the driver is the sole source of the capability.

I think the base class should die, because if it doesn't advertise the
feature, the method should never be reachable anyways.

>> Online offload runs only when the freeze succeeds, giving an
>> FS-consistent copy; if there is no agent or the freeze fails, fall back
>> to drive-mirror. This needs no separate switch -- the same copy-offload
>> option governs it, and the freeze requirement keeps it from ever
>> producing a crash-consistent copy silently.
> 
> I think the question of how to incorporate freeze for cloning running
> VMs is a bit orthogonal? atm we don't freeze, so there is no cross-disk
> consistency when cloning a running VM, other than that provided by the
> mirror blockjob.

No, we do freeze when cloning a running VM:
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=src/PVE/QemuServer/BlockJob.pm;h=921f046cd9ad917a1e365bd152cb250d656beec4;hb=HEAD#l168

I'm in favor of the bitmap-mirroring approach Fabian suggested, so in
the end, it would just use the existing BlockJob.pm mirror code for
completion.

>>
>> Out of scope
>> ------------
>> - Cross-storage and format-converting clones (inherently
>>   host-mediated).
> 
> agreed. cross-storage could potentially be a follow-up, and we might
> want to account for it in the copy_image signature/parameters?

I think we'd need an abstraction similar to
volume_{export,import}{,formats} so that plugins don't deal with
internal information from other plugins?




  reply	other threads:[~2026-07-08  8:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 19:20 [RFC storage, qemu-server] offload full/live clone to storage backend Ciro Iriarte
2026-07-07 13:48 ` Fabian Grünbichler
2026-07-08  8:17   ` Fiona Ebner [this message]
2026-07-08  8:43     ` 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=90aae63f-8d67-4a26-ab6b-ed32fd1537ce@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=cyruspy@gmail.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