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

[Daniel P. Berrangé]

On Wed, Apr 25, 2018 at 02:36:52PM +0200, Peter Krempa wrote:
> 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.

I think it would fall under the "starts executing a snapshot" scenario
no matter what, because the spec doesn't say anything about whether the
original VM carried on running after the snapshot was taken. Just that
a snapshot was taken and this snapshot is then run. So the fact that
our save/restore can be view as a way to "pause" execution doesn't
matter - we've implemented "pause" by creating a snapshot and then 
"resume" by running the snapshot.

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