We were facing a problem reinstalling Windows VMs. For example VMs that were still installing fine a month ago, cannot be reinstalled via PXE boot now. After extensive debugging, I found the reason.
Once a VM gets VMware Tools installed (or upgraded to) version 11.3.0 (11360), the .vmx file of the VM gets an additional line: ethernet0.exposeLargeBAR = "TRUE" (at least if the virtual hardware version is 19; didn't see it happen on v15)
When such a VM gets booted with Windows Preinstallation Environment (WinPE) again for reinstallation, there's no network card (vmxnet3) available for that OS, because the driver is older and apparently incompatible with this exposeLargeBAR option (the vmxnet driver loads successfully, but no network card is recognized).
Once this line is removed, everything works again. Or if the vmxnet3 driver 1.9.2 gets manually loaded, it also gets detected.
I've opened a case with VMware GSS two weeks ago, but they even can't find "exposeLargeBAR" in their internal docs and knowledge bases! Google yields zero hits as well...
We also had freshly reinstalled Windows VMs fail at a later stage, when Windows was already running but still with version 10.3 of VMware Tools (that version is in our automated installation method and gets updated later), once the VM gets powered off and on, or even when it just got moved to another host (then the new config value "kicked in", apparently).
So if someone faces mysterious vmxnet3 connection losses, that's something to check (either in the .vmx, or via GUI: VM > Edit Settings > VM Options > Advanced > Edit Configuration Parameters. Removing the TRUE value and powering on the VM will remove the option.
Of course it doesn't happen if you revert a VM via snapshot, because along with the vmxnet3 driver version, also the .vmx config gets reverted. But if someone would restore a backup into a VM container that has been altered, the same situation can happen.
Can you send me the SR number to firstname.lastname@example.org ? Your use case is interesting, i.e. reverting to an OS with an older driver. I agree that the current behavior (that the guest driver is choosing the supported capability) and possible corner cases should be documented better. You can override (without having to remove the the other option) via: vmxnet3.disableLargeBAR