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.
The define API must have the same semantics when a new VM is defined and
when an pre-existing object is modified (well except let's say the UUID)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
