From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 pve-storage 1/2] add external snasphot support
Date: Thu, 24 Oct 2024 09:50:18 +0200 (CEST) [thread overview]
Message-ID: <1940096001.1382.1729756218429@webmail.proxmox.com> (raw)
In-Reply-To: <1350338065.715.1729678366532@webmail.proxmox.com>
> Fabian Grünbichler <f.gruenbichler@proxmox.com> hat am 23.10.2024 12:12 CEST geschrieben:
>
>
> some high level comments:
>
> I am not sure how much we gain here with the raw support? it's a bit confusing to have a volid ending with raw, with the current volume and all but the first snapshot actually being stored in qcow2 files, with the raw file being the "oldest" snapshot in the chain..
>
> if possible, I'd be much happier with the snapshot name in the snapshot file being a 1:1 match, see comments inline
> - makes it a lot easier to understand (admin wants to manually remove snapshot "foo", if "foo" was the last snapshot then right now the volume called "foo" is actually the current contents!)
> - means we don't have to do lookups via the full snapshot list all the time (e.g., if I want to do a full clone from a snapshot "foo", I can just pass the snap-foo volume to qemu-img)
>
> the naming scheme for snapshots needs to be adapted to not clash with regular volumes:
>
> $ pvesm alloc extsnap 131314 vm-131314-disk-foobar.qcow2 2G
> Formatting '/mnt/pve/ext4/extsnap/images/131314/vm-131314-disk-foobar.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=off compression_type=zlib size=2147483648 lazy_refcounts=off refcount_bits=16
> successfully created 'extsnap:131314/vm-131314-disk-foobar.qcow2'
> $ qm rescan --vmid 131314
> rescan volumes...
> can't parse snapname from path at /usr/share/perl5/PVE/Storage/Plugin.pm line 1934.
>
> storage_migrate needs to handle external snapshots, or at least error out. I haven't tested that part or linked clones or a lot of other advanced related actions at all ;)
I'll add some more high-level comments (the threading seems to be broken for some reason, so I'll use this as "entrypoint"):
- snapext should probably be fixed for dir-type storages as well
- the volume ID should be static for both plugins, snapshots should be encoded on the storage layer in a fashion that doesn't "break through" to the API layers and makes it impossible to confuse the "main" volname with snapshots:
-- alloc_image shouldn't be able to allocate a volume that is then interpreted as snapshot
-- free_image shouldn't be able to free a snapshot volume directly
-- listing images should never return snapshots
-- ..
- for the LVM part, snapshots still require allocation a full-sized volume+some overhead for the qcow2 each. should we attempt to shrink them once they become read-only? in practice, only the LV backing the top image needs to be full-sized.. how do we ensure the underlying storage doesn't waste all that "empty" space?
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-10-24 7:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240930113153.2896648-1-alexandre.derumier@groupe-cyllene.com>
2024-09-30 11:31 ` Alexandre Derumier via pve-devel
2024-10-23 10:12 ` Fabian Grünbichler
2024-10-23 12:59 ` DERUMIER, Alexandre via pve-devel
[not found] ` <f066c13a25b30e3107a9dec8091b456ce2852293.camel@groupe-cyllene.com>
2024-10-24 6:42 ` Fabian Grünbichler
2024-10-24 7:59 ` Giotta Simon RUAGH via pve-devel
2024-10-24 9:48 ` Fabian Grünbichler
2024-10-25 20:04 ` DERUMIER, Alexandre via pve-devel
[not found] ` <7974c74b2d3a85086e8eda76e52d7a2c58d1dcb9.camel@groupe-cyllene.com>
2024-10-28 11:12 ` Fabian Grünbichler
2024-10-25 5:52 ` DERUMIER, Alexandre via pve-devel
2024-10-24 7:50 ` Fabian Grünbichler [this message]
2024-09-30 11:31 ` [pve-devel] [PATCH v2 qemu-server 1/1] implement external snapshot Alexandre Derumier via pve-devel
2024-10-23 10:14 ` Fabian Grünbichler
2024-10-23 14:31 ` DERUMIER, Alexandre via pve-devel
2024-10-23 18:09 ` DERUMIER, Alexandre via pve-devel
[not found] ` <aeb9b8ea34826483eabe7fec5e2c12b1e22e132f.camel@groupe-cyllene.com>
2024-10-24 7:43 ` Fabian Grünbichler
2024-09-30 11:31 ` [pve-devel] [PATCH v2 pve-storage 2/2] add lvmqcow2 plugin: (lvm with external qcow2 snapshot) Alexandre Derumier via pve-devel
2024-10-23 10:13 ` Fabian Grünbichler
2024-10-23 13:45 ` DERUMIER, Alexandre via pve-devel
[not found] ` <e976104d8ed7c365d8a482fa320a0691456e69c1.camel@groupe-cyllene.com>
2024-10-24 7:42 ` Fabian Grünbichler
2024-10-24 11:01 ` DERUMIER, Alexandre via pve-devel
2024-10-20 13:03 ` [pve-devel] [PATCH SERIES v2 pve-storage/qemu-server] add external qcow2 snapshot support DERUMIER, Alexandre via pve-devel
2024-10-20 17:34 ` Roland privat via pve-devel
2024-10-20 19:08 ` Esi Y via pve-devel
[not found] ` <CABtLnHqZVhDKnog6jaUBP4HcSwfanyEzWeLdUXnzJs2esJQQkA@mail.gmail.com>
2024-10-22 6:39 ` Thomas Lamprecht
2024-10-22 9:51 ` Esi Y via pve-devel
2024-10-22 14:54 ` DERUMIER, Alexandre via pve-devel
[not found] ` <2f07646b51c85ffe01089c2481dbb9680d75cfcb.camel@groupe-cyllene.com>
2024-10-24 3:37 ` Esi Y via pve-devel
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=1940096001.1382.1729756218429@webmail.proxmox.com \
--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