From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [pve-dev] Storage assisted copy feature for Proxmox storage plugin
Date: Fri, 03 Oct 2025 08:42:25 +0200 [thread overview]
Message-ID: <1759473060.6ll3polgmk.astroid@yuna.none> (raw)
In-Reply-To: <mailman.625.1759450547.390.pve-devel@lists.proxmox.com>
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! :)
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
prev parent reply other threads:[~2025-10-03 6:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 0:15 Andrei Perapiolkin via pve-devel
2025-10-03 6:42 ` Fabian Grünbichler [this message]
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=1759473060.6ll3polgmk.astroid@yuna.none \
--to=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