On Wed, Sep 29, 2021 at 11:10:35AM +0100, Daniel P. Berrangé wrote:
On Wed, Sep 29, 2021 at 10:57:19AM +0100, Richard W.M. Jones wrote:
> Looking at the qemu code the problem IMHO is:
>
>
https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b19...
>
https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b19...
>
> This byte swapping makes no sense to me. How do we know that the
> guest is little endian? What will this code do for BE guests? I
> think qemu would be better off treating the "GUID" as a list of bytes
> and writing that exactly into the guest memory.
This is an artifact of the HyperV only caring about x86 and thus leaving
endianness unspecified in the spec for GenID. QEMU docs say
Endian-ness Considerations:
---------------------------
Although not specified in Microsoft's document, it is assumed that the
device is expected to use little-endian format.
All GUID passed in via command line or monitor are treated as big-endian.
GUID values displayed via monitor are shown in big-endian format.
So by extension if libvirt is passing the value from its XML straight
to QEMU, then libvirt has effectively defined that the XML is storing
it big-endian too.
This could be where the confusion with VMX config is coming into play,
though the byte re-ordering in v2v seems more complex than just an
endianess-fiddle ?
qemu's qemu_uuid_bswap function only swaps some of the fields.
I think even more that applying qemu_uuid_bswap to these (not really)
"UUIDs" is a nonsense.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v