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

["Fabian Grünbichler" <f.gruenbichler@proxmox.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