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