On 10/24/22 12:28, Stefan Berger wrote:
> Allow migration with TPM_EMULATOR (swtpm) only if shared storage has been
> set up for the TPM state directory.
>
> Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxxxxx>
> ---
> src/qemu/qemu_migration.c | 6 ++++++
> src/qemu/qemu_tpm.c | 28 ++++++++++++++++++++++++++++
> src/qemu/qemu_tpm.h | 5 +++++
> 3 files changed, 39 insertions(+)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 33105cf07b..16bf7ac178 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -38,6 +38,7 @@
> #include "qemu_security.h"
> #include "qemu_slirp.h"
> #include "qemu_block.h"
> +#include "qemu_tpm.h"
>
> #include "domain_audit.h"
> #include "virlog.h"
> @@ -2579,6 +2580,11 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver,
> _("tunnelled offline migration does not make sense"));
> return NULL;
> }
> + if (qemuTPMHasSharedStorage(driver, vm->def) != 1) {
> + virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> + _("offline migration requires TPM state directory to be on shared storage"));
Does it though? We don't have such requirement for say domain disks. I
believe the point of --offline is to merely just get domain XML an
define it on the destination. That's why --offline requires --persistent
and why a lot of checks are skipped when --offline.
I mean, for disks we just assume users will copy them onto destination
(or use a shared FS). We can assume the same for TPM, can't we? This
would also allow us to simplify qemuTPMHasSharedStorage() because it no
longer needs to call qemuTPMEmulatorInitPaths() because for running
guests the paths were already initialized.
And if we chose to keep this check in, then I think it should live in
qemuMigrationSrcIsAllowed() which is the places where similar checks are
performed.
Michal
