Re: [PATCH 0/1] vmx: Fix <genid/> mapping
On Wed, Sep 29, 2021 at 10:20:44AM +0100, Richard W.M. Jones wrote:
On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote:
> Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it
> was brought up in a private thread that libvirt doesn't report correct
> UUIDs. For instance for the following input:
>
> vm.genid = "-8536691797830587195"
> vm.genidX = "-1723453263670062919"
(The two lines above come from a VMware .vmx file)
The only thing that really matters is what the guest sees. I ran
VMGENID.EXE (https://bugzilla.redhat.com/show_bug.cgi?id=1598350#c3
https://docs.microsoft.com/en-gb/windows/win32/hyperv_v2/virtual-machine-...)
inside the guest and it showed:
8987940a09512cc5:e81510634ff550b9
Note these numbers are the hex equivalents of the VMware .vmx numbers:
>>> print("%x" % (2**64-8536691797830587195))
8987940a09512cc5
>>> print("%x" % (2**64-1723453263670062919))
e81510634ff550b9
> Libvirt would report:
>
> <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid>
>
> while virt-v2v would report:
>
> <genid>09512cc5-940a-8987-b950-f54f631015e8</genid>
After thinking about this a bit more, IMHO the real problem is
with qemu. If you pass this to qemu:
-device vmgenid,guid=8987940a-0951-2cc5-e815-10634ff550b9,id=vmgenid0
then inside the guest VMGENID shows 2cc509518987940a:b950f54f631015e8 (wrong)
If you pass this to qemu:
...guid=09512cc5-940a-8987-b950-f54f631015e8...
then inside the guest it sees 8987940a09512cc5:e81510634ff550b9
(the correct values, matching VMware).
This is the reason why virt-v2v mangles the GUID, in order to trick
libvirt into passing a mangled GUID which gets mangled again by qemu
which is the same as unmangling it.
So another way to fix this could be for us to fix qemu. We could just
pass the two numbers to qemu instead of using GUIDs, eg:
-device vmgenid,low=0x8987940a09512cc5,high=0xe81510634ff550b9,id=vmgenid0
and then we'd fix the implementation in qemu so that the low/high
values match what is seen by VMGENID.EXE in the guest.
Or we could have libvirt use the current GUID in <genid> but to do the
mangling when it gets passed through to qemu (instead of virt-v2v
doing the mangling).
On the libvirt side, the #1 most important thing is that a given
XML string
<genid>8987940a-0951-2cc5-e815-10634ff550b9</genid>
results in the same value being exposed to the guest OS, for both
the QEMU and VMWare drivers. Whehter the guest sees the bytes in
the same order is not essential, but it would be less of a surprise
if it did match.
Ultimately as long as the mapping from libvirt XML to guest visible
string is consistent across drivers, that's sufficient.
Adding qemu-devel because I'm interesting to see if the qemu
developers would prefer to fix this properly in qemu.
No matter what order QEMU accepts the data in, it can be said to be
functionally correct. If the order is "unusual" though, it ought to
at least be documented how the QEMU order corresponds to guest visible
order.
Incidentally I wonder how much to trust VMGENID.EXE and whether that
actally reports what it gets out of guest memory "as is", or whether
it has done any byte re-ordering.
I'm curious what Linux kernel sees for the genid on Vmware vs KVM
hosts, as probably I'd trust that data more ?
Regards,
Daniel
--
|: 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 :|