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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
