On Wed, Apr 25, 2018 at 08:02:35AM -0400, John Ferlan wrote:
On 04/25/2018 04:46 AM, Peter Krempa wrote:
> On Wed, Apr 25, 2018 at 09:39:49 +0100, Daniel Berrange wrote:
>> On Wed, Apr 25, 2018 at 10:32:05AM +0200, Peter Krempa wrote:
>>>
>>> Well, that depends. I did not read the docs for this thoroughly enough.
>>> If it is okay for us to generate a new GUID upon every boot of a VM then
>>> this will be for a rather simple implementation, since we have a very
>>> limited set of situations when we are starting a new qemu process which
>>> should NOT change the GUID and we will change it in all other scenarios.
>>
>> AFAIK, we *must* change GUID on every cold boot
>
> Good, that makes things rather simple.
>
This one is not really 100% clear to me. The "spec" is like 6 pages -
it's a pretty quick read...
http://go.microsoft.com/fwlink/?LinkId=260709
The last 2 pages describe "when" the GUID should change and specifically
calling out cold boot is not one of those. What leads me to believe
otherwise is the two boot scenarios and the unspecified VM config
changes have this "undertone" that using the same GUID for those
scenarios is fine/expected.
Yeah the table at the very end is the key bit and it seems I was actually
wrong
Scenario GenID changed
-----------------------------------------------------------------------
Virtual machine is paused or resumed No
Virtual machine reboots No
Virtual machine host reboots No
Virtual machine starts executing a snapshot Yes
Virtual machine is recovered from backup Yes
Virtual machine is failed over in a disaster recovery env Yes
Virtual machine is live migrated No
Virtual machine is imported, copied, or cloned Yes
Virtual machine is failed over in a clustered environment No
Virtual machine's configuration changes Unspecified
My reading of "Virtual machine reboots" and "Virtual machine host
reboots"
rows in particular is that we can *NOT* change GUID on every boot up
operation. The spec literally only wants it to be changed when there is
the possibility that the VM is potentially re-executing something that
has already been executed before.
The transient VM feature is the real killer for libvirt - we have no
way of knowing when virDomainCreateXML launches a transient VM whether
that is starting up after a revert to backup/snapshot, or whether it
is a normal boot. Only the mgmt app like oVirt / OpenStack has enough
info to decide that. So we must allow the mgmt app to provide a GUID
in the XML document themselves, and then change it in places where we
know it is needed to change.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|