From: "DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Cc: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [PATCH v2 pve-storage 1/2] add external snasphot support
Date: Fri, 25 Oct 2024 05:52:09 +0000 [thread overview]
Message-ID: <mailman.558.1729835539.332.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <257159672.1161.1729752121142@webmail.proxmox.com>
[-- Attachment #1: Type: message/rfc822, Size: 16973 bytes --]
From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 pve-storage 1/2] add external snasphot support
Date: Fri, 25 Oct 2024 05:52:09 +0000
Message-ID: <100d9cf0211db39a5d94eb596bbca9f7760b2f7c.camel@groupe-cyllene.com>
>
>
> But even with that, you can still have performance impact.
> So yes, I think they are really usecase for workload when you only
> need
> snapshot time to time (before an upgrade for example), but max
> performance with no snaphot exist.
>>my main point here is - all other storages treat snapshots as
>>"cheap". if you combine raw+qcow2 snapshot overlays, suddenly
>>performance will get worse if you keep a snapshot around for whatever
>>reason..
Ok, I redone a lot of bench yesterday, with a real san storage, and I
don't see too much difference between qcow2 and raw. (something like
30000iops on raw and 28000~29000 iops on qcow2).
I have tested with 2TB qcow2 file to be sure, and with new qcow2 sub-
cluster feature with l2_extended, it's not too much.
The difference is a little more big on a local nvme (I think because of
low latency), but as the usecase is for network storage, it's ok.
Let's go for full .qcow2, it'll be easier ;)
> > > 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 it's too confusing, we could use for example an .snap extension.
> (as we known that it's qcow2 behind)
>>I haven't thought yet about how to encode the snapshot name into the
>>snapshot file name, but yeah, maybe something like that would be
>>good. or maybe snap-VMID-disk-DISK.qcow2 ?
ok we can use snap-VMID-disk-DISK.qcow2 , I'll be easier for regex :p
> > > storage_migrate needs to handle external snapshots, or at least
> > > error
> > > out.
> it should already work. (I have tested move_disk, and live migration
> +
> storage migration). qemu_img_convert offline and qemu block job for
> live.
>>but don't all of those lose the snapshots? did you test it with
>>snapshots and rollback afterwards?
ok, sorry, I have tested clone a new vm from a snapshot. (which use the
same code). I don't remember how it's work with move disk of a running
vm when snaphot exist.
>
> The main problem is when you start a vm on a specific snasphot,
> we don't send the $snapname param.
>
> One way could be that qemu-server check the current snapshot from
> config when doing specific action like start.
>>if we manage to find a way to make the volid always point at the top
>>overlay, then that wouldn't be needed..
yes, indeed if we are able to rename the current snapshot file to vm-
100-disk-0.qcow2 , it's super easy :)
I need to do more test, because drive-reopen only seem to work if the
original drive is defined with -blockdev syntax. (It seem to clash on
nodename if it's not defined with -drive ).
I have begin to look to implement blockdev, it don't seem too much
difficult for the start command line, but I need check the hotplug
part.
Maybe for pve9 ? (it could open door to features like luks encryption
too or or)
I'll rework all the patches after my holiday, with both renaming of
current snapshot and only use .qcow2 format, it should be a lot of
more clean and KISS.
Thanks again for the review !
[-- 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 prev parent reply other threads:[~2024-10-25 5:52 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 [this message]
2024-10-24 7:50 ` Fabian Grünbichler
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=mailman.558.1729835539.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