On 10/24/22 12:28, Stefan Berger wrote:
Pass the --migration option to swtpm if swptm supports it (starting
with v0.8) and if the TPM's state is written on shared storage. If this
is the case apply the 'release-lock-outgoing' parameter with this
option and apply the 'incoming' parameter for incoming migration so that
swtpm releases the file lock on the source side when the state is migrated
and locks the file on the destination side when the state is received.
If a started swtpm instance is running with the necessary options of
migrating with share storage then remember this with a flag in the
virDomainTPMPrivateDef.
Report an error if swtpm does not support the --migration option and an
incoming migration across shared storage is requested.
Signed-off-by: Stefan Berger <stefanb(a)linux.ibm.com>
---
src/qemu/qemu_migration.c | 10 ++++++++
src/qemu/qemu_tpm.c | 48 +++++++++++++++++++++++++++++++++++++--
src/qemu/qemu_tpm.h | 3 +++
3 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 16bf7ac178..2aa0b6e89e 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2786,6 +2786,7 @@ qemuMigrationSrcBegin(virConnectPtr conn,
g_autofree char *xml = NULL;
char *ret = NULL;
virDomainAsyncJob asyncJob;
+ int rc;
if (cfg->migrateTLSForce &&
!(flags & VIR_MIGRATE_TUNNELLED) &&
@@ -2795,6 +2796,15 @@ qemuMigrationSrcBegin(virConnectPtr conn,
goto cleanup;
}
+ rc = qemuTPMHasSharedStorage(driver, vm->def);
+ if (rc < 0)
+ goto cleanup;
+ if (rc == 1 && !qemuTPMCanMigrateSharedStorage(vm->def)) {
+ virReportError(VIR_ERR_NO_SUPPORT, "%s",
+ _("the running swtpm does not support migration with shared
storage"));
+ goto cleanup;
+ }
+
This check is correct, but as I said in my other reply, I think it
should live in qemuMigrationSrcIsAllowed().
Michal