swtpm persistent state snapshots by copying .permall file

swtpm persistent state snapshots by copying .permall file

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Hi Stefan,
I am investigating QEMU devices with persistent state like swtpm for a
specific snapshot use case. The VM is paused while disk images and other
persistent state files are snapshotted. This creates a crash-consistent
snapshot similar to booting after power failure on a real machine. No
RAM or volatile device state is collected.

My concern is how to ensure the swtpm's persistent state is captured as
consistently as possible, but I'm not very familiar with the code. I
wanted to run the following by you:

- Using --tpmstate dir= will write the persistent state to a new
  temporary file and then atomically replace the old .permall file using
  rename(2).

- If the VM is paused and a copy of the .permall file is taken, then
  this copy is consistent. It may not reflect any in-progress changes
  being written into a new temporary file, but that doesn't matter from
  the snapshot point of view since the VM is paused and it hasn't seen
  the completion of in-progress TPM operations.

- The .volatilestate and .savestate files do not need to be captured in
  the snapshot since the goal is just to achieve crash consistency.

Does this sound reasonable or have I missed something?

Thanks,
Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: swtpm persistent state snapshots by copying .permall file

[Stefan Berger]

On 9/10/25 5:08 PM, Stefan Hajnoczi wrote:
> Hi Stefan,
> I am investigating QEMU devices with persistent state like swtpm for a
> specific snapshot use case. The VM is paused while disk images and other
> persistent state files are snapshotted. This creates a crash-consistent
> snapshot similar to booting after power failure on a real machine. No
> RAM or volatile device state is collected.
> 
> My concern is how to ensure the swtpm's persistent state is captured as
> consistently as possible, but I'm not very familiar with the code. I
> wanted to run the following by you:
> 
> - Using --tpmstate dir= will write the persistent state to a new
>    temporary file and then atomically replace the old .permall file using
>    rename(2).

This is correct for the directory backend. We also have the file backend 
where a single file is keeping all the different types of state.

> 
> - If the VM is paused and a copy of the .permall file is taken, then
>    this copy is consistent. It may not reflect any in-progress changes
>    being written into a new temporary file, but that doesn't matter from

Correct.

>    the snapshot point of view since the VM is paused and it hasn't seen
>    the completion of in-progress TPM operations.

> 
> - The .volatilestate and .savestate files do not need to be captured in
>    the snapshot since the goal is just to achieve crash consistency.

Yes, I think so since the .volatilestate state would be written only in 
case of VM suspend or migration and the .savestate only upon suspend-to-RAM.

> 
> Does this sound reasonable or have I missed something?

No, I think this sounds reasonable.

> 
> Thanks,
> Stefan

Re: swtpm persistent state snapshots by copying .permall file

[Stefan Hajnoczi]

On Wed, Sep 10, 2025 at 7:14 PM Stefan Berger <stefanb@linux.ibm.com> wrote:
> On 9/10/25 5:08 PM, Stefan Hajnoczi wrote:
> > Hi Stefan,
> > I am investigating QEMU devices with persistent state like swtpm for a
> > specific snapshot use case. The VM is paused while disk images and other
> > persistent state files are snapshotted. This creates a crash-consistent
> > snapshot similar to booting after power failure on a real machine. No
> > RAM or volatile device state is collected.
> >
> > My concern is how to ensure the swtpm's persistent state is captured as
> > consistently as possible, but I'm not very familiar with the code. I
> > wanted to run the following by you:
> >
> > - Using --tpmstate dir= will write the persistent state to a new
> >    temporary file and then atomically replace the old .permall file using
> >    rename(2).
>
> This is correct for the directory backend. We also have the file backend
> where a single file is keeping all the different types of state.
>
> >
> > - If the VM is paused and a copy of the .permall file is taken, then
> >    this copy is consistent. It may not reflect any in-progress changes
> >    being written into a new temporary file, but that doesn't matter from
>
> Correct.
>
> >    the snapshot point of view since the VM is paused and it hasn't seen
> >    the completion of in-progress TPM operations.
>
> >
> > - The .volatilestate and .savestate files do not need to be captured in
> >    the snapshot since the goal is just to achieve crash consistency.
>
> Yes, I think so since the .volatilestate state would be written only in
> case of VM suspend or migration and the .savestate only upon suspend-to-RAM.
>
> >
> > Does this sound reasonable or have I missed something?
>
> No, I think this sounds reasonable.

Thanks for confirming!

Stefan