On Wed, Sep 10, 2025 at 7:14 PM Stefan Berger <[email protected]> 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
