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

[John Ferlan]

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.

I really don't want to follow the ~20 attempts to get genid into QEMU -
I'll give up way before then ;-)!


>>> A second consideration then is whether to allow user-specified GUID at
>>> all, but I guess mgmt applications may have a different idea when it's
>>> necessary to change and thus it makes sense to allow that. For that
>>> situation the provided GUID should be always honoured.
>>
>> The microsoft spec describes exactly why GUID must change, and mgmt
>> applications must not deviate from those rules to make up their own.
>>
>> So the question is not whether the mgmt app has a different idea of
>> when to change GUID. Rather, we should consider whether there is any
>> situation in which it is impossible for libvirt todo the right thing
>> according to the microsoft spec.
>>
>> If libvirt has enough knowledge to always do the right thing, then
>> we could refuse to make it user configurable - just report what is
>> set.

Not sure we can "decide" to not make it user configurable, but then
again it's also not specifically stated from how I read things.

> 
> The only thing that comes into my mind is the non-managed save/restore
> case. In that scenario both options make somewhat sense and libvirt
> can't really tell which is the case.
> 
> That can be handled with an API flag though, since we can use the GUID
> stored in the save image.
> 

The spec says :

"Restoring from backup – Restoring a backup image will cause a previous
workload time interval to be re-executed. Upon restore, the components
of the backup are enumerated and replaced on the restore target by the
VSS system. The affected configuration files are simply copied and not
re-realized on the host. The restore sequence will be modified to post
process the restore target and apply new generation identifiers to the
restored configuration files."

I read that as change the GUID and did so during startup processing from
the qemuDomainSaveImageStartVM.

Although I suppose it could also be read as altering the GUID before the
virDomainObjListAdd in qemuDomainRestoreFlags and before the
virDomainObjAssignDef in qemuDomainObjRestore.

Since both called the latter and the running config for which the GUID
is formatted is saved in the latter it "felt reasonable" to not have
duplicated code.



John