From: Alexandre Derumier via pve-devel <pve-devel@lists.proxmox.com>
To: pve-devel@lists.proxmox.com
Cc: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Subject: [pve-devel] [PATCH SERIES v2 pve-storage/qemu-server] add external qcow2 snapshot support
Date: Mon, 30 Sep 2024 13:31:50 +0200 [thread overview]
Message-ID: <mailman.145.1727695957.332.pve-devel@lists.proxmox.com> (raw)
[-- Attachment #1: Type: message/rfc822, Size: 5384 bytes --]
From: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH SERIES v2 pve-storage/qemu-server] add external qcow2 snapshot support
Date: Mon, 30 Sep 2024 13:31:50 +0200
Message-ID: <20240930113153.2896648-1-alexandre.derumier@groupe-cyllene.com>
This patch series implement qcow2 external snapshot support for files && lvm volumes
The current internal qcow2 snapshots have a lot of performance problems.
I have tested through nfs and also local filesystem
https://lore.proxmox.com/pve-devel/6a44716a-88bc-4523-b210-d67031917d8f@proxmox.com/t/
I see that Fiona don't have same result than me, but I got something like 200~300iops
vs 20000 iops with 4k randwrite when a snapshot exist.
The result is even worst on a shared filesystem like ocfs2 or gfs2. (around 80 iops)
I think (I'm not 100% sure) this is mostly because metadatas are not preallocated
anymore with qcow2 internal snap.
With external snapshot, I almost don't have any performance impact when a snapshot exist.
Also other bugs are freeze/lock reported by users since years on snapshots delete on nfs
https://forum.proxmox.com/threads/snapshot-removal-jams-the-vm.111648/
(The disk access seem to be frozen during all the delete duration)
External qcow2 snapshots also allow snapshot of raw devices ,so 0 performance impact without snapshots.
This also open doors for remote snapshot export-import for storage replication.
This V2 introduce support for qcow2 external snapshot for lvm, extra lvm
volume is created for each snapsphot and formated with qcow2.
This is a lot more performant than lvm (non-thin/nomedata) snapshot, and allow to use
it for shared lvm. (I have another patch series for thick lvm dynamic extend, but if we could have at minimum
snapshot working, it could great :)
I have tested: snasphot, snap rollback, snap delete, clone, move disk, rename disk, create_base. (online && offline)
lxc is not yet supported, but I think we could look to implement the recent dm-qcow2 kernel block driver
https://lore.kernel.org/lkml/164846619932.251310.3668540533992131988.stgit@pro/T/
storage.cfg example:
dir: local2
path /var/liv/vz
content snippets,vztmpl,backup,images,iso,rootdir
snapext 1
lvmqcow2:test
vgname test
snapext 1
content images
changelog v2:
implement lvm with external qcow2 snapshots
pve-storage:
Alexandre Derumier (2):
add external snasphot support
add lvmqcow2 plugin: (lvm with external qcow2 snapshot)
src/PVE/Storage.pm | 2 +
src/PVE/Storage/DirPlugin.pm | 1 +
src/PVE/Storage/LvmQcow2Plugin.pm | 460 ++++++++++++++++++++++++++++++
src/PVE/Storage/Makefile | 3 +-
src/PVE/Storage/Plugin.pm | 225 +++++++++++++--
5 files changed, 665 insertions(+), 26 deletions(-)
create mode 100644 src/PVE/Storage/LvmQcow2Plugin.pm
qemu-server:
Alexandre Derumier (1):
implement external snapshot
PVE/QemuServer.pm | 108 ++++++++++++++++++++++++++++++++++++++++------
1 file changed, 95 insertions(+), 13 deletions(-)
--
2.39.2
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next reply other threads:[~2024-09-30 11:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 11:31 Alexandre Derumier via pve-devel [this message]
[not found] <20240930113153.2896648-1-alexandre.derumier@groupe-cyllene.com>
2024-10-20 13:03 ` 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=mailman.145.1727695957.332.pve-devel@lists.proxmox.com \
--to=pve-devel@lists.proxmox.com \
--cc=alexandre.derumier@groupe-cyllene.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