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 :|