public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Ivaylo Markov via pve-devel <pve-devel@lists.proxmox.com>
To: pve-devel@lists.proxmox.com
Cc: Ivaylo Markov <ivaylo.markov@storpool.com>
Subject: Re: [pve-devel] Proposal: support for atomic snapshot of all VM disks at once
Date: Mon, 7 Oct 2024 10:27:09 +0300	[thread overview]
Message-ID: <mailman.200.1728286038.332.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <1485692612.2176.1728281553739@webmail.proxmox.com>

[-- Attachment #1: Type: message/rfc822, Size: 6524 bytes --]

From: Ivaylo Markov <ivaylo.markov@storpool.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] Proposal: support for atomic snapshot of all VM disks at once
Date: Mon, 7 Oct 2024 10:27:09 +0300
Message-ID: <1a8d02ca-ae00-4ab4-bae3-86446452bf6d@storpool.com>

Hi,

On 07/10/2024 09:12, Fabian Grünbichler wrote:
>> Dietmar Maurer <dietmar@proxmox.com> hat am 04.10.2024 17:13 CEST geschrieben:
>>> I am the maintainer of StorPool’s external storage plugin for PVE[0]
>>> which integrates our storage solution as a backend for VM disks. Our
>>> software has the ability to create atomic (crash-consistent) snapshots
>>> of a group of storage volumes.
>> We already make sure that shaphots of a group of volumes are atomic at qemu level (VM is halted while snapshots are created), so I wonder
>> if there is any real advantage here?
> I think the main advantage is that if you are fine with crash-equivalent consistency (e.g., the same as pulling the power plug) for your snapshots, then you can skip the freeze/suspend (and associated, hopefully tiny, downtime), and just snapshot on the storage layer. there might also be additional optimizations or administrative benefits on the storage side (like all snapshots being part of a single transaction), but those are probably not relevant for PVE itself..
>
This is exactly it - we're looking to avoid any slow downs/interruptions 
in the VMs when creating snapshots. I've not measured how long other 
storage plugins take to create snapshots, but it could be helpful for 
them if it's a slow operation.

-- 
Ivaylo Markov
Quality & Automation Engineer
StorPool Storage
https://www.storpool.com



[-- 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

  reply	other threads:[~2024-10-07  7:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04 13:54 Ivaylo Markov via pve-devel
2024-10-04 15:13 ` Dietmar Maurer
2024-10-07  6:12   ` Fabian Grünbichler
2024-10-07  7:27     ` Ivaylo Markov via pve-devel [this message]
2024-10-07 10:58       ` DERUMIER, Alexandre via pve-devel
2024-10-07  7:12   ` Daniel Berteaud via pve-devel
     [not found] <b16012bc-d4a9-42ff-b9ba-523649c6cfa6@storpool.com>
2024-10-08 10:50 ` Max Carrara
2024-10-08 12:49   ` Ivaylo Markov 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.200.1728286038.332.pve-devel@lists.proxmox.com \
    --to=pve-devel@lists.proxmox.com \
    --cc=ivaylo.markov@storpool.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal