Re: [pve-devel] [PATCH v2 pve-storage 1/2] add external snasphot support

["DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>]

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

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "f.gruenbichler@proxmox.com" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 pve-storage 1/2] add external snasphot support
Date: Fri, 25 Oct 2024 20:04:10 +0000
Message-ID: <7974c74b2d3a85086e8eda76e52d7a2c58d1dcb9.camel@groupe-cyllene.com>

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


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


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)


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