Hello,
Please excuse me for this long post which I hope is sufficiently clear, I find it a little difficult to express myself in a language other than my own.
In truth, after my last post I continued to go around it, and some of the things I found at that moment can still change depending on other different circumstances that (certainly my limitation) I cannot understand. Let's say that a good starting point is this slightly old but good thread all the same:
https://communities.vmware.com/t5/ESXi-Discussions/Static-MAC-address-not-starting-with-00-50-56/td-...
The essence is that an automatically generated MAC Address in the "00:0C:29.xx.yy.zz" range is implicitly valid thus setting one manually in this same range, should still be valid regardless of any other mechanism today "a problem", because now "reserved" thus "impermissible". When a vCenter version 8.0U2 object finds a virtual machine(s) in its inventory with such a manual MAC address it prevents them from starting, and since it is not possible to manually set a different one, the remedy becomes more complicated than that it should be.
Practical result:
"00:0c:29:27:e7:11 is not an allowed static Ethernet address. It conflicts with VMware reserved MACs. Failed to start the virtual machine. Module DevicePowerOn power on failed. Could not set up "macAddress" for ethernet0. Invalid MAC address specified".
I also noticed that a host that run ESXi version 8.0U2 if you try to manually set a MAC Address within the aforementioned range produces an error saying that it cannot be set because it is "impermissible", but then get sets anyway and the affected VM can no longer start as well.
Practical result:
"Failed to power on virtual machine VM-test. Impermissible static Ethernet address: '00:0c:29:2f:45:9c'. It conflicts with VMware reserved MACs. Click here for more details. dismiss".
With this latest version, when creating a new virtual machine according to the selected GUEST operating system you find yourself with a default USB controller, in version 3.2 from the point of view of a vCenter object and 3.1 from the point of view of an ESXi host, no choice, it must be removed and then added back at which point then you can choose a USB controller version 2.0 or 3.x (as before).
Another thing that worries me quite a bit, what is the expected default behavior for a virtual machine (whether it is a new or pre-existing one) with a hardware level lower than 20 in terms of "chipset.motherboardLayout", I noticed that either after a vMotion operation is performed or because default behavior, with version 8.0 and later I always found this parameter added but it is not clear to me according to "what kind of logic" and whether it is then honored even in the case VHW lower then 20 or not. From my very personal point of view it is not a question of "goat wool" at all.
Practical result:
virtualHW.version = "19"
chipset.motherboardLayout = "acpi"
But if it were just that, one way or another I'll make do anyway.
After the clean deployment of a vCenter 8.0U2 object according to the "Tiny" model I found myself with another set of hassles, after no more than two hours I received the "usual" invitation to add more RAM memory (which I'm now used to ignore) and dozens of events of this kind as warning (never seen before, currently running vCenter object version 8.0U1c):
"Privilege check failed for user VSPHERE.LOCAL\vmware-vsm-37799e0e-cac0-43f7-adde-610f5f1db676 for missing permission Sessions.TerminateSession. Session user performing the check: VSPHERE.LOCAL\vmware-vsm-37799e0e-cac0-43f7-adde-610f5f1db676", "com.vmware.vc.authorization.NoPermission".
Frankly, I don't understand if it's just a cosmetic issue or an indication of a concrete potential problem.
Regards,
Ferdinando
Note for the moderator(s): If you find this post excessively polemical, please remove it. Nonetheless, I agree with the comment of @pmichelli and the OP.
