On 10/4/22 11:48, Michal Prívozník wrote:
On 10/4/22 17:33, Stefan Berger wrote:
On 10/4/22 10:39, Michal Prívozník wrote:
Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
and pushed.
Thanks.
Regarding shared storage and migration. Should shared storage support be
implemented using an XML attribute or through a new migration option
(--tpm-shared-storage)? The previously proposed implementation used an
XML attribute that may be easier to accommodate by higher layers that
then don't need to support a new migration option just a slighly
different XML but that may not be how it should be done...
Yeah, I've been meaning to look into that discussion and patches. I
don't know if it was suggested, but maybe a flag to migration APIs? We
do storage migration that way. Or do we need to pass the flag to swtpm
even way before migration is started (e.g. on domain startup)?
I think that should not be necessary.
swtpm now has options to support shared storage setups:
--migration [incoming][,release-lock-outgoing]
: Incoming migration defers locking of storage backend
until the TPM state is received; release-lock-outgoing
releases the storage lock on outgoing migration
If we need to support shared storage migration using an option then we will have to add --migration release-lock-outgoing to the command line of every instance of swtpm that 's being started and that supports this option. When migration then is done across shared storage using the new command line option then we have to query on source and destination whether the above options are indeed supported and if that's not the case on either side reject/fail the migration. So, an older versions of swtpm on either side will cause a rejection of the migration across shared storage then as expected...
I suppose migration flags passed on the source side will become available on the destination side. Need to test this...
Michal
