• NSX upgrade fails
• Connecting virtual machines to a logical switch fails
• Re-connecting the virtual machine to a logical switch fail
• You see the error:
  
  Failed to connect virtual device ethernet0
  
  
• In the /var/log/vmkernel.log file on the ESXi host, you see entries similar to:
  
  <YYYY-MM-DD>T<time> .833Z cpu16:1138415)WARNING: vxlan: VDL2PortPropSet:672: Failed to set control plane property for port[0x4000016] on VDS[DvsPortset-0] :</time> Would block
  <YYYY-MM-DD>T<time> .833Z cpu16:1138415)WARNING: NetPort: 1431: failed to enable port 0x4000016: </time>Would block
  
  Note: The Would block string is the most definitive symptom of this issue. It is also possible to see the Would block error in your environment when using a mis-configured Host Profile. VMware does not recommend using Host Profiles to create the VXLAN Tunnel End Point (VTEP). In this case, it is different from the issue that is described on this article. For more information, see the Updating the host profiles section in Deploying VXLAN through Auto Deploy and VMware NSX for vSphere 6.x (2092871).
  

• The (VTEP) is not created on the ESXi host.
• Running the command esxcli network vswitch dvs vmware vxlan list displays no output.
• In the vSphere Client or the vSphere Web Client on the vSphere Distributed Switch (vDS), you see entries similar to:
  
  com.vmware.net.overlay.class.missing
  com.vmware.vxlan.instance.notexist

• In the /var/log/vmkernel.log file on the ESXi host, you see entries similar to:
  
  <YYYY-MM-DD>T<time>.480Z cpu24:33371)Net: 221: Created new Tcpip Instance at 0x410a716b2fc0, index 1, name: vxlan, ccalgo: newreno, socketMax: 11000
  <YYYY-MM-DD>T<time>.492Z cpu24:33371)NetOverlay: 1218: class name:vxlan not found
  <YYYY-MM-DD>T<time>.492Z cpu24:33371)NetOverlay: 1326: failed to install overlay instance vxlan: Not found
  <YYYY-MM-DD>T<time>.492Z cpu24:33371)NetOverlay: 1496: Instantiate overlay class:[vxlan] on vds:[DvsPortset-0] failed
  <YYYY-MM-DD>T<time>.492z cpu24:33371)WARNING: vdrb: VdrCreateVxlanTrunk:59: CNXN:[C:dvSwitch-xxxx,P:33554446] Failed to Create VXLAN trunk status: Would block</time></time></time></time></time>

