On 09/30/21 09:33, Richard W.M. Jones wrote: > > More data: I found a colleague who has a Hyper-V instance with a > Windows guest and he helped me to understand how Hyper-V represents > generation IDs. Hyper-V has had support for generation IDs since long > before Microsoft proposed the feature for standardization. Originally > (I think pre-2013) Hyper-V used an XML description which included: > > <generation_id type="string">4a07df4361fdf4c883f97bc30e524b9d</generation_id> > > Note this is a pure hex string, not a GUID. > > In current Hyper-V, the same representation is used but it's embedded > in a binary file. > > My colleague ran two Windows VMs on Hyper-V and examined the > generation_id on the hypervisor and compared it to the output of > VMGENID.EXE inside the guest. > > The first guest had this in the binary hypervisor metadata: > > 000056b0 00 00 0e 67 65 6e 65 72 61 74 69 6f 6e 5f 69 64 |...generation_id| > 000056c0 00 40 00 00 00 38 00 30 00 35 00 61 00 32 00 38 |.@...8.0.5.a.2.8| > 000056d0 00 37 00 61 00 32 00 35 00 30 00 39 00 38 00 39 |.7.a.2.5.0.9.8.9| > 000056e0 00 65 00 34 00 66 00 65 00 36 00 66 00 36 00 39 |.e.4.f.e.6.f.6.9| > 000056f0 00 39 00 32 00 62 00 65 00 33 00 33 00 34 00 61 |.9.2.b.e.3.3.4.a| > 00005700 00 34 00 33 00 00 00 00 00 00 00 00 00 00 00 00 |.4.3............| > > and reported the output of VMGENID in this guest as: > > VmCounterValue: fe6f6992be334a43:805a287a250989e4 > > The second guest had: > > 00005360 c5 06 00 00 00 0e 67 65 6e 65 72 61 74 69 6f 6e |......generation| > 00005370 5f 69 64 00 40 00 00 00 65 00 62 00 66 00 62 00 |_id.@...e.b.f.b.| > 00005380 62 00 37 00 39 00 37 00 33 00 36 00 35 00 37 00 |b.7.9.7.3.6.5.7.| > 00005390 32 00 38 00 65 00 37 00 30 00 62 00 33 00 66 00 |2.8.e.7.0.b.3.f.| > 000053a0 64 00 33 00 63 00 37 00 31 00 33 00 65 00 63 00 |d.3.c.7.1.3.e.c.| > 000053b0 65 00 38 00 34 00 32 00 00 00 00 00 00 00 00 00 |e.8.4.2.........| > > and VMGENID was: > > VmCounterValue: b3fd3c713ece842:ebfbb797365728e7 > > Note: > > - In both cases, the generation ID is clearly not a GUID. > > - The two 64 bit words are swapped over somewhere, but individual > bytes are not byte-swapped, and there is again no evidence of > UUID-aware byte swapping. > > ---------------------------------------------------------------------- > > So how do we get from where we are to a more sane vmgenid in qemu? > > I propose we deprecate the guid parameter in: > > -device vmgenid,guid=8987940a-0951-2cc5-e815-10634ff550b9,id=vmgenid0 > > Instead it will be replaced by bytes= which will simply write > the bytes, in the order they appear, into guest memory with no > attempt to interpret or byte-swap. Something like: > > -device vmgenid,bytes=112233445566778899aabbccddeeff00,id=vmgenid0 > > (guid although deprecated will need to be kept around for a while, > along with its weird byte-swapping behaviour). > > We will then have a plain and simple method to emulate the behaviour > of other hypervisors. We will look at exactly what bytes they write > to guest memory and copy that behaviour when v2v converting from those > hypervisors. I don't have anything against this, I just don't know who's going to implement the QEMU change. Thanks Laszlo
