From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id AACEC1FF13A for ; Wed, 08 Jul 2026 10:43:48 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 4F7C22144B; Wed, 08 Jul 2026 10:43:48 +0200 (CEST) Date: Wed, 08 Jul 2026 10:43:41 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= Subject: Re: [RFC storage, qemu-server] offload full/live clone to storage backend To: Ciro Iriarte , Fiona Ebner , pve-devel@lists.proxmox.com References: <6a4416f5.01f0a1da.1533d8.2fdf@mx.google.com> <1783430000.wo44ge3ggk.astroid@yuna.none> <90aae63f-8d67-4a26-ab6b-ed32fd1537ce@proxmox.com> In-Reply-To: <90aae63f-8d67-4a26-ab6b-ed32fd1537ce@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1783500024.h4hi20lbpy.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783500216278 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.067 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: FCYTWDJFAQUPW6Z6J7M2DBKCPXDJFQHJ X-Message-ID-Hash: FCYTWDJFAQUPW6Z6J7M2DBKCPXDJFQHJ X-MailFrom: f.gruenbichler@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On July 8, 2026 10:17 am, Fiona Ebner wrote: > Adding on top of Fabian's feedback: >=20 > Am 07.07.26 um 3:48 PM schrieb Fabian Gr=C3=BCnbichler: >> 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. >=20 > 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. >>=20 >> 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. >=20 > No, we do freeze when cloning a running VM: > https://git.proxmox.com/?p=3Dqemu-server.git;a=3Dblob;f=3Dsrc/PVE/QemuSer= ver/BlockJob.pm;h=3D921f046cd9ad917a1e365bd152cb250d656beec4;hb=3DHEAD#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). >>=20 >> agreed. cross-storage could potentially be a follow-up, and we might >> want to account for it in the copy_image signature/parameters? >=20 > 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..