[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs

From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] Byte ordering of VM Generation ID in Windows VMs
Date: Thu, 5 Jul 2018 18:13:20 +0100
User-agent: Mutt/1.10.0 (2018-05-17)

On Thu, Jul 05, 2018 at 05:43:43PM +0100, Richard W.M. Jones wrote:
> On Thu, Jul 05, 2018 at 04:20:33PM +0200, Laszlo Ersek wrote:
> > QEMU does the right thing. If other hypervisors don't do this -- while
> > still taking and displaying the value in UUID / GUID textual format --,
> > they are wrong. The VMGENID spec from Microsoft
> > <http://go.microsoft.com/fwlink/?LinkId=260709> specifically mentions
> > "GUID".
> The MSFT spec does mention GUID, but it seems to me that it's only
> using GUID as an incidental example -- ie. that you might use the VM
> Generation ID to generate a GUID.  Outside that example it
> consistently refers to the VM Gen ID as a 128-bit integer.  It also
> says that it could be used as a "high entropy random data source",
> which is not in fact true if it's a UUID.
> It has to be said that after reading the spec again [the MSFT spec,
> not qemu's spec] and what other hypervisors are doing, I'm not sure
> qemu is doing the right thing here.

I'm not sure it particularly matters, as long as there is a way to
encode the 128-bit integer as a UUID without irreversable mangling
or data loss.  We could document it, or if we really wanted to,
provide an alternative syntax that QEMU internals changes into its
UUID form (or the reverse).  Libvirt would probably still need to
expose it as a UUID though, due to compatibility needs in the XML.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]