Description: VMware supports genid in its vmx metadata files, eg: vm.genid = "7344585841658099715" vm.genidX = "-8483171368186442967" However the <genid> tag does not appear when dumping the XML of this guest> # virsh -c vpx://root@xx/data/10.73.72.61/?no_verify=1 dumpxml esx6.0-win2012r2-x86_64 Enter root's password for xx: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx6.0-win2012r2-x86_64</name> <uuid>564d5c84-172a-0ecd-05c9-14003ce70ae3</uuid> [etc] We expect to see <genid> here, as described here: https://libvirt.org/formatdomain.html#elementsMetadata
Hmm, genid should be a UUID, which means 16 unsigned bytes. I guess vm.genid and vm.genidX are 8 byte signed integers which are supposed to be combined to form the full 16 byte UUID.
Hopefully these links will help: https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg02019.html https://github.com/libguestfs/libguestfs/blob/b11b870166b7ae27f728dbb58b6498788bf97329/v2v/input_vmx.ml#L430
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.
I'm sorry, this bug was closed in error by the "stale bugs" process.
Patch posted to the list: https://listman.redhat.com/archives/libvir-list/2021-July/msg00855.html
Pushed upstream: 7d661d6e20 vmx: Parse vm.genid v7.6.0-2-g7d661d6e20
Test the bug with below builds: libvirt-libs-7.6.0-2.module+el8.5.0+12219+a5ea13d2.x86_64 qemu-img-6.0.0-27.module+el8.5.0+12121+c40c8708.x86_64 Steps: 1.Prepare a VMware windows guest which has both vm.genid and vm.genidX in vmx file # cat esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmx |grep genid vm.genidX = "-4711986729966890469" vm.genid = "6683475107232079980" 2.Use virsh to dump the guest xml from VMware # virsh -c vpx://root.198.169/data/10.73.199.217/?no_verify=1 dumpxml esx7.0-win2019-x86_64 Enter root's password for 10.73.198.169: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx7.0-win2019-x86_64</name> <uuid>4203fb76-a391-6c63-86cf-7e6a25f6285a</uuid> <genid>5cc07933-0fbb-e06c-be9b-a908c5f8121b</genid> ..... 3.Prepare a VMware windows guest which only has only vm.genidX in vmx file # cat esx6.7-win8.1-i386/esx6.7-win8.1-i386.vmx |grep genid vm.genidX = "4685629850823382880" 4. Use virsh to dump the guest xml from VMware # virsh -c vpx://root.73.141/data/10.73.75.219/?no_verify=1 dumpxml esx6.7-win8.1-i386 Enter root's password for 10.73.73.141: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx6.7-win8.1-i386</name> <uuid>422c2275-8391-d308-9e5f-b8f1b76c8ea0</uuid> <genid>00000000-0000-0000-4106-b386174b5760</genid> ...... 5.Prepare a VMware windows guest which only has only vm.genid in vmx file # cat esx6.5-win2016-genid/esx6.5-win2016-x86_64.vmx |grep genid vm.genid = "-5258618877951871830" 6. Use virsh to dump the guest xml from VMware # virsh -c vpx://root.73.141/data/10.73.196.89/?no_verify=1 dumpxml esx6.5-win2016-only-genid Enter root's password for 10.73.73.141: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx6.5-win2016-only-genid</name> <uuid>564daf5c-8938-3f47-7453-b4cb12a280fb</uuid> <genid>b705a1fd-ea83-f4aa-0000-000000000000</genid> ...... Result: virsh can generate genid in guest xml from VMware
Hi Richard, Could you please help to confirm if the test result of step3 ~ step6 of comment11 is expected? This is what I said in the mail, virsh can generate <genid> tag in libvirtxml from VMware as long as vm.genidX or vm.genid is existed in guest vmx file, thanks!
I've not been convinced that real VMX files from VMware exist that only contain vm.genid or only vm.genidX. However if they did then the results given by libvirt seem reasonable.
Verify the bug with below builds: libvirt-libs-7.6.0-2.module+el8.5.0+12219+a5ea13d2.x86_64 qemu-img-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64 Steps: 1.Prepare a VMware windows guest which has both vm.genid and vm.genidX in vmx file # cat esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmx |grep genid vm.genidX = "-4711986729966890469" vm.genid = "6683475107232079980" 2.Use virsh to dump the guest xml from VMware # virsh -c vpx://root.198.169/data/10.73.199.217/?no_verify=1 dumpxml esx7.0-win2019-x86_64 Enter root's password for 10.73.198.169: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx7.0-win2019-x86_64</name> <uuid>4203fb76-a391-6c63-86cf-7e6a25f6285a</uuid> <genid>5cc07933-0fbb-e06c-be9b-a908c5f8121b</genid> ..... 3.Prepare a VMware windows guest which only has only vm.genidX in vmx file # cat esx6.7-win8.1-i386/esx6.7-win8.1-i386.vmx |grep genid vm.genidX = "4685629850823382880" 4. Use virsh to dump the guest xml from VMware # virsh -c vpx://root.73.141/data/10.73.75.219/?no_verify=1 dumpxml esx6.7-win8.1-i386 Enter root's password for 10.73.73.141: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx6.7-win8.1-i386</name> <uuid>422c2275-8391-d308-9e5f-b8f1b76c8ea0</uuid> <genid>00000000-0000-0000-4106-b386174b5760</genid> ...... 5.Prepare a VMware windows guest which only has only vm.genid in vmx file # cat esx6.5-win2016-genid/esx6.5-win2016-x86_64.vmx |grep genid vm.genid = "-5258618877951871830" 6. Use virsh to dump the guest xml from VMware # virsh -c vpx://root.73.141/data/10.73.196.89/?no_verify=1 dumpxml esx6.5-win2016-only-genid Enter root's password for 10.73.73.141: <domain type='vmware' xmlns:vmware='http://libvirt.org/schemas/domain/vmware/1.0'> <name>esx6.5-win2016-only-genid</name> <uuid>564daf5c-8938-3f47-7453-b4cb12a280fb</uuid> <genid>b705a1fd-ea83-f4aa-0000-000000000000</genid> ...... Result: virsh can generate genid in guest xml from VMware, move the bug from ON_QA to VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (virt:av bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4684