Re: [pve-devel] [PATCH-SERIES qemu/swtpm/storage/qemu-server 00/16] fix #4693: drive: allow non-raw image formats for TPM state drive

From: "Daniel Kral" <d.kral@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Cc: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES qemu/swtpm/storage/qemu-server 00/16] fix #4693: drive: allow non-raw image formats for TPM state drive
Date: Fri, 17 Oct 2025 15:17:18 +0200	[thread overview]
Message-ID: <DDKMJYZK2QEB.149XCK3UMI5J8@proxmox.com> (raw)
In-Reply-To: <20251014143946.160679-1-f.ebner@proxmox.com>

On Tue Oct 14, 2025 at 4:39 PM CEST, Fiona Ebner wrote:
> Add infrastructure for doing FUSE exports via QEMU storage daemon.
> This makes it possible to use non-raw formatted volumes for the TPM
> state, by exposing it to swtpm as raw via FUSE. A QEMU storage daemon
> instance is associated to a given VM.
>
> The swtpm_setup code tries to unlink files rather than just clear the
> header like it does for block devices. FUSE exports cannot be
> unlinked, align the behavior to also just remove the header for files.
>
> To have FUSE exports available, it's necessary to enable via QEMU
> build flags.
>
> A new standard option for VM image formats is introduced and in the
> end used for the TPM state drive. The need for that also came up
> already in the past for setting a format override when restoring and
> it's cleaner to use what the storage layer actually supports.
>
> Then there's two independent improvements for qemu-server.
>
> For the QMP client and wrappers, the QMP peer is better abstracted and
> the QEMU storage daemon is added as a possible peer.
>
> Blockdev code is updated to also support attaching a drive to the QEMU
> storage daemon rather than just the main QEMU instance for a VM.
>
> Then the QSD module is introduced and handling for TPM is added.
>
> Finally, non-raw formats are allowed in the schema for the TPM state
> drive.

I have tested this for a few pre-existing and new VMs and it works like
a charm, nice work!

I've tested the following:

- creating a VM with tpmstate0 as a raw image
- creating a VM with tpmstate0 as a subvol
- creating a VM with tpmstate0 as a qcow2 image
- cloning a VM with tpmstate0 as a raw image
- cloning a VM with tpmstate0 as a qcow2 image
- templating a VM with tpmstate0 + cloning
- moving qcow2 tmpstate0s between storages
- converting existing raw tpmstate0 to qcow2
- converting qcow2 tpmstate0 back to raw image

I installed Debian on the new VMs and used existing Debian and Windows
VMs to test the templating / moving / converting ops and all of those
worked as expected.

As pointed out in the cover letter / swtpm patch, not applying that one
will result in a failed VM start as it will try to unlink the FUSE
export fs (which is exposed as a regular file).

The qsd run files in /run/qemu-server/ were always cleaned up correctly
(besides when sending SIGKILL to the VM's qsd process directly) and I
didn't ran into qsd hanging when stopping the VM normally otherwise.

I've tried my best to study the surrounding code that I didn't have much
knowledge about yet (mainly setting up swtpm and the qmp cmd
infrastructure), but didn't find any serious issues besides a few nits
and the SIGKILL handling, so with the latter addressed consider this as:

Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Tested-by: Daniel Kral <d.kral@proxmox.com>

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel