Re: [RFC storage, qemu-server] offload full/live clone to storage backend

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On July 8, 2026 10:17 am, Fiona Ebner wrote:
> 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.

I agree, it's also more consistent with existing code

>>> 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

ah, thanks, missed that.

> 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.

but that sitll applies :)

>>>
>>> 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?

I guess a valid baseline assumption is that offloaded copies can only
ever occur between two storage instances of the same plugin type? how
the plugin then decides that the two instances can be used for copying
or not is up to the plugin (e.g., zfs can send/recv locally, a storage
appliance might have a copy feature between namespaces, but not
between storage pools or appliances, ..).

volume_export/import can be split like that because we lower to some
transport format, but that is not possible for offloading, which is
opaque from PVE's point of view..