Home > Blogs > Support Insider

Troubleshooting Virtual SAN 6.2 on disk upgrades which fail after 10%

Posted on by
Leave a reply

This video demonstrates how to troubleshoot Virtual San 6.2 upgrades which fail after 10% of the upgrade procedure. The resolution provided in this video tutorial will be useful to you if you experience the following symptoms within your VMware Virtual SAN environment:

  • When upgrading VMware Virtual SAN (VSAN) to version 6.2, the Virtual SAN Disk Format Conversion task fails at 10%.
  • In the vSphere Web Client, you see an error similar to:

    A general system error occurred: Failed to realign following Virtual SAN objects, due to being locked or lack of vmdk descriptor file which requires manual fix
  • The Convert disk format for Virtual SAN task fails with a General Virtual SAN error status.

When upgrading the on-disk format, during the 10% – 15% phase, Virtual SAN realigns objects to prepare them for new features. The process is performed in two steps:

        • In the first step, Virtual SAN realigns objects and their components to have a 1 MB address space. The process fails in this step if the cluster is unstable or if there is not enough disk space.
        • In the second step, Virtual SAN realigns vsanSparse objects to be 4k aligned. The process fails if there are objects which cannot be upgraded to version 2.5.

An object will fail to upgrade under these conditions:

        • The object is left behind and no longer referenced by anything.
        • The disk chain is not complete or is corrupted.

For additional information, see VMware Knowledge Base article Virtual SAN 6.2 on disk upgrade fails at 10% (2144881).

Top 20 vRealize Automation articles for August 2016

Posted on by
Leave a reply

Top 20Here is our Top 20 vRealize Automation (vRA) articles list for August 2016. This list is ranked by the number of times a VMware Support Request was resolved by following the steps in a published Knowledge Base article.

  1. Unable to add Active Directory users or groups to vCenter Server Appliance or vRealize Automation permissions
  2. Using JXplorer to update the LDAP string for an identity source for VMware vRealize Automation 6.0.x, 6.1.x
  3. Connection between VMware vRealize Automation and embedded vRealize Orchestrator fails with the error: Cannot connect to Orchestrator server
  4. Users are unable to see some infrastructure tabs in vRA 7.0.x
  5. Deleting an endpoint in vRealize Automation fails with the error: This endpoint is being used by # compute resources and # storage paths and cannot be deleted
  6. Connecting to a resource using the Remote Console (VMRC) option in VMware vRealize Automation 6.2.1 fails with the error: Cannot establish a remote console connection
  7. VMware vRealize Orchestrator endpoint data collection fails
  8. Migrating to a new SSO or recovering from a reinstallation of SSO in VMware vRealize Automation
  9. Provisioning multiple virtual machines in VMware vRealize Automation with external workflows fail with Timeout on signal errors
  10. Deploying a virtual machine using a clone workflow in vRealize Automation 6.x fails with the error: The object has already been deleted or has not been completely created
  11. Multi-Machine Blueprint Reported as Partially Succeeded But All the Components Provisioned Correctly
  12. After upgrading the VMware vRealize Automation Identity Appliance to 6.2.3, the vmware-stsd service fails to start
  13. Log locations for VMware vRealize Automation 7.x
  14. Request to destroy a machine fails in VMware vRealize Automation 7.0.x
  15. vRealize Automation services fail when modifying the vIDM database
  16. vRealize Automation 7.X Manager Service extensibility callouts to Event Broker fails
  17. Services take a long time or fail to start in vRealize Automation High Availability environment
  18. Provisioning a machine using VMware vRealize Automation fails with the error: Error executing query usp_SelectHostReservation
  19. Installing or configuring VMware vRealize Automation fails with the error: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms
  20. Mounting a CD-ROM or ISO in vRealize Automation using vRealize Orchestrator

Top 20 vCenter Server articles for August 2016

Posted on by
Leave a reply

