The problem
I had the issue with a crashed vCenter Server which was configured on an non-ephemeral portgroup and was disconnected. As the vCenter Server was down, and the portgroup was a non-ephemeral one, no new ports could be allocated. In that particular case a new standard vSwitch has to be created, vCenter needs to be connected to the VSS for the boot process, until it can be reconnected to the vDS again.
The solution
Here is the procedure I used in this situation:
- Verify that the vCenter is down and the NIC is not connected to the portgroup
- Connect via ssh to the host (e.g. using PuTTY). Note that if ssh is not enabled on the host, it has to be enabled first.
- Create a new vSwitch to be used to temporarily connect the vCenter
esxcfg-vswitch -a vSwitch0
- Create a new PortGroup
esxcfg-vswitch -A VMNetwork vSwitch0
- List the vSwitches and vDS to get the ID of the vmnic to remove from vDS
[root@hostname:~] esxcfg-vswitch -l
Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 11776 1 128 1500
PortGroup Name VLAN ID Used Ports Uplinks
VMNetwork 1 0
DVS Name Num Ports Used Ports Configured Ports MTU Uplinks
vDSname 11776 12 512 9000 vmnic0,vmnic2
DVPort ID In Use Client
42 1 vmnic0
43 1 vmnic2
5 1 vmk0
18 1 vmk1
8 1 vmk2- Remove vmnic0 from the vDS:
esxcfg-vswitch -Q vmnic0 -V 42 vDSname
- Add vmnic0 to vSwitch0:
esxcli network vswitch standard uplink add --uplink-name=vmnic0 --vswitch-name=vSwitch0
- Start vCenter Server in the host client
- Once the vCenter is up, clean up the temporary configuration:
– Connect the vCenter to the Portgroup on the vDS again. Note that to avoid this issue in future, the portgroup for the vCenter should be ephemeral.
– Reconnect vmnic0 to the vDS
– Remove the temporary VSS (vSwitch0) and the portgroup
you are life saver, thank you 🙂
Question on the ephemeral port. Some people say you should create the port group with the ephemeral setting but leave vcenter static until there is an issue. When you have an issue connect to the host running vcenter and just change it to the ephemeral group. You state to just have vcenter already on the ephemeral setting, which makes more sense. Can you think why they may be doing it the other way?
I usually keep one management portgroup with ephemeral binding for vCenter Server (and in the meantime also NSX appliances) for recovery purposes. If your whole environment is down for any reason (or at least your vCenter like in the above scenario), you’ll be able to recover quicker than with the static setting.
In VMware validated designs, VMware state that “Port-level permissions and controls are lost across power cycles, so no historical context is saved.”
On top, performance might be slightly impacted when using ephemeral binding.
However I still prefer in most cases to be able to recover from a failure, accepting the impact on the design.
This however might not be the case for every design.