Re: [libvirt] [PATCH v2 06/11] conf: Add VM Generation ID parse/format support

On Wed, Apr 25, 2018 at 13:25:57 +0100, Daniel Berrange wrote: > 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. Okay. So that means that we actually need to generate it in the parser, but we should also always report it back even for offline configurations. The only problem then will be what to do with the save/restore functionality, because that is really unknown to us since that API both includes the "Virtual machine is paused or resumed" and "Virtual machine starts executing a snapshot" scenario.