> Did I miss something? Is there a way to make this not happen?
I have a theory that would explain the behavior - have not tested it but it makes perfect sense to me ....
The virtal hardware for a VM will be created at the first start of the VM.
The instructions for each different VM will be read from the vmx-file.
And now comes the point that you may not be aware of ....
The syntax for the vmx-file uses what I call "silent defaults"
The probably best known example for a "silent default" is this one:
scsi0.present = "true"
This means that the behaviour is: always create new VMs with a SCSI-controller unless the instructions in vmx read as
scsi0.present = "false"
As far as I know there is no official documentation for silent defaults and the values have changed over the years.
To explain the behaviour you see the following assumptions make perfect sense to me:
ethernet0.present = "true"
The value for ethernet0.virtualDev depends on the guestOS parameter so for your selected guestOS we can assume another silent default to be:
ethernet0.virtualDev = "e1000"
We can also assume that
ethernet0.addressType = "vpx"
is another one.
So we have 3 rules to apply when creating a new ESXi VM with guestOS-type you selected:
ethernet0.present = "true"
ethernet0.virtualDev = "e1000"
ethernet0.addressType = "vpx"
So the behaviour will be:
you always get one networkcard when creating a new VM unless you explicitely disable it by setting ethernet0.present = "false"
for the guestOS you selected you will always get an e1000 unless you order a different one.
ethernet0 will be always mapped to vSwitch0 unless specified otherwise.
Now ESXi has all the info to fill the other ethernet0 parameters automatically - like mac address and so on.
Next your VM boots and will create an unexpected ethernet device.
If the VM boots in an environment that has a vSwich0 all parameters are valid and you will see a functional nic inside the VM.
If the VM boots somewhere where no vSwitch0 exists - for example in your case with distributed switches only - then I would expect that you get a VM with no working nic.
Not sure if ESXi disables an ethernet device if there is no backend - it may also allow such a config - but then you would get a phantom nic in the registry of a Windows VM.
If it works like this it would prefectly explain why the suggested workaround is supposed to work
It also explains why you an obscure behaviour if you use procedures that create a vmx-file using a newer scripted procedure.
The vmx-syntax rules need to be consistent across versions and need to be backward compatible.
The result is the behaviour you see:
when using scripts to create a new VM you expect to get NO device unless you order one.
following vmx-syntax rules the same assumption would work in most cases:
you get NO USB-port unless you order one
you get NO second nic unless you order one.
... and so on ...
BUT here we have a few exceptions where the logic is reversed:
you get the first SCSI-controller unless you explicitely say that you dont want one.
you get the first ethernet-controller unless you explicitely say that you dont want one.
I may be totally wrong with this theory - but for me it makes sense.
You should be able to test this with some examples ...
Ulli