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