Re: [PATCH v2 0/2] qemu: tpm: Improve TPM state files management
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(a)redhat.com>
>>
>> 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