• On a vCloud Director environment, deployment of the Edge fails and you see entries similar to:
  
  Cannot deploy organization VDC network (5b81120a-b0b2-4c54-8861-80633e5dad5c)
  Failed to connect interface of edge gateway edge_gateway_name to organization VDC network VDC_network_name
  java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (10014): Configuration failed on NSX Edge vm vm-1922. ([65280] /sbin/ifconfig vNic_1 up failed :
  
  SIOCSIFFLAGS: Invalid argument
  

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

• In VMware vSphere 6.0 Update 1, host scan operation by EAM fails but NSX host preparation status shows as green incorrectly as the returned unhandled error 99. In releases with a fix for this issue, EAM correctly reports that the host scan failed and raises a vibNotInstalled state. The following example message from the /var/log/eam.log file on the affected ESXi host shows the error code 99.
  
  INFO | 2015-02-25 11:41:32,221 | host-4 | VcPatchManager.java | 356 | Scan result on VcHostSystem(host-383):
  ScanResult {
  errorCode = 99,
  vibUrl = 'https://172.16.224.232/bin/vdn/vibs/5.5/vxlan.zip',
  responseXml = <unset>,
  bulletins = [],
  

• VMware NSX for vSphere 6.1.5, available at VMware Downloads. For more information, see the NSX for vSphere 6.1.5 Release Notes.
• VMware NSX for vSphere 6.2, available at VMware Downloads. For more information, see the NSX for vSphere 6.2.0 Release Notes.

The NSX workaround consists of a detection logic in which NSX Manager checks the preparation status of a host after it is rebooted. If the host is found in the would block state, NSX Manager takes the corrective action by resetting the vSphere Distributed Switch properties, then the VTEP properties, and finally the port properties on the ESXi host. This corrective action repairs the VXLAN configuration without a second host reboot.

In addition, NSX Manager provides an alert that the would block condition was detected and resolved through the following log messages:

• VXLAN opaque data is missing on host host-351, repushing the opaque data.
  
  Note: This log indicates that the remediation has started.

• Reseted the vxlan opaque properties on host host-351.
  
  Note: This log indicates that the remediation has completed.

• Not detected VXLAN opaque data missing on host-351, skip repush the opaque data.
  
  Note: This log indicates that the ESXi host has not encountered any issues on the reboot.

Some virtual machines may start running on the ESXi host before the NSX Manager finishes the detection and remediation described above. These virtual machines remains disconnected even after the ESXi host is repaired. These virtual machines must be connected back the network.

• You have basic authorization with the NSX Manager web credentials such as the admin user, or any vCenter user granted NSX privileges.
• Headers Content-type: application/xml and Accept: application/xml are used.

1. If you see Resolve in the Installation Status column, click Resolve and then refresh your browser window. For more information, see the Prepare Hosts on the Primary NSX Manager section of the Cross-vCenter NSX Installation Guide.
   
2. Standard VIB install with Update Manager or with the esxcli command.
   
   For more information on how to install a VIB on an ESXi host, see Downloading and installing async drivers in VMware ESXi 5.x and ESXi 6.0.x (2005205). Also, see Installing patches on an ESXi 5.x/6.x host from the command line (2008939)
   
   Note: After the above commands are run:
   
   • Reboot each of the ESXi host where the force install succeeded. (For example, VIBs are not skipped)
   • NSX Installation tab resolve on cluster is required to detect that VIBs are now correctly installed
   
   If the NSX Agent has not been deployed:
   
   
   • Remove ESX from cluster
   • Reboot
   • Add ESX to cluster

What is fixed in vSphere 6.0 Update 2

• In vCenter Server 6.0U2 and ESXi 5.5P8, for the case of live NSX VIB installation on new (not yet prepared) hosts, EAM now reports a partial installation (For example: NSX VIBs have been installed on the running image but not on boot disk). In vSphere versions without this change, an error condition, such as another VIB (For example, ixgbe driver VIB), can prevent the NSX VIBs from being copied to the boot disk, and EAM reports a successful NSX installation / Host Ready status.
• A new esxupdate error code with reboot the host immediate is reported when there is a live VIB installation failure caused by jumpstart plugins, rc scripts or init.d scripts.
• A new error code with Please reboot the host immediately to discard the unfinished message is reported when there is a live NSX VIB installation failure. The failed NSX VIB is not reported as installed. The new error code and message are reported to NSX User Interface (UI).
  

Detect if alt-bootbank is not up to date and do a force install

To detect if the alt-bootbank is not up-to-date, use the --dry-run option. Output is installed (instead of skipped) if alt-bootbank is not up to date, run this command:

esxcli software vib install --no-live-install --force --dry-run --depot /path/vxlan.zip

Key:
--force | -f
Bypasses checks for package dependencies, conflicts, obsolescence, and acceptance levels. Really not recommended unless you know what you are doing. Use of this option will result in a warning being displayed in the vSphere Client.

--no-live-install
Forces an install to /altbootbank even if the VIBs are eligible for live installation or removal. This causes the installation to be skipped on PXE-booted hosts.

--dry-run
Performs a dry-run only. Report the VIB-level operations that would be performed, but do not change anything in the system.

--depot | -d
Specifies full remote URLs of the depot index.xml or server file path pointing to an offline bundle .zip file.

For more information, see the esxcli software section of the vSphere Command-Line Interface Documentation.

On any ESXi host where the alt-bootbank is not up to date, run the same command without the --dry-run option.

esxcli software vib install --no-live-install --force --depot /path/vxlan.zip

• Check if standard image shows VIBs installed.
• Check if ESXi host is currently connected to VXLAN.
• Test Force install VIBs to bring alternate boot bank up to date.
  
  set VI_USERNAME=root
  set VI_PASSWORD=password
  @echo off
  for %%e in (ESX01 ESX02 ESX03 …) do (
  echo %%e
  REM Check: standard image shows vibs installed
  "c:\Program Files (x86)\VMware\VMware vSphere CLI\bin\esxcli" -s %%e software vib list | findstr -i "vxlan vsip switch-security" | find /C "VMware"
  REM test if ESX currently connected to VXLAN
  "c:\Program Files (x86)\VMware\VMware vSphere CLI\bin\esxcli" -s %%e network vswitch dvs vmware vxlan list
  REM Check force install does not succeed i.e. alternate boot bank is up to date
  "c:\Program Files (x86)\VMware\VMware vSphere CLI\bin\esxcli" -s %%e software vib install --no-live-install --force --dry-run --depot /vmfs/volumes/55d393fd-0de6432f-19b2-8cdcd4b521e8/NSX/vxlan.zip
  )
  
  For more information on vCLI, see the vSphere Command-Line Interface Documentation.

PowerCLI method:

$vcServer = "vCenter01"
$cluster = "CL01"
$esxCred = Get-Credential
#Connect to vCenter
Connect-VIServer $vcServer | Out-Null
#Connect to ESX hosts in cluster
foreach ($esx in Get-Cluster $cluster | Get-VMHost) {
Connect-VIServer $esx -Credential $esxCred | Out-Null
}
#Retrieve the esxcli instances and loop through them
foreach($esxcli in Get-EsxCli) {
$esxcli.software.vib.list() | Where-Object {$_ -like "vxlan"}
$esxcli.network.vswitch.dvs.vmware.vxlan.list()
$esxcli.software.vib.install( --no-live-install --force --dry-run –depot)

}

#Disconnect from ESX hosts
foreach ($esx in Get-Cluster $cluster | Get-VMHost) {
Disconnect-VIServer $esx.name -Confirm:$false
}
#Disconnect from vCenter
Disconnect-VIServer $vcServer -Confirm:$false | Out-Null

For more information on PowerCLI, see the vSphere PowerCLI Documentation.