abbbi
Backup (SW)TPM Device related state files in a consistent way
New Windows versions often depend von TPM devices beeing attached (at least during installation). Libvirt allows for two types of TPM devices:
- emulated devices (swtpm based)
- passthrough devices
it may make sense to include the swtpm related files within the backup too, even if i currently dont see a way to guarantee the data beeing consistent.
If an emulated device is attached, libvirt starts an swtpm process:
/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/2-backuptest-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/*vm_uuid*/tpm2,mode=0600 -
it makes sense to add the files from /var/lib/libvirt/swtpm/vm_uuid/ to the backup. In case the complete host system is lost or these files are missing, i think it may be troublesome to boot the actual virtual machine (uefi / secureboot)
The files in /var/lib/libvirt/swtpm are owned by special "tss" user with no read rights. So this might only work if backup is executed as root user. More information required.
For now backup at least prints a warning that further action may be required by user.
Outstanding:
- Clarify which user most distributions use for the swtpm process (on Debian it is "tss")
- ssh client needs to be enhanced to be able to put/get directory trees and not single files for remote backup
- Fail backup with warning if we dont have access to the files (we need to be part of the "tss" group if run as regular user)
- Adopt restore utility
More info and Limitations:
https://www.ovirt.org/develop/release-management/features/virt/tpm-device.html
as discussed in IRC, to catch a consistent copy of the SWTPM state files, the backup process must pause the virtual machine for a short timeframe to ensure consistency. The current backupBegin API doesnt handle things here.
This also applies to the NVRAM settings ..
17:12 <abi> still quite interesting how to get a "consistent" state. Lets say backup via NBD. fsfreeze() -> copy nvram/tpm state -> fsthaw() enough?
17:13 <abi> rather, fsfreeze() -> create bitmap|copy nvram/tpm state| -> fsthaw() -> backup disk data
17:13 <abi> wonder if that is enough ..
17:14 <sipos> Is there a way to view exactly what is stored in a snapshot in a qcow2 file? I'd love to be able to dump the domain configuration or TPM state from the file and see what is
saved exactly. For the disk image, I can obviously export the snapshot as a NBD, but that is just the disk state, not the device/TPM state, so it is only showing part of what
is in the snapshot.
17:15 <pkrempa> abi: no, you must pause the VM to collect the nvram and TPM at the same time
17:15 <pkrempa> you also need to start the backup job while paused
17:16 <pkrempa> similarly I've added 'manual' snapshot mode for disks, if you e.g. want to use lvm snapshots for a LV backed disk on a VM. It pauses the VM and allows you to create the
snapshot on the storage before continuing
17:16 <pkrempa> (it's in sync with the memory image)
17:16 <pkrempa> backups don't have that yet though
17:16 <abi> pkrempa: show how does this work toegether with backupBegin()?
17:17 <pkrempa> well, for now you need to pause the VM, do the backup and then do a snapshot of memory (if you want memory state)
17:17 <abi> pkrempa: in case of a snapshot? not if im using a checkpoint? right?
17:17 <pkrempa> you can unpause after the memory snapshot finishes before the backup finishes
17:17 <pkrempa> the backup API can't be combined with taking a memory state dump for now (atomically)
17:18 <pkrempa> but you can make it atomic by pausing the VM
17:18 <abi> yeah, im only caring about the backup API, atm..
17:21 <pkrempa> so the backup API could be extended to also allow backup of the NVRAM image as it's a plain blockdev
17:22 <pkrempa> but it's a bit more complicated with swtpm as that state can't be atomically captured by qemu; so it'd require a brief pause
17:23 <pkrempa> but similarly can be emulated manually by pausing, fetching the NVRAM and SWTPM state, kicking off the backup and unpausing