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: Thu, 9 Jul 2026 09:56:04 +0200 [thread overview]
Message-ID: <c231abb9-c340-432c-9728-5dc46f134c16@proxmox.com> (raw)
In-Reply-To: <1783500024.h4hi20lbpy.astroid@yuna.none>
Am 08.07.26 um 10:43 AM schrieb Fabian Grünbichler:
> On July 8, 2026 10:17 am, Fiona Ebner wrote:
>>>>
>>>> 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..
Different storage types based on the same underlying technology (e.g.
ZFS) could still do it. That said, I don't mind not designing for this
but just for offloading between storages of the same type.
prev parent reply other threads:[~2026-07-09 7:56 UTC|newest]
Thread overview: 5+ 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
2026-07-08 8:43 ` Fabian Grünbichler
2026-07-09 7:56 ` Fiona Ebner [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=c231abb9-c340-432c-9728-5dc46f134c16@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.