public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>,
	"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: Mon, 28 Oct 2024 12:12:46 +0100	[thread overview]
Message-ID: <1730113744.ylkqjpc17g.astroid@yuna.none> (raw)
In-Reply-To: <7974c74b2d3a85086e8eda76e52d7a2c58d1dcb9.camel@groupe-cyllene.com>

On October 25, 2024 10:04 pm, DERUMIER, Alexandre wrote:
> -------- Message initial --------
> De: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> À: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
> "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
> Cc: Giotta Simon RUAGH <Simon.Giotta@ruag.ch>
> Objet: Re: [pve-devel] [PATCH v2 pve-storage 1/2] add external snasphot
> support
> Date: 24/10/2024 11:48:03
> 
> 
>> Giotta Simon RUAGH via pve-devel <pve-devel@lists.proxmox.com> hat am
>> 24.10.2024 09:59 CEST geschrieben:
>> > I mean, if we don't allow .raw files to be snapshotted then this
>> > problem doesn't exist ;)
>> 
>> Quick comment from the bleacher; Adding a mechanism to shapshot raw
>> disks might solve the TPM (tpmstate) snapshotting issue, as well as
>> allowing containers to be snapshot.
>> 
>> For context: 
>> When using a storage that does not natively support snapshotting (NFS
>> on NetApp or similar enterprise storage, in particular), raw disks
>> cannot be snapshot. 
>> Since tpmstate disks can only be stored as raw (as I understand they
>> are just a binary blob?), this makes it impossible to snapshot or
>> (link-)clone any VMs that have a TPM. This especially is an issue for
>> current Windows clients.
>> Same issue for LXC containers, as their storage format is raw only as
>> well.
>>  
>> https://antiphishing.vadesecure.com/v4?f=OVFyc3FkSEdWUWx0QkZXZpBaFZH9
>> xbUoQi0GpC0KVIU1UWG2AZ7f_MrrmMArnShL&i=Sm1YaTk1OUR6bzFoY3JtMLa1y1UZBH
>> RmExEJw6jsROc&k=Hbsl&r=dmh0RHJVSG1CUXhDTmJ3UlzJQNCs3CJCbvk0g2AF56AIGO
>> 1hR25I2pdFPY1trx1rDP3XHfwmNmQ-
>> fWda_VoksA&s=d330b0a625b7cfcbde904428642b953a712c1a40b54a60918ac39b62
>> f8ca6535&u=https%3A%2F%2Fbugzilla.proxmox.com%2Fshow_bug.cgi%3Fid%3D4
>> 693
> 
>>>no it does not - with the mechanisms proposed in this patch series,
>>>only the initial volume can be raw, if it is snapshotted, the
>>>overlays are qcow2. so anything reading from the volume needs qcow2
>>>support, including swtpm. 
>>>
>>>that's why containers are not on the table for now either..
> 
> Hi, I really don't known how swtpm is working, but for containers maybe
> it could be possible

anything that works for containers should probably also be applicable
for swtpm (the other direction depends on how exactly it is made to work
- e.g., if swtpm gets patched to read directly from a qcow2 file, that
  doesn't transfer to qcow2 support for containers ;))

> not yet merged to kernel, but a dm-qcow2 driver is on the roadmap :)
> https://www.youtube.com/watch?v=Z7jPpWydEC8
> 
> another possibility is qemu-storage-daemon  + nbd or vdpa export:
> https://blog.deckhouse.io/lvm-qcow-csi-driver-shared-san-kubernetes-81455201590e

the issue with nbd is that it requires setting up ahead how many devices
are exposed that way, and that means it doesn't really scale well:

https://bugzilla.proxmox.com/show_bug.cgi?id=4693

> About vtpm, is it really a problem to not be able to snapshot ? (I
> mean, does the content change regulary ? can't we just skip the disk ?
> I really don't known how it's working, I don't use tpm :p)

see the above BZ - they are small enough that we could potentially use a
"poor" variant of external snapshots by just copying the image (it is
rather small after all, so keeping a full copy per snapshot isn't that
bad). or we teach swtpm to read qcow2 files ;)

it is important for windows VMs, since those use/require a TPM in modern
versions. and depending how you set up the VM, your disk encryption keys
might rely on the TPM state being correct, so not snapshotting it is not
really an option ;)


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  parent reply	other threads:[~2024-10-28 11:13 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 [this message]
2024-10-25  5:52         ` DERUMIER, Alexandre via pve-devel
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=1730113744.ylkqjpc17g.astroid@yuna.none \
    --to=f.gruenbichler@proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal