From: Thomas Ellmenreich <t.ellmenreich@proxmox.com>
To: pve-devel@lists.proxmox.com
Cc: Thomas Ellmenreich <t.ellmenreich@proxmox.com>
Subject: [RFC qemu-server 0/5] drive: account for differing TPM sizes
Date: Mon, 19 Oct 2026 11:53:41 +0200 [thread overview]
Message-ID: <20261019095346.175659-1-t.ellmenreich@proxmox.com> (raw)
Our current systems to handle TPM drives always assume that the disks have a
fixed 4MiB size that cannot be changed even if that may not be the case. In
situations where the granularity of the backing storage exceeds the 4MiB, an
allocation of a TPM drive will be at least as big as the granularity of said
backing storage.
To solve this mismatch in a very simple way, the default size is retained for
allocation. Only after the allocation do we check the actual size of the
created TPM disk and update the configuration accordingly. A minimum size of
4MiB is always applied to situations where that may not be the case.
In the case of migrations, movement and cloning of disks, we just refer to the
actual disk size instead of the TPM size constant. Doing so also makes it now
possible to move a larger (than 4MiB) TPM disk to a different storage.
Open Questions
--------------
1. During a migration a TPM disk might change from a storage with 4MiB
granularity to a storage with 64MiB granularity. As already mentioned, the
TPM disk's size is then automatically increased. The fix I have implemented
for this, performs a "brute" `qm disk rescan --vmid` on the remote. This
does the job, but also much more.
To avoid all of the other side effects of a rescan, I could extend `qm disk
rescan` to also take another parameter that specifies the disk and so Avoid
any of the other side effects of calling a rescan on the whole VM. could
This approach be better? or is there a even better approach?
2. The rescan is currently disabled for remote migrations, but it should also
be safe for those. So does it make sense to also implement the rescan for
remote migrations?
3. A small thing, but how should I handle errors produced by PVE::Tools::run_command?
I didn't quite understand if run_command returns an error if an error is
emitted by the internal command. If that is not the case, the context is
never actually shown.
qemu-server:
Thomas Ellmenreich (5):
drive: improve and extend TPM drive size helpers
drive: update TPM size on creation
drive: read actual size when cloning TPM drive
tests: make qm mock accept disk command
drive: rescan drives after migrating to different storage
src/PVE/API2/Qemu.pm | 16 ++++++++++----
src/PVE/QemuMigrate.pm | 19 +++++++++++++---
src/PVE/QemuServer.pm | 27 ++++++++++++++++++++---
src/test/MigrationTest/QemuMigrateMock.pm | 2 ++
4 files changed, 54 insertions(+), 10 deletions(-)
Summary over all repositories:
4 files changed, 54 insertions(+), 10 deletions(-)
--
Generated by murpp 0.12.0
next reply other threads:[~2026-10-19 9:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 9:53 Thomas Ellmenreich [this message]
2026-10-19 9:53 ` [PATCH qemu-server 1/5] drive: improve and extend TPM drive size helpers Thomas Ellmenreich
2026-10-19 9:53 ` [PATCH qemu-server 2/5] drive: update TPM size on creation Thomas Ellmenreich
2026-10-19 9:53 ` [PATCH qemu-server 3/5] drive: read actual size when cloning TPM drive Thomas Ellmenreich
2026-10-19 9:53 ` [PATCH qemu-server 4/5] tests: make qm mock accept disk command Thomas Ellmenreich
2026-10-19 9:53 ` [PATCH qemu-server 5/5] drive: rescan drives after migrating to different storage Thomas Ellmenreich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261019095346.175659-1-t.ellmenreich@proxmox.com \
--to=t.ellmenreich@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.