[libvirt] [PATCH] Revert "tpm: Check TPM XML device configuration changes after edit"

[Peter Krempa]

On Mon, Aug 12, 2019 at 14:15:22 -0400, Stefan Berger wrote:
> On 8/12/19 2:11 PM, Peter Krempa wrote:
> > On Mon, Aug 12, 2019 at 13:57:40 -0400, Stefan Berger wrote:
> > > On 8/9/19 6:15 AM, Ján Tomko wrote:
> > > > Redefining a domain via virDomainDefineXML should not give different results
> > > > based on an already existing definition.
> > > 
> > > I added this patch so that users don't try to change a VM from encrypted to
> > > unencrypted on the level of the domain XML and assume it will start. It will
> > > not start anymore.
> > It is pointless to even try to protect from this as user can undefine
> > the domain and then define it again. Since at that point there's nothing
> > to compare against you'd get into the same situation.
> Not quite. We would deleted the state directories of the (encrypted) TPMs
> upon VM undefinition. So the user would start with no existing TPM state.

Well, that is okay. If the user changes configuration such as that the
wrong state is reused it's a configuration problem. It's the same
situation as if the user changes from UEFI to bios but provides the
wrong/old path to the bios image.

We just must make sure that once the original configuration is restored
(including the disk images (if the guest would e.g. record that the
state has changed and refuse to work)) everything works as if nothing
happened. This is the snapshot revert scenario (but this requires some
management level trickery to e.g. also revert the state of the TPM (as I
doubt that the code is more clever than in the case of the UEFI variable
store which we don't snapshot currently properly))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190812/841431ee/attachment-0001.sig>