Bug 2014413

A weird one, but it looks like a valid bug.  I guess we should
assume that vm.genid = 0 in this case.

Can you run VMGENID.EXE inside the guest and see what it prints?
https://bugzilla.redhat.com/show_bug.cgi?id=1598350#c3

Another thing to be aware of: Does libvirt handle this case?
Try running virsh -c ... dumpxml against both the original
and cloned guest and see what libvirt says for the <genid>
field.  This might require another bug against libvirt.

Please ignore comment3, I found guest 'esx7.0-win11-x86_64' will have both vm.genidX and vm.genid in vmx file after powering on, clone a new guest from esx7.0-win11-x86_64 on VMware web client, then check the guest as below:

1.Check the genid info of the guest on ESXi host(guest is power off at this time)
#cat esx7.0-win11-clone/esx7.0-win11-clone.vmx  |grep genid
vm.genidX = "7731431846628452470"

2.Check the genid info of guest by virsh
#  virsh -c vpx://root.198.169/data/10.73.199.217/?no_verify=1 dumpxml esx7.0-win11-clone
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-win11-clone</name>
  <uuid>42034507-9e31-0822-929b-89267c701bba</uuid>
  <genid>00000000-0000-0000-6b4b-904d376e6876</genid>


3.Power on the guest, found guest will have both vm.genidX and vm.genid in vmx file
#cat esx7.0-win11-clone/esx7.0-win11-clone.vmx  |grep genid
vm.genidX = "-8070084918510306187"
vm.genid = "7850450661273421100"

4.Check genid info in guest OS
PS C:\> .\VMGENID.EXE
VmCounterValue: 6cf267486feec52c:90014c8614f4bc75

> #cat esx7.0-win11-clone/esx7.0-win11-clone.vmx  |grep genid
> vm.genidX = "-8070084918510306187"
> vm.genid = "7850450661273421100"

That's weird.  I wonder if VMware noticed that the genid/X entries were
partially missing and generated a completely new genid.

After investigating bug 1598348, I'm going to test & propose the following patch upstream (only compile-tested thus far):

diff --git a/input/parse_domain_from_vmx.ml b/input/parse_domain_from_vmx.ml
index b812edeb81e2..fa3d58b59fed 100644
--- a/input/parse_domain_from_vmx.ml
+++ b/input/parse_domain_from_vmx.ml
@@ -377,9 +377,10 @@ let parse_domain_from_vmx vmx_source =
     let genid_lo = Parse_vmx.get_int64 vmx ["vm"; "genid"]
     and genid_hi = Parse_vmx.get_int64 vmx ["vm"; "genidX"] in
     match genid_lo, genid_hi with
-    | None, None | Some _, None | None, Some _ ->
-       None
-    | Some lo, Some hi ->
+    | None, None -> None
+    | _ ->
+       let lo = Option.default 0_L genid_lo
+       and hi = Option.default 0_L genid_hi in
        (* See docs/vm-generation-id-across-hypervisors.txt *)
        let sub = String.sub (sprintf "%016Lx%016Lx" lo hi) in
        let uuid =

What I think about this bug:

 - How did the guest get created that has only vm.genidX?  It's definitely
   not the case that someone hand-edited the VMX file?

 - (My question in comment 2): If you boot the guest which has only vm.genidX,
   what does VMGENID print in the guest?

 - If you boot the guest which has only vm.genidX set, and shut it down, has
   VMware added a vm.genid entry?  If it adds a vm.genid entry, does it change
   the vm.genidX entry?

