It turns out that changing the qemu implementation is painful, particularly if we wish to maintain backwards compatibility of the command line and live migration. Instead I opted to document comprehensively what all the different hypervisors do: https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-across-hypervisors.txt On Thu, Sep 30, 2021 at 10:16:20AM +0100, Richard W.M. Jones wrote: > I was going to suggest something like: > > <genid type="guid">aa-bb-cc..</genid> > or > <genid type="binary">aabbcc..</genid> After thinking about this some more, the real implementation on Windows guest and host is two 64 bit little-endian integers[1]. How about implementing this exactly the same way as Hyper-V (and VMware): <genid type="pair"> <low>0x8877665544332211</low> <high>0x00ffeeddccbbaa99</high> </genid> This would have to be mapped to the following qemu command line: qemu -device vmgenid,guid=44332211-6655-8877-99aa-bbccddeeff00 which would unmangle to the following in guest physical memory: 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff 00 The equivalent back-compat option would be: <genid type="qemu">44332211-6655-8877-99aa-bbccddeeff00</genid> Rich. [1] No one has ever thought what to do about big-endian guests. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/
