[pve-devel] [pve-dev] Storage assisted copy feature for Proxmox storage plugin

[Andrei Perapiolkin]

Hi Fabian,

Use Cases:

1. Full volume copy performed on the same storage (storage_id).

2. New volume creation from a snapshot on the same storage (storage_id).

Currently, the full clone operation involves attaching both the source 
and destination volumes to a Proxmox node and transferring data through it.
This method is network-intensive, impacting both the send and receive 
channels of the Proxmox and storage nodes.
As a result, it can negatively affect VMs performing I/O operations on 
the storage.

Expanding 'volume_export' and 'volume_impor't may not be the best 
approach. Instead, introducing a new method—such as 'volume_copy' or 
'copy_image'—could be more appropriate. This method would be triggered 
when both the source and destination share the same storage_id, 
optimizing the copy process. It would be especially beneficial for 
ZFS-based storages, particularly those with complex rollback mechanisms. 
With this approach, users could perform fast, full clones without 
impacting network performance. Best regards, Andrei Perepiolkin


On 10/3/25 02:42, Fabian Grünbichler wrote:
> On October 3, 2025 2:15 am, Andrei Perapiolkin via pve-devel wrote:
>> Hi,
>>
>> Can the honorable community help me find an elegant way for
>> volume_import to identify the source volume origin type and name?
>>
>> I'm investigating this to implement storage-assisted copy (i.e.,
>> performing the volume copy entirely on the storage side).
>>
>> My initial assumption was that this could be achieved by defining custom
>> volume_export and volume_import functions.
>> However, may be there is a better way to do storage assisted copy.
> volume_export and volume_import are only used for a few specific cases
> (mainly offline migration of local disks, and offline remote migration
> of disks).
>
> for those you could define your own transport format that includes or
> just contains the relevant metadata to do a storage side copy - it would
> only be selected if the storage for the source and target volume both
> say they support that particular format.
>
> I assume your storage is shared, so you'd be more interested in the
> move disk/full clone case, which currently uses either a mirror block
> job (if the VM is running), qemu-img convert (if the VM is not running)
> or rsync (for container volumes). These mechanisms are all not
> extensible at the moment for storage plugins.
>
> Maybe you could describe for which tasks you would see a clear benefit
> for extending the interface to allow a storage plugin to provide a "copy
> volume A into volume B storage side" - for the live move disk it might
> be hard (without dirty bitmap trickery like we use for replication, but
> that might be an option?), for the offline moves it would probably be
> possible to somehow special case this and let plugins opt in, we've
> discussed this ourselves in the past..
>
>> P.S.
>> Just found out about
>> https://pve.proxmox.com/wiki/Storage_Plugin_Development:_Writing_a_Storage=
>> _Plugin_for_SSHFS
>> This is grate!
>> Many thanks for posting this article!
> Great that it found its intended audience! :)
>