Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2009123

Summary:	Wrong genid is generated when doing certain v2v conversions because of qemu byte-swapping
Product:	Red Hat Enterprise Linux 9	Reporter:	Vera <vwu>
Component:	qemu-kvm	Assignee:	Richard W.M. Jones <rjones>
qemu-kvm sub component:	Devices	QA Contact:	jingzhao <jinzhao>
Status:	CLOSED WONTFIX	Docs Contact:
Severity:	high
Priority:	unspecified	CC:	ailan, coli, jferlan, jinzhao, juzhang, lersek, mprivozn, rjones, virt-maint, xuzhang, yiwei
Version:	9.0	Keywords:	Reopened, Triaged
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-06-22 07:28:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Vera 2021-09-30 02:39:53 UTC

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:

Comment 1 Richard W.M. Jones 2021-09-30 07:35:18 UTC

I believe this to be a bug in qemu-kvm.  See:
https://lists.gnu.org/archive/html/qemu-devel/2021-09/threads.html#07393

Comment 2 Michal Privoznik 2021-10-01 07:27:29 UTC

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.

Comment 4 Richard W.M. Jones 2023-02-28 09:14:26 UTC

This bug still exists in qemu.

Comment 5 RHEL Program Management 2023-03-30 07:28:22 UTC

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.

Comment 7 Richard W.M. Jones 2023-04-06 07:50:35 UTC

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.

Comment 10 Richard W.M. Jones 2023-05-16 15:10:00 UTC

The bug still exists in qemu, so ...

Comment 11 John Ferlan 2023-05-20 11:29:40 UTC

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

Comment 12 Richard W.M. Jones 2023-05-22 11:34:21 UTC

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.

Comment 14 RHEL Program Management 2023-06-22 07:28:20 UTC

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.