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

Peter Krempa pkrempa at redhat.com
Wed Apr 25 08:46:58 UTC 2018


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.

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180425/ccf31fd2/attachment-0001.sig>


More information about the libvir-list mailing list