public inbox for pve-devel@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 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