Description of problem: The genid generated by libvirt is wrong Version-Release number of selected component (if applicable): libvirt-7.7.0-3.el9.x86_64 virt-v2v-1.45.3-3.el9.x86_64 qemu-kvm-6.1.0-3.el9.x86_64 How reproducible: 100% Steps to Reproduce: Step 1: Check the vm.genid and wm.genidX values in vmx file # cat esx6.7-win2019-x86_64/esx6.7-win2019-x86_64.vmx |grep genid vm.genid = "-8536691797830587195" vm.genidX = "-1723453263670062919" 2. nstalled VMGENID.EXE in \Temp of ESX VM and running it (on VMware) prints: 8987940a09512cc5:e81510634ff550b9 3. check the genid value direcly from ESX serer via virsh # virsh -c vpx://root.73.141/data/10.73.75.219/?no_verify=1 dumpxml esx6.7-win2019-x86_64 .... <genid>8987940a-0951-2cc5-e815-10634ff550b9</genid> 4. convert from vmx virt-v2v -i vmx -o libvirt -of raw -os v2v_dir --mac 00:50:56:ac:59:8d:network:default /esx-images/esx6.7/esx6.7-win2019-x86_64/esx6.7-win2019-x86_64.vmx -on esx6.7-win2019-x86_64_fromVMX -v -x |& tee > /v2vfromVMX.log 4. check genid in xml of the VM <domain type='kvm'> <!-- generated by virt-v2v 1.45.3rhel=9,release=3.el9 --> <name>esx6.7-win2019-x86_64_fromVMX</name> <genid>09512cc5-940a-8987-b950-f54f631015e8</genid> Actual results: The genid generated by libvirt is different from the genid calcualted by vmgenid.exe. Expected results: The genid should be the same as the one calculated by vmgenid.exe Additional info:
I believe this to be a bug in qemu-kvm. See: https://lists.gnu.org/archive/html/qemu-devel/2021-09/threads.html#07393
There's a long conversation on the libvir-list on this topic: https://listman.redhat.com/archives/libvir-list/2021-September/msg00931.html It's now believed that it's qemu who has the bug, not libvirt.
This bug still exists in qemu.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
It's not the same as Bug 1118834. It's a bug in how that feature was implemented. I wrote an article about VM genIDs which should help: https://github.com/libguestfs/virt-v2v/blob/master/docs/vm-generation-id-across-hypervisors.txt Basically any use of GUID is wrong, so the whole fundamental basic way qemu + Linux implement this feature is wrong. Any question involving GUIDs doesn't make sense.
The bug still exists in qemu, so ...
(In reply to Richard W.M. Jones from comment #10) > The bug still exists in qemu, so ... Then is there an upstream issue on this? Is someone actually working on it? Does it really matter to RHEL? If it doesn't really matter to RHEL, then the RHEL bug should be closed DEFERRED, and wait for upstream fix. My recollection on the genid in qemu was it was a long process to actually get the support added and then the work was abandoned (I was a libvirt developer at the time adding the genid support to libvirt). I see upstream Ani Sinha added himself as a reviewer of vmgenid and that it's listed as an orphaned device. Perhaps this bug can be re-assigned to Ani since he now works for Red Hat, but I still think we should create the upstream issue and close the RHEL bug.
I did look into fixing this in qemu but it's quite tricky to make a fix which is backwards compatible, and involves dealing with QOM weirdness, so I didn't get very far. It would probably be easy for someone who deals with qemu full time. I have set the stale date to now + 1 month.