(When I next go to the office I'll switch on my VMware machine and try this,
but it's probably going to be tomorrow)

(In reply to Richard W.M. Jones from comment #7)

>  - (My question in comment 2): If you boot the guest which has only
>    vm.genidX, what does VMGENID print in the guest?
>
>  - If you boot the guest which has only vm.genidX set, and shut it
>    down, has VMware added a vm.genid entry?  If it adds a vm.genid
>    entry, does it change the vm.genidX entry?

Here's what I did:

- with the win2019 server domain shut down, I manually removed the
  "vm.genid" entry from the VMX file, preserved only "vm.genidX",

- launched the guest through the ESXi web UI,

- re-checked the VMX file (with the guest just booting), and noticed
  that ESXi *re-added* "vm.genid" immediately, near the end of the file
  (not in the same location). Here's a before-after diff (note that the
  domain is currently running):

> --- win2019.vmx.bak
> +++ win2019.vmx
> @@ -47,7 +47,7 @@
>  sched.mem.shares = "normal"
>  ethernet0.generatedAddress = "00:0c:29:46:9b:0b"
>  vmci0.id = "-2126079221"
> -cleanShutdown = "TRUE"
> +cleanShutdown = "FALSE"
>  sata0:0.startConnected = "TRUE"
>  extendedConfigFile = "win2019.vmxf"
>  ethernet0.uptCompatibility = "TRUE"
> @@ -75,8 +75,7 @@
>  numa.autosize.cookie = "20012"
>  numa.autosize.vcpu.maxPerVirtualNode = "2"
>  sched.swap.derivedName = "/vmfs/volumes/624d796f-52b87554-ccba-a4ae111c9b1b/win2019/win2019-645c6913.vswp"
> -vm.genid = "-5209976526678193832"
> -vm.genidX = "-7907472369019749004"
> +vm.genidX = "-5104727847056752683"
>  pciBridge0.pciSlotNumber = "17"
>  pciBridge4.pciSlotNumber = "21"
>  pciBridge5.pciSlotNumber = "22"
> @@ -94,7 +93,7 @@
>  vmotion.svga.graphicsMemoryKB = "16384"
>  ethernet0.generatedAddressOffset = "0"
>  monitor.phys_bits_used = "45"
> -softPowerOff = "TRUE"
> +softPowerOff = "FALSE"
>  toolsInstallManager.lastInstallError = "0"
>  toolsInstallManager.updateCounter = "3"
>  svga.guestBackedPrimaryAware = "TRUE"
> @@ -103,6 +102,7 @@
>  scsi0:0.redo = ""
>  svga.vramSize = "16777216"
>  guestOS.detailed.data = ""
> +vm.genid = "-802103094701856339"
>  usb_xhci:4.present = "TRUE"
>  usb_xhci:4.deviceType = "hid"
>  usb_xhci:4.port = "4"

  Thus, not only is "vm.genid" re-added in a different spot upon guest
  launch in the VMX file, but even the *values* of both "vm.genid" and
  "vm.genidX" change.

- In this state, VMGENID.EXE reports hex values in the guest that
  correspond to the *regenerated* "vm.genid" and "vm.genidX" entries:

  f4de5b7c2f0de9ad:b9285d11b1233fd5

  In brief: I cannot reproduce the issue.

- After shutting down the guest, the diff (against the BAK file I saved
  originally) shrinks to:

> --- win2019.vmx.bak
> +++ win2019.vmx
> @@ -75,8 +75,7 @@
>  numa.autosize.cookie = "20012"
>  numa.autosize.vcpu.maxPerVirtualNode = "2"
>  sched.swap.derivedName = "/vmfs/volumes/624d796f-52b87554-ccba-a4ae111c9b1b/win2019/win2019-645c6913.vswp"
> -vm.genid = "-5209976526678193832"
> -vm.genidX = "-7907472369019749004"
> +vm.genidX = "-5104727847056752683"
>  pciBridge0.pciSlotNumber = "17"
>  pciBridge4.pciSlotNumber = "21"
>  pciBridge5.pciSlotNumber = "22"
> @@ -103,6 +102,7 @@
>  scsi0:0.redo = ""
>  svga.vramSize = "16777216"
>  guestOS.detailed.data = ""
> +vm.genid = "-802103094701856339"
>  usb_xhci:4.present = "TRUE"
>  usb_xhci:4.deviceType = "hid"
>  usb_xhci:4.port = "4"

  IOW, the "cleanShutdown" and "softPowerOff" hunks disappear
  (consistently with me having cleanly shut down the guest), and the
  regenerated vmgenid halves (both of them) persist.

For now I'm going to set "Devel Cond-NAK: reproducer" on this (I don't doubt it can be reproduced by cloning, but I don't have the necessary setup for cloning).

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.

Reopen because of stupid stale bug nonsense.