Re: [RFC qemu-server 0/5] drive: account for differing TPM sizes

[Fiona Ebner <f.ebner@proxmox.com>]

Am 19.10.26 um 11:54 AM schrieb Thomas Ellmenreich:
> 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?
> 

See my reply to the last patch.

> 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.

Yes, if the invoked command ends with a non-zero exit status,
run_command() will die. The stderr output is handled by the errfunc in
your patch.

> 
> 
> 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(-)
>