Re: [PATCH 0/1] vmx: Fix <genid/> mapping

On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote: (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: 8987940a09512cc5 e81510634ff550b9 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). Adding qemu-devel because I'm interesting to see if the qemu developers would prefer to fix this properly in qemu. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html