Top 20Here is our Top 20 vCenter articles list for August 2016. This list is ranked by the number of times a VMware Support Request was resolved by following the steps in a published Knowledge Base article.

  1. Investigating virtual machine file locks on ESXi/ESX
  2. Using the VMware Knowledge Base
  3. Uploading diagnostic information for VMware through the Secure FTP portal
  4. Correlating build numbers and versions of VMware products
  5. Licensing VMware vCenter Site Recovery Manager
  6. Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x
  7. Resetting the VMware vCenter Server 5.x Inventory Service database
  8. Downloading, licensing, and using VMware products
  9. Build numbers and versions of VMware vCenter Server
  10. How to repoint and re-register vCenter Server 5.1 / 5.5 and components
  11. vSphere handling of LUNs detected as snapshot LUNs
  12. Upgrading to vCenter Server 6.0 best practices
  13. How to consolidate snapshots in vSphere 5.x/6.0
  14. ESXi 5.5 Update 3b and later hosts are not manageable after an upgrade
  15. Collecting diagnostic information for VMware vCenter Server 4.x, 5.x and 6.0
  16. How to enable EVC in vCenter Server
  17. Upgrading to vCenter Server 5.5 best practices
  18. VMware End User License Agreements
  19. “Failed to verify the SSL certificate for one or more vCenter Server Systems” error in the vSphere Web Client
  20. VMware vCenter Server 5.x fails to start with the error: Failed to add LDAP entry

Top 20 NSX articles for August 2016

Posted on by
Leave a reply

Top 20Here is our Top 20 NSX articles list for August 2016. This list is ranked by the number of times a VMware Support Request was resolved by following the steps in a published Knowledge Base article.

  1. Installing VXLAN Agent fails with ESX Agent Manager displaying the error: Agent VIB module not installed
  2. vCenter Server certificate validation error for external solutions in environments with Embedded Platform Services Controller
  3. “The pending transaction requires xxx MB free space” error when installing VIBs
  4. Duplicate VTEPs in ESXi hosts after rebooting vCenter Server
  5. NSX 6.2.3 DLR HA nodes remain in a split brain state
  6. DFW rules using SG not correctly being applied to VMs after NSX 6.2.3 install or upgrade
  7. SNMP MIB module file download
  8. NSX Controller disconnected or isolates intermittently
  9. Virtual machines lose network connectivity in NSX 6.2.x
  10. Network connectivity issues after upgrade in NSX/VCNS environment
  11. NSX is unavailable from the vSphere Web Client Plug-in
  12. vCenter Server or Platform Services Controller certificate validation error for external VMware Solutions in vSphere 6.0
  13. Upgrading VMware vCNS 5.5.x to NSX 6.2.x
  14. NSX Manager consistently at 100% CPU utilization
  15. VMs lose network connectivity in NSX with DLR HA
  16. Collecting diagnostic information for VMware NSX for vSphere 6.x
  17. Installation Status appears as Not Ready in NSX
  18. vCenter Server access is blocked after creating a Deny All rule in DFW
  19. Configuring syslog server for VMware NSX for vSphere 6.x controllers
  20. Configuring the NSX SSO Lookup Service fails

Top 20 Horizon View articles for August 2016

Posted on by
Leave a reply

Top 20Here is our Top 20 Horizon View articles list for August 2016. This list is ranked by the number of times a VMware Support Request was resolved by following the steps in a published Knowledge Base article.

 

  1. Removing invalid linked clone entries automatically using the ViewDBChk tool in VMware Horizon View 5.3 and later versions
  2. Virtual machine application runs slower than expected in ESXi
  3. Finding and removing unused replica virtual machines in the VMware Horizon View
  4. Restart order of the View environment to clear ADLDS (ADAM) synchronization in View 4.5, 4.6, 5.0, 5.1, 5.2, 5.3, 6.0, and 6.1
  5. Linked Clone pool creation and recomposition fails with VMware Horizon View 6.1.x and older releases
  6. Removing a standard (replica) connection server or a security server from a cluster of connection/security servers
  7. Generating a Horizon View SSL certificate request using the Microsoft Management Console (MMC) Certificates snap-in
  8. Manually deleting replica virtual machines in VMware Horizon View 5.x
  9. Confirming that the userinit string is configured properly
  10. Provisioning View desktops fails due to customization timeout errors
  11. The View virtual machine is not accessible and the View Administration console shows the virtual machine status as Already Used
  12. Forcing replication between ADAM databases
  13. Provisioning VMware Horizon View desktops fails with error: View Composer Agent initialization error (16): Failed to activate software license
  14. Administration dashboard in VMware Horizon View reports the error: Server’s certificate cannot be checked
  15. Connecting from the View Client to a VMware View desktop using PCoIP protocol over a WAN fails with the error: The connection to the remote computer ended
  16. Changing the log file behavior in the VMware View components
  17. Determining which replica disk is used for a linked clone virtual machine
  18. Performing an end-to-end backup and restore for VMware View Manager
  19. Network adapter disappears from a Windows virtual machine
  20. Troubleshooting USB redirection problems in VMware View Manager

Top 20 ESXi articles for August 2016

Posted on by
Leave a reply

Top 20Here is our Top 20 ESXi articles list for August 2016. This list is ranked by the number of times a VMware Support Request was resolved by following the steps in a published Knowledge Base article.

  1. Collecting diagnostic information for VMware ESX/ESXi
  2. Snapshot removal task stops at 99% in ESXi/ESX
  3. Support Contracts FAQs
  4. Investigating virtual machine file locks on ESXi/ESX
  5. PSOD with Intel Xeon CPU E5-26xx v4 CPUs
  6. How to purchase and file Pay Per Incident support for VMware products
  7. Using the VMware Knowledge Base
  8. Determining Network/Storage firmware and driver version in ESXi/ESX 4.x, ESXi 5.x, and ESXi 6.x
  9. Uploading diagnostic information for VMware through the Secure FTP portal
  10. Restarting the Management agents in ESXi
  11. Correlating build numbers and versions of VMware products
  12. Licensing VMware vCenter Site Recovery Manager
  13. “esxcli software vib” commands to patch an ESXi 5.x/6.x host
  14. Product offerings for vSphere 5.x
  15. ESXi 5.x with E1000e adapter fails with purple diagnostic screen
  16. Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x
  17. Recreating a missing virtual machine disk descriptor file
  18. How to unmount a LUN or detach a datastore device from ESXi hosts
  19. Collecting diagnostic information for VMware products
  20. Creating a persistent scratch location for ESXi 4.x/5.x/6.0

How to capture performance statistics using Virtual SAN Observer for Virtual SAN

Posted on by
Leave a reply

This video tutorial demonstrates and shows how to capture performance statistics using Virtual SAN Observer for VMware Virtual SAN. For additional information see VMware Knowledge Base article Enabling or capturing performance statistics using Virtual SAN Observer for VMware Virtual SAN (2064240).

While watching this video you will see the necessary steps to launch, collect and display Virtual SAN Observer (VSAN Observer) performance charts and information for VMware Virtual SAN (VSAN).

VSAN Observer is designed to capture performance statistics for a Virtual SAN Cluster and provide access through a web browser and capture the statistics for customer use or for VMware Technical Support.

VMware NSX for vSphere 6.2.4 now available

Posted on by
Leave a reply

VMware has made NSX for vSphere 6.2.4 available for download. NSX 6.2.4 provides critical bug fixes identified in previous releases, and 6.2.4 delivers a security patch for CVE-2016-2079 which is a critical input validation vulnerability for sites that uses NSX SSL VPN.

  • For customers who use SSL VPN, VMware strongly recommends a review of CVE-2016-2079 and an upgrade to NSX 6.2.4.
  • For customers who have installed NSX 6.2.3 or 6.2.3a, VMware recommends installing NSX 6.2.4 to address critical bug fixes.

Caution: Before upgrading, consult the NSX 6.2.4 Release Notes available from the NSX Documentation Center and Recommended minimum version for NSX for vSphere with GID, ESXi, and vCenter Server (2144295).

Critical Alert on 6.2.3 and 6.2.3a for DLR users: For more information, see “Fixed issue 1703913: NSX DLR HA nodes remain in a split-brain state” in the NSX for vSphere 6.2.4 Release Notes and VMware Knowledge Base article NSX 6.2.3 DLR HA nodes remain in a split brain state (2146506). This issue will occur after approximately 24 days of BFD uptime and will continue to reoccur every 24 days.

Customers who are using 6.2.3 or 6.2.3a are strongly advised to review KB 2146506, review how to prevent or remediate the issue, and plan to upgrade to NSX 6.2.4.

vShield Endpoint Update

VMware has announced the End of Availability (EOA) and End of General Support (EOGS) of VMware vCloud Networking and Security 5.5.x. The EOGS date for VMware vCloud Networking and Security 5.5.x is September 19, 2016.  For customers using vCNS Manager specifically to manage vShield Endpoint for agentless anti-virus, Technical Guidance is available until March 31, 2017. For more information, see End of Availability and End of General Support for VMware vCloud Networking and Security 5.5.x (2144733).

For more information on additional partner solution availability, see Implementation of VMware vShield Endpoint beyond vCloud Networking and Security End of Availability (EOA) (2110078).

Note: Consult the VMware Compatibility Guide for Endpoint partner solution certification status before upgrading.  If your preferred solution is not yet certified, contact that vendor.

How to track the top field issues

Path failover may not be successful when using Cisco MDS Switches on NX-OS 7.3 and FCoE based HBAs

Posted on by
1 Reply

So I wanted to get this blog post out sooner rather than later as it might effect a significant number of customers. In a nutshell, if you perform array maintenance that requires you to reboot a storage controller, the probability of successful path failover is low. This is effectively due to stale entries in the fiber channel name server on Cisco MDS switches running NX-OS 7.3, which is a rather new code release. As the title suggests, this only affects FCoE HBAs, specifically ones that rely on our libfc/libfcoe stack for FCoE connectivity. Such HBAs would be Cisco fnic HBAs as well as a handful of Emulex FCoE HBAs and a couple others.

Here is an example of a successful path failover after receiving an RSCN (Register State Change Notification) from the array controller after performing a reboot:

2016-07-07T17:36:34.230Z cpu17:33461)<6>host4: disc: Received an RSCN event
 2016-07-07T17:36:34.230Z cpu17:33461)<6>host4: disc: Port address format for port (e50800)
 2016-07-07T17:36:34.230Z cpu17:33461)<6>host4: disc: RSCN received: not rediscovering. redisc 0 state 9 in_prog 0
 2016-07-07T17:36:34.231Z cpu14:33474)<6>host4: disc: GPN_ID rejected reason 9 exp 1
 2016-07-07T17:36:34.231Z cpu14:33474)<6>host4: rport e50800: Remove port
 2016-07-07T17:36:34.231Z cpu14:33474)<6>host4: rport e50800: Port entered LOGO state from Ready state
 2016-07-07T17:36:34.231Z cpu14:33474)<6>host4: rport e50800: Delete port
 2016-07-07T17:36:34.231Z cpu54:33448)<6>host4: rport e50800: work event 3
 2016-07-07T17:36:34.231Z cpu54:33448)<7>fnic : 4 :: fnic_rport_exch_reset called portid 0xe50800
 2016-07-07T17:36:34.231Z cpu54:33448)<7>fnic : 4 :: fnic_rport_reset_exch: Issuing abts
 2016-07-07T17:36:34.231Z cpu54:33448)<6>host4: rport e50800: Received a LOGO response closed
 2016-07-07T17:36:34.231Z cpu54:33448)<6>host4: rport e50800: Received a LOGO response, but in state Delete
 2016-07-07T17:36:34.231Z cpu54:33448)<6>host4: rport e50800: work delete

Here is a breakdown of what you just read:

  1. RSCN is received from the array controller
  2. Operation is now is state = 9
  3. GPN_ID (Get Port Name ID) is issued to the switches but is rejected because the state is 9 (See http://lists.open-fcoe.org/pipermail/fcoe-devel/2009-June/002828.html)
  4. LibFC begins to remove the port information on the host
  5. Port enters LOGO (Logout) state from previous state, which was Ready
  6. LibFC Deletes the port information

After this the ESX host will failover to other available ports, which would be on the peer SP:

2016-07-07T17:36:44.233Z cpu33:33459)<3> rport-4:0-1: blocked FC remote port time out: saving binding
 2016-07-07T17:36:44.233Z cpu55:33473)<7>fnic : 4 :: fnic_terminate_rport_io called wwpn 0x524a937aeb740513, wwnn0xffffffffffffffff, rport 0x0x4309b72f3c50, portid 0xffffffff
 2016-07-07T17:36:44.257Z cpu52:33320)NMP: nmp_ThrottleLogForDevice:3298: Cmd 0x2a (0x43a659d15bc0, 36277) to dev "naa.624a93704d1296f5972642ea0001101c" on path "vmhba3:C0:T0:L1" Failed: H:0x1 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. Act:FAILOVER

A Host status of H:0x1 means NO_CONNECT, hence the failover.

Now here is an example of the same operation on a Cisco MDS switch running NX-OS 7.3 when a storage controller on the array is rebooted:

2016-07-14T19:02:03.551Z cpu47:33448)<6>host2: disc: Received an RSCN event
 2016-07-14T19:02:03.551Z cpu47:33448)<6>host2: disc: Port address format for port (e50900)
 2016-07-14T19:02:03.551Z cpu47:33448)<6>host2: disc: RSCN received: not rediscovering. redisc 0 state 9 in_prog 0
 2016-07-14T19:02:03.557Z cpu47:33444)<6>host2: rport e50900: ADISC port
 2016-07-14T19:02:03.557Z cpu47:33444)<6>host2: rport e50900: sending ADISC from Ready state
 2016-07-14T19:02:23.558Z cpu47:33448)<6>host2: rport e50900: Received a ADISC response
 2016-07-14T19:02:23.558Z cpu47:33448)<6>host2: rport e50900: Error 1 in state ADISC, retries 0
 2016-07-14T19:02:23.558Z cpu47:33448)<6>host2: rport e50900: Port entered LOGO state from ADISC state
 2016-07-14T19:02:43.560Z cpu2:33442)<6>host2: rport e50900: Received a LOGO response timeout
 2016-07-14T19:02:43.560Z cpu2:33442)<6>host2: rport e50900: Error -1 in state LOGO, retrying
 2016-07-14T19:02:43.560Z cpu58:33446)<6>host2: rport e50900: Port entered LOGO state from LOGO state
 2016-07-14T19:03:03.563Z cpu54:33449)<6>host2: rport e50900: Received a LOGO response timeout
 2016-07-14T19:03:03.563Z cpu54:33449)<6>host2: rport e50900: Error -1 in state LOGO, retrying
 2016-07-14T19:03:03.563Z cpu2:33442)<6>host2: rport e50900: Port entered LOGO state from LOGO state
 2016-07-14T19:03:23.565Z cpu32:33447)<6>host2: rport e50900: Received a LOGO response timeout
 2016-07-14T19:03:23.565Z cpu32:33447)<6>host2: rport e50900: Error -1 in state LOGO, retrying
 2016-07-14T19:03:23.565Z cpu54:33449)<6>host2: rport e50900: Port entered LOGO state from LOGO state
 2016-07-14T19:03:43.567Z cpu50:33445)<6>host2: rport e50900: Received a LOGO response timeout
 2016-07-14T19:03:43.567Z cpu50:33445)<6>host2: rport e50900: Error -1 in state LOGO, retrying
 2016-07-14T19:03:43.567Z cpu32:33447)<6>host2: rport e50900: Port entered LOGO state from LOGO state
 2016-07-14T19:04:03.568Z cpu54:33443)<6>host2: rport e50900: Received a LOGO response timeout
 2016-07-14T19:04:03.568Z cpu54:33443)<6>host2: rport e50900: Error -1 in state LOGO, retrying
 2016-07-14T19:04:03.569Z cpu32:33472)<6>host2: rport e50900: Port entered LOGO state from LOGO state
 2016-07-14T19:04:43.573Z cpu20:33473)<6>host2: rport e50900: Received a LOGO response timeout
 2016-07-14T19:04:43.573Z cpu20:33473)<6>host2: rport e50900: Error -1 in state LOGO, retrying
 2016-07-14T19:04:43.573Z cpu54:33443)<6>host2: rport e50900: Port entered LOGO state from LOGO state

Notice the difference? Here is a breakdown of what happened this time:

  1. RSCN is received from the array controller
  2. Operation is now is state = 9
  3. GPN_ID (Get Port Name ID) is issued to the switches but is NOT rejected
  4. Since GPN_ID is valid, LibFC issues an Address Discovery (ADISC)
  5. 20 seconds later the ADISC sent times out and this continues to occur every 20 seconds

The problem is that the ADISC will continue this behavior until the array controller completes the reboot and is back online:

2016-07-14T19:04:47.276Z cpu56:33451)<6>host2: disc: Received an RSCN event
 2016-07-14T19:04:47.276Z cpu56:33451)<6>host2: disc: Port address format for port (e50900)
 2016-07-14T19:04:47.276Z cpu56:33451)<6>host2: disc: RSCN received: not rediscovering. redisc 0 state 9 in_prog 0
 2016-07-14T19:04:47.277Z cpu20:33454)<6>host2: rport e50900: Login to port
 2016-07-14T19:04:47.277Z cpu20:33454)<6>host2: rport e50900: Port entered PLOGI state from LOGO state
 2016-07-14T19:04:47.278Z cpu57:33456)<6>host2: rport e50900: Received a PLOGI accept
 2016-07-14T19:04:47.278Z cpu57:33456)<6>host2: rport e50900: Port entered PRLI state from PLOGI state
 2016-07-14T19:04:47.278Z cpu52:33458)<6>host2: rport e50900: Received a PRLI accept
 2016-07-14T19:04:47.278Z cpu52:33458)<6>host2: rport e50900: PRLI spp_flags = 0x21
 2016-07-14T19:04:47.278Z cpu52:33458)<6>host2: rport e50900: Port entered RTV state from PRLI state
 2016-07-14T19:04:47.278Z cpu57:33452)<6>host2: rport e50900: Received a RTV reject
 2016-07-14T19:04:47.278Z cpu57:33452)<6>host2: rport e50900: Port is Ready

What is actually happening here is that the Cisco MDS switches are quick to receive the RSCN from the array controller and pass it along to the host HBAs however due to a timing issue the entries for that array controller in the FCNS (Fiber Channel Name Server) database are still present when the host HBAs issue the GPN_ID so the switches respond to that request instead of rejecting it. If you review the entry in http://lists.open-fcoe.org/pipermail/fcoe-devel/2009-June/002828.html you see that code was added to validate that the target is actually off the fabric instead of assuming it would be by the RSCN alone. There are various reasons to do this but suffice it to say that it is better to be safe than sorry in this instance.

Unfortunately there is no fix for this at this time, which is why this is potentially so impactful to our customers since it means they effectively are unable to perform array maintenance without the risk of VMs crashing or even corruption. Cisco is fixing this in 7.3(1), which due out in a few weeks.

Here are a couple of references regarding this issue:

 

Cheers,
Nathan Small
Technical Director
Global Support Services
VMware

NSX for vSphere Field Advisory – July 2016 Edition

Posted on by
1 Reply

This blog has been updated to reflect new information as it was provided. Changes are marked with an *.

VMware NSX for vSphere 6.2.3 Update

  • NSX for vSphere 6.2.3 has an issue that can affect both new NSX customers as well as customers upgrading from previous versions of NSX. The NSX for vSphere 6.2.3 release has been pulled from distribution. The current version available is NSX for vSphere 6.2.2, which is the VMware minimum recommended release.  Refer to KB 2144295. VMware is actively working towards releasing the next version to replace NSX for vSphere 6.2.3 *
  • VMware NSX for vSphere version 6.2.3 delivered a security patch to address a known SSL VPN security vulnerability (CVE-2016-2079) . This issue may allow a remote attacker to gain access to sensitive information. Customers who use SSL VPN are strongly advised to review CVE-2016-2079 and contact VMware support to request immediate assistance. For questions or concerns, contact VMware Support. *
  • The next version of NSX for vSphere contains fixes for bugs that have been found in NSX 6.2.3.
  • Customers who have already upgraded to 6.2.3 are advised to review the following  KB articles:
    • VMware knowledge base article 2146227, VMs using Distributed Firewall (DFW) and Security Groups (SG) may experience connectivity issues. A workaround is available. *
    • VMware knowledgebase article 2146293, Virtual machines lose network connectivity in NSX 6.2.x. *
    • VMware Knowledgebase article 2146413, VMs lose network connectivity in NSX with DLR HA. *

Critical Alert for Edge DLR users on NSX 6.2.3 and 6.2.3a *

  • NSX 6.2.3 DLR HA nodes remain in a split brain state (2146506) *
    • A new issue has been identified that can cause both primary and secondary HA nodes into an Active State, causing network disruption.
    • This issue will occur after approximately 24 days of BFD uptime and will continue to reoccur every 24 days.
    • Customers who are using NSX-V 6.2.3 or 6.2.3a are strongly advised to review KB 2146506, review how to prevent or remediate the issue and plan to upgrade to the next version of NSX.

For questions or concerns, contact VMware Support. To contact VMware support, see Filing a Support Request in My VMware (2006985) or How to Submit a Support Request.

Top NSX for vSphere issues for July 2016

NSX for vSphere 6.2.3 other new and changed issues

Notes:

  • vCloud Director 8.0.1 is now interop-tested and supported with NSX 6.2.3.  For more information, see the VMware Interoperability Matrix
  • VMware is working actively with anti-virus solution partners to influence completion of their certification testing efforts with both NSX 6.2.2 and 6.2.3.  For more information, see the VMware Compatibility Guide (VCG)

Other trending issues

Known interoperability issues during upgrade to NSX for vSphere 6.2.3

Note: VMware vSphere 6.0 supports VIB downloads over port 443 (instead of port 80). This port is opened and closed dynamically. The intermediate devices between the ESXi hosts and vCenter Server must allow traffic using this port.

How to track Top Field Issues

login