Been fighting some problems with VMware Auto Deploy lately which turned out to be an easy to solve issue. I installed the first host in the cluster, which would NOT be deployed with Auto Deploy but had a local hard disk in it. Configured it the way I like it, set all the logging and network coredump location to be the vCenter host and then created a host profile. The network configuration consisted of just two vmnics (10Gbps) in a dvSwitch. The vmkernel port was of course on the dvSwitch. After this host was working fine, I copied the host profile and used this copied profile as the reference profile for the hosts that WOULD be using Auto Deploy.
When deploying the remaining hosts, I could get them to work the first time and register them in vCenter, but after the profile had been applied and the answer file was updated, the host would drop from vCenter. What happened is that after reboot the host would show in vCenter again, then a few seconds later vCenter would trigger applying the host profile and then the host would drop from the network. Closer investigation showed that when the host would return after reboot, it has a standard vSwitch with only a vmkernel portgroup on it, connected to one vmnic. As soon as the host profile is applied, the host will migrate the vmkernel port from the standard vSwitch to the dvSwitch.
However….. when a network coredump location is configured, the vmkernel port is “locked”. The vmkernel is unable to migrate the vmkernel port from the standard vSwitch to the dvSwitch and will fail. Problem is that it doesn’t fail back to the last good network configuration but it will just “leave it hanging”. As a result your host is disconnected from the network. You can reconnect it again by going to the DCUI and reset your network.
Solution: Don’t configure a network coredump location: esxcli system coredump network set –enable false
2 thoughts on “Adding ESXi host with dvSwitch through Auto Deploy fails”
Nice article. FYI more info on the netdump limitation with VDS: http://kb.vmware.com/kb/2000781
Comments are closed.