vmexplorer

The evolution of vMotion

• Scaled VMware vSphere vMotion operations: Starting with vCenter Server 7.0 Update 2, vSphere vMotion automatically adapts to make full use of high speed networks such as 25 GbE, 40 GbE and 100 GbE with a single vMotion VMkernel interface, up from maximum 10 GbE in previous releases. For more information, see Networking Best Practices for vSphere vMotion and the vMotion Improvements in vSphere 7 blog. Learn About the vMotion Improvements in vSphere 7 (8 min video)

• vSphere With Tanzu Load Balancer support encompasses access to the Supervisor Cluster, Tanzu Kubernetes Grid clusters and to Kubernetes Services of Type LoadBalancer deployed in the TKG clusters.   Users are allocated a single Virtual IP (VIP) to access the Supervisor Cluster Kubernetes API.  Traffic is spread across the three Kubernetes Controllers that make up the Supervisor Cluster.  Read more here….

• New CLI deployment of vCenter Server: With vCenter Server 7.0 Update 2, by using the vCSA_with_cluster_on_ESXi.json template, you can bootstrap a single node vSAN cluster and enable vSphere Lifecycle Manager cluster image management when deploying vCenter Server on an ESXi host. For more information, see JSON Templates for CLI Deployment of the vCenter Server Appliance.
• Parallel remediation on hosts in clusters that you manage with vSphere Lifecycle Manager baselines: With vCenter Server 7.0 Update 2, to reduce the time needed for patching or upgrading the ESXi hosts in your environment, you can enable vSphere Lifecycle Manager to remediate in parallel the hosts within a cluster by using baselines. You can remediate in parallel only ESXi hosts that are already in maintenance mode. You cannot remediate in parallel hosts in a vSAN cluster. For more information, see Remediating ESXi Hosts Against vSphere Lifecycle Manager Baselines and Baseline Groups.
• Improved vSphere Lifecycle Manager error messages: vCenter Server 7.0 Update 2 introduces improved error messages that help you better understand the root cause for issues such as skipped nodes during upgrades and updates, or hardware compatibility, or ESXi installation and update as part of the Lifecycle Manager operations.
• Increased scalability with vSphere Lifecycle Manager: With vCenter Server 7.0 Update 2, scalability for vSphere Lifecycle Manager operations with ESXi hosts and clusters is up to 400 supported ESXi hosts managed by a vSphere Lifecycle Manager Image from 280.
• Upgrade and migration from NSX-T-managed Virtual Distributed Switches to vSphere Distributed Switches: By using vSphere Lifecycle Manager baselines, you can upgrade your system to vSphere 7.0 Update 2 and simultaneously migrate from NSX-T-managed Virtual Distributed Switches to vSphere Distributed Switches for clusters enabled with VMware NSX-T Data Center. For more information, see Using vSphere Lifecycle Manager to Migrate an NSX-T Virtual Distributed Switch to a vSphere Distributed Switch.
• Create new clusters by importing the desired software specification from a single reference host: With vCenter Server 7.0 Update 2, you can save time and effort to ensure that you have all necessary components and images available in the vSphere Lifecycle Manager depot before creating a new cluster by importing the desired software specification from a single reference host. You do not compose or validate a new image, because during image import, vSphere Lifecycle Manager extracts in the vCenter Server instance where you create the cluster the software specification from the reference host, as well as the software depot associated with the image. You can import an image from an ESXi host that is in the same or a different vCenter Server instance. You can also import an image from an ESXi host that is not managed by vCenter Server, move the reference host to the cluster or use the image on the host and seed it to the new cluster without moving the host. For more information, see Create a Cluster That Uses a Single Image by Importing an Image from a Host.
• Enable vSphere with Tanzu on a cluster managed by the vSphere Lifecycle Manager: As a vSphere administrator, you can enable vSphere with Tanzu on vSphere clusters that you manage with a single VMware vSphere Lifecycle Manager image. You can then use the Supervisor Cluster while it is managed by vSphere Lifecycle Manager. For more information, see Working with vSphere Lifecycle Manager.
• vSphere Lifecycle Manager fast upgrades: Starting with vSphere 7.0 Update 2, you can configure vSphere Lifecycle Manager to suspend virtual machines to memory instead of migrating them, powering them off, or suspending them to disk. For more information, see Configuring vSphere Lifecycle Manager for Fast Upgrades.
• Confidential vSphere Pods on a Supervisor Cluster in vSphere with Tanzu: Starting with vSphere 7.0 Update 2, you can run confidential vSphere Pods, keeping guest OS memory encrypted and protected against access from the hypervisor, on a Supervisor Cluster in vSphere with Tanzu. You can configure confidential vSphere Pods by adding Secure Encrypted Virtualization-Encrypted State (SEV-ES) as an extra security enhancement. For more information, see Deploy a Confidential vSphere Pod.
• In-product feedback: vCenter Server 7.0 Update 2 introduces an in-product feedback option in the vSphere Client to enable you provide real-time rating and comments on key VMware vSphere workflows and features.

• Deprecation of SSPI, CAC and RSA: In a future vSphere release, VMware plans to discontinue support for Windows Session Authentication (SSPI), Common Access Card (CAC), and RSA SecurID for vCenter Server. In place of SSPI, CAC, or RSA SecurID, users and administrators can configure and use Identity Federation with a supported Identity Provider to sign in to their vCenter Server system.
• Removal of SHA1 from Secure Shell (SSH): In vSphere 7.0 Update 2, the SHA-1 cryptographic hashing algorithm is removed from the SSHD default configuration.
• Support for Federal Information Processing Standards (FIPS): FIPS will be added to and enabled by default in vCenter Server in a future release of vSphere. FIPS support is also available but not enabled by default in vCenter Server 7.0 Update 2, and can be enabled by following the steps described in vCenter Server and FIPS.
• Client plug-ins compliance with FIPS: In a future vSphere release, all client plug-ins for vSphere must become compliant with the Federal Information Processing Standards (FIPS). When FIPS is enabled by default in the vCenter Server, you cannot use local plug-ins that do not conform to the standards. For more information, see Preparing Local Plug-ins for FIPS Compliance.
• PowerCLI support for updating vSphere Native Key Providers: PowerCLI support for updating vSphere Native Key Providers will be added in an upcoming PowerCLI release. For more information, see VMware knowledge base article 82732.
• Site Recovery Manager 8.4 and vSphere Replication 8.4 support: If virtual machine encryption is switched on, Site Recovery Manager 8.4 and vSphere Replication 8.4 do not support vSphere 7.0 Update 2.

• vRealize Network Insight 5.1/5.2/5.3 limitations with vSphere 7.0, Project Pacific and NSX-T 3.0 with VDS 7.0 (78492)

• Depreciation of /rest APIs is planned for the next major version;  Use of /api is the preferred method.
  • Deprecation of cookie based interaction with vSphere REST APIs (vAPIs) (78315)
  • REST API Modernization
  • Upgrade paths possible from vCenter 6.5.0 onwards

Refer to our Interoperability Matrix for more product support notices.

vCenter Server Configuration  |   vCenter Server and Host Management

Faster vMotion Makes Balancing Workloads Invisible

vSphere With Tanzu – NSX Advanced Load Balancer Essentials

The AI-Ready Enterprise Platform: Unleashing AI for Every Enterprise

REST API Modernization

Learn About the vMotion Improvements in vSphere 7 (8 min video)

vSphere Lifecycle Manager – Host Seeding Demo (5 min video)

This lab showcases what is new in vSphere 7.0 with regards to performance.

HOL-2113-01-SDC – vSphere with Tanzu

vSphere 7 with Tanzu is the new generation of vSphere for modern applications and it is available standalone on vSphere or as part of VMware Cloud Foundation

HOL-2147-01-ISM Accelerate Machine Learning in vSphere Using GPUs

In this lab, you will learn how you can accelerate Machine Learning Workloads on vSphere using GPUs. VMware vSphere combines GPU power with the management benefits of vSphere

L3 Networking

OSPFv2 Support on Tier-0 Gateways

NSX-T Data Center now supports OSPF version 2 as a dynamic routing protocol between Tier-0 gateways and physical routers. OSPF can be enabled only on external interfaces and can all be in the same OSPF area (standard area or NSSA), even across multiple Edge Nodes. This simplifies migration from the existing NSX for vSphere deployment already using OSPF to NSX-T Data Center.

NSX Data Center for vSphere to NSX-T Data Center Migration

Support of Universal Objects Migration for a Single Site

You can migrate your NSX Data Center for vSphere environment deployed with a single NSX Manager in Primary mode (not secondary). As this is a single NSX deployment, the objects (local and universal) are migrated to local objects on a local NSX-T.  This feature does not support cross-vCenter environments with Primary and Secondary NSX Managers.

Migration of NSX-V Environment with vRealize Automation – Phase 2

The Migration Coordinator interacts with vRealize Automation (vRA) to migrate environments where vRealize Automation provides automation capabilities. This release adds additional topologies and use cases to those already supported in NSX-T 3.1.0.

Modular Migration for Hosts and Distributed Firewall

The NSX-T Migration Coordinator adds a new mode to migrate only the distributed firewall configuration and the hosts, leaving the logical topology(L3 topology, services) for you to complete. You can benefit from the in-place migration offered by the Migration Coordinator (hosts moved from NSX-V to NSX-T while going through maintenance mode, firewall states and memberships maintained, layer 2 extended between NSX for vSphere and NSX-T during migration) that lets you (or a third party automation) deploy the Tier-0/Tier-1 gateways and relative services, hence giving greater flexibility in terms of topologies. This feature is available from UI and API.

Modular Migration for Distributed Firewall available from UI

The NSX-T user interface now exposes the Modular Migration of firewall rules. This feature was introduced in 3.1.0 (API only) and allows the migration of firewall configurations, memberships and state from an NSX Data Center for vSphere environment to an NSX-T Data Center environment. This feature simplifies lift-and-shift migration where you vMotion VMs between an environment with hosts with NSX for vSphere and another environment with hosts with NSX-T by migrating firewall rules and keeping states and memberships (hence maintaining security between VMs in the old environment and the new one).

Fully Validated Scenario for Lift and Shift Leveraging vMotion, Distributed Firewall Migration and L2 Extension with Bridging

This feature supports the complete scenario for migration between two parallel environments (lift and shift) leveraging NSX-T bridge to extend L2 between NSX for vSphere and NSX-T, the Modular Distributed Firewall.

Identity Firewall

NSX Policy API support for Identity Firewall configuration – Setup of Active Directory, for use in Identity Firewall rules, can now be configured through NSX Policy API (https://<nsx-mgr>/policy/api/v1/infra/firewall-identity-stores), equivalent to existing NSX Manager API (https://<nsx-mgr>/api/v1/directory/domains).

Advanced Load Balancer Integration

Support Policy API for Avi Configuration

The NSX Policy API can be used to manage the NSX Advanced Load Balancer configurations of virtual services and their dependent objects. The unique object types are exposed via the https://<nsx-mgr>/policy/api/v1/infra/alb-<objecttype> endpoints.

Service Insertion Phase 2

​This feature supports the Transparent LB in NSX-T advanced load balancer (Avi). Avi sends the load balanced traffic to the servers with the client’s IP as the source IP. This feature leverages service insertion to redirect the return traffic back to the service engine to provide transparent load balancing without requiring any server-side modification.

Edge Platform and Services

DHCPv4 Relay on Service Interface

Tier-0 and Tier-1 Gateways support DHCPv4 Relay on Service Interfaces, enabling a 3rd party DHCP server to be located on a physical network

AAA and Platform Security

Guest Users – Local User accounts: NSX customers integrate their existing corporate identity store to onboard users for normal operations of NSX-T. However, there is an essential need for a limited set of local users — to aid identity and access management in many scenarios. Scenarios such as (1) the ability to bootstrap and operate NSX during early stages of deployment before identity sources are configured in non-administrative mode or (2) when there is failure of communication/access to corporate identity repository. In such cases, local users are effective in bringing NSX-T to normal operational status. Additionally, in certain scenarios such as (3) being able to manage NSX in a specific compliant-state catering to industry or federal regulations, use of local guest users are beneficial. To enable these use-cases and ease-of-operations, two guest local-users have been introduced in 3.1.1, in addition to existing admin and audit local users. With this feature, the NSX admin has extended privileges to manage the lifecycle of the users (e.g., Password rotation, etc.) including the ability to customize and assign appropriate RBAC permissions. Please note that the local user capability is available on both NSX-T Local Managers (LM) and Global Managers (GM) but is unavailable on edge nodes in 3.1.1 via API and UI. The guest users are disabled by default and have to be explicitly activated for consumption and can be disabled at any time.
FIPS Compliant Bouncy Castle Upgrade: NSX-T 3.1.1 contains an updated version of FIPS compliant Bouncy Castle (v1.0.2.1). Bouncy Castle module is a collection of Java based cryptographic libraries, functions, and APIs. Bouncy Castle module is used extensively on NSX-T Manager. The upgraded version resolves critical security bugs and facilitates compliant and secure operations of NSX-T.

NSX Cloud

NSX Marketplace Appliance in Azure: Starting with NSX-T 3.1.1, you have the option to deploy the NSX management plane and control plane fully in Public Cloud (Azure only, for NSX-T 3.1.1. AWS will be supported in a future release). The NSX management/control plane components and NSX Cloud Public Cloud Gateway (PCG) are packaged as VHDs and made available in the Azure Marketplace. For a greenfield deployment in the public cloud, you also have the option to use a ‘one-click’ terraform script to perform the complete installation of NSX in Azure.

NSX Cloud Service Manager HA: In the event that you deploy NSX management/control plane in the public cloud, NSX Cloud Service Manager (CSM) also has HA. PCG is already deployed in Active-Standby mode thereby enabling HA.

NSX-Cloud for Horizon Cloud VDI enhancements: Starting with NSX-T 3.1.1, when using NSX Cloud to protect Horizon VDIs in Azure, you can install the NSX agent as part of the Horizon Agent installation in the VDIs. This feature also addresses one of the challenges with having multiple components ( VDIs, PCG, etc.) and their respective OS versions. Any version of the PCG can work with any version of the agent on the VM. In the event that there is an incompatibility, the incompatibility is displayed in the NSX Cloud Service Manager (CSM), leveraging the existing framework.

Operations

UI-based Upgrade Readiness Tool for migration from NVDS to VDS with NSX-T Data Center

To migrate Transport Nodes from NVDS to VDS with NSX-T, you can use the Upgrade Readiness Tool present in the Getting Started wizard in the NSX Manager user interface. Use the tool to get recommended VDS with NSX configurations, create or edit the recommended VDS with NSX, and then automatically migrate the switch from NVDS to VDS with NSX while upgrading the ESX hosts to vSphere Hypervisor (ESXi) 7.0 U2.

Licensing

Enable VDS in all vSphere Editions for NSX-T Data Center Users: Starting with NSX-T 3.1.1, you can utilize VDS in all versions of vSphere. You are entitled to use an equivalent number of CPU licenses to use VDS. This feature ensures that you can instantiate VDS.

Container Networking and Security

This release supports a maximum scale of 50 Clusters (ESXi clusters) per vCenter enabled with vLCM, on clusters enabled for vSphere with Tanzu as documented at configmax.vmware.com

Retention Period of Unassigned Tags: In NSX-T 3.0.x, NSX Tags with 0 Virtual Machines assigned are automatically deleted by the system after five days. In NSX-T 3.1.0, the system task has been modified to run on a daily basis, cleaning up unassigned tags that are older than one day. There is no manual way to force delete unassigned tags.

Duplicate certificate extensions not allowed:

Starting with NSX-T 3.1.1, NSX-T will reject x509 certificates with duplicate extensions (or fields) following RFC guidelines and industry best practices for secure certificate management. Please note this will not impact certificates that are already in use prior to upgrading to 3.1.1. Otherwise, checks will be enforced when NSX administrators attempt to replace existing certificates or install new certificates after NSX-T 3.1.1 has been deployed.

API & CLI Resources  |  Resolved Issues  |  Known Issues

Troubleshooting Upgrade Failures  |  Upgrading Federation Deployment

ESXi 7.0 Update 1c | ISO Build 17325551

• Physical NIC statistics: vCenter Server 7.0 Update 1c adds five physical NIC statistics:droppedRx, droppedTx, errorsRx, RxCRCErrors and errorsTx, to the hostd.log file at /var/run/log/hostd.log to enable you detect uncorrected networking errors and take necessary corrective action

• Advanced Cross vCenter vMotion: With vCenter Server 7.0 Update 1c, in the vSphere Client, you can use the Advanced Cross vCenter vMotion feature to manage the bulk migration of workloads across vCenter Server systems in different vCenter Single Sign-On domains. Advanced Cross vCenter vMotion does not depend on vCenter Enhanced Linked Mode or Hybrid Linked Mode and works for both on-premise and cloud environments. Advanced Cross vCenter vMotion facilitates your migration from VMware Cloud Foundation 3 to VMware Cloud Foundation 4, which includes vSphere with Tanzu Kubernetes Grid, and delivers a unified platform for both VMs and containers, allowing operators to provision Kubernetes clusters from vCenter Server. The feature also allows smooth transition to the latest version of vCenter Server by simplifying workload migration from any vCenter Server instance of 6.x or later

• Parallel remediation on hosts in clusters that you manage with vSphere Lifecycle Manager baselines: With vCenter Server 7.0 Update 1c, you can run parallel remediation on ESXi hosts in maintenance mode in clusters that you manage with vSphere Lifecycle Manager baselines

• Third-party plug-ins to manage services on the vSAN Data Persistence platform: With vCenter Server 7.0 Update 1c, you can enable third-party plug-ins to manage services on the vSAN Data Persistence platform from the vSphere Client, the same way you manage your vCenter Server system. For more information, see the vSphere with Tanzu Configuration and Management documentation.

• Supervisor Namespace Isolation with Dedicated T1 Router – Supervisor Clusters using NSX-T network uses a new topology where each namespace has its own dedicated T1 router.

·      Newly created Supervisor Clusters uses this new topology automatically.

·      Existing Supervisor Clusters are migrated to this new topology during an upgrade

• Supervisor Clusters Support NSX-T 3.1.0 – Supervisor Clusters is compatible with NSX-T 3.1.0

• Supervisor Cluster Version 1.16.x Support Removed – Supervisor Cluster Version 1.16.x is now removed. Supervisor Clusters running 1.16.x should be upgraded to a new version

Tanzu Kubernetes Grid Service for vSphere

• HTTP/HTTPS Proxy Support  – Newly created Tanzu Kubernetes clusters can use a global HTTP/HTTPS Proxy for egress traffic as well as for pulling container images from internet registries.
• Integration with Registry Service – Newly created Tanzu Kubernetes clusters work out of the box with the vSphere Registry Service. Existing clusters, once updated to a new version, also work with the Registry Service.
• Configurable Node Storage  – Tanzu Kubernetes clusters can now mount an additional storage volume to virtual machines thereby increasing available node storage capacity. This enables users to deploy larger container images that might exceed the default 16GB root volume size.
• Improved status information – WCPCluster and WCPMachine Custom Resource Definitions now implement conditional status reporting. Successful Tanzu Kubernetes cluster lifecycle management depends on a number of subsystems (for example, Supervisor, storage, networking) and understanding failures can be challenging. Now WCPCluster and WCPMachine CRDs surface common status and failure conditions to ease troubleshooting.

Missing new default VM Classes introduced in vSphere 7.0 U1

• After upgrading to vSphere 7.0.1, and then performing a vSphere Namespaces update of the Supervisor Cluster, running the command “kubectl get virtualmachineclasses” did not list the new VM class sizes 2x-large, 4x-large, 8x-large. This has been resolved and all Supervisor Clusters will be configured with the correct set of default VM Classes. 

• With ESXi 7.0 Update 1c, you can use the –remote-host-max-msg-len parameter to set the maximum length of syslog messages, to up to 16 KiB, before they must be split. By default, the ESXi syslog daemon (vmsyslogd), strictly adheres to the maximum message length of 1 KiB set by RFC 3164. Longer messages are split into multiple parts. Set the maximum message length up to the smallest length supported by any of the syslog receivers or relays involved in the syslog infrastructure

• With ESXi 7.0 Update 1c, you can use the installer boot option systemMediaSize to limit the size of system storage partitions on the boot media. If your system has a small footprint that does not require the maximum 138 GB system-storage size, you can limit it to the minimum of 33 GB. The systemMediaSize parameter accepts the following values:

• • min (33 GB, for single disk or embedded servers)
  • small (69 GB, for servers with at least 512 GB RAM)
  • default (138 GB)
  • max (consume all available space, for multi-terabyte servers)

The selected value must fit the purpose of your system. For example, a system with 1TB of memory must use the minimum of 69 GB for system storage. To set the boot option at install time, for example systemMediaSize=small, refer to Enter Boot Options to Start an Installation or Upgrade Script. For more information, see VMware knowledge base article 81166.

• DOM Scrubber enhancement feature to enhance DOM scrubber functionality
• Improvements in checksum verification during write prepare in LLOG
• Persistence in network settings of witness appliance while creating witness VM
• Enhancement in storage capacity/usage calculation on host level
• NFS File bench performance improvements
• LSOM fixes for random high write latency spikes in vSAN all-flash
• File services improvements

NSX for vSphere 6.4 End Of General Support Was Extended to 01/16/2022

lifecycle.vmware.com

• vSphere 7.0 Update 1 Support

• VMware NSX – Functionality Updates for vSphere Client (HTML): The following VMware NSX features are now available through the vSphere Client: Service Definitions for Guest Introspection and Network Introspection. For a list of supported functionality, please see VMware NSX for vSphere UI Plug-in Functionality in vSphere Client.
• Guest Introspection: Adds the ability to change logging level without requiring a restart of 3rd-party Guest Introspection partner service.

For vSphere 6.5:

Recommended: 6.5 Update 3 Build Number 14020092.
Important: If you are using NSX Guest Introspection on vSphere 6.5, vSphere 6.5 P03 or higher is recommended.

VMware Product Interoperability Matrix | NSX-V 6.4.9 & vSphere 6.5

For vSphere 6.7:

Recommended: 6.7 Update 2
Important:  If you are using NSX Guest Introspection on vSphere 6.7, please refer to Knowledge Base Article KB57248 prior to installing NSX 6.4.6, and consult VMware Customer Support for more information.

For vSphere 7, Update 1 is now supported

Note vSphere 6.0 has reached End of General Support and is not supported with NSX 6.4.7 onwards.

Guest Introspection for Windows

It is recommended that you upgrade VMware Tools to 10.3.10 before upgrading NSX for vSphere.

End of Life and End of Support Warnings

For information about NSX and other VMware products that must be upgraded soon, please consult the VMware Lifecycle Product Matrix.

• NSX for vSphere 6.1.x reached End of Availability (EOA) and End of General Support (EOGS) on January 15, 2017. (See also VMware knowledge base article 2144769.)
• vCNS Edges no longer supported. You must upgrade to an NSX Edge first before upgrading to NSX 6.3 or later.
• NSX for vSphere 6.2.x has reached End of General Support (EOGS) as of August 20, 2018.

General Behavior Changes

If you have more than one vSphere Distributed Switch, and if VXLAN is configured on one of them, you must connect any Distributed Logical Router interfaces to port groups on that vSphere Distributed Switch. Starting in NSX 6.4.1, this configuration is enforced in the UI and API. In earlier releases, you were not prevented from creating an invalid configuration.  If you upgrade to NSX 6.4.1 or later and have incorrectly connected DLR interfaces, you will need to take action to resolve this. See the Upgrade Notes for details.

In NSX 6.4.7, the following functionality is deprecated in vSphere Client 7.0:

• NSX Edge: SSL VPN-Plus (see KB79929 for more information)
• Tools: Endpoint Monitoring (all functionality)
• Tools: Flow Monitoring (Flow Monitoring Dashboard, Details by Service, and Configuration)
• System Events: NSX Ticket Logger

For the complete list of NSX installation prerequisites, see the System Requirements for NSX section in the NSX Installation Guide.

For installation instructions, see the NSX Installation Guide or the NSX Cross-vCenter Installation Guide.

Also refer to the complete Deprecated and Discontinued Functionality for all depreciated features, API Removals and Behavior Changes

• To upgrade NSX, you must perform a full NSX upgrade including host cluster upgrade (which upgrades the host VIBs). For instructions, see the NSX Upgrade Guide including the Upgrade Host Clusters section.
• Upgrading NSX VIBs on host clusters using VUM is not supported. Use Upgrade Coordinator, Host Preparation, or the associated REST APIs to upgrade NSX VIBs on host clusters.
• System Requirements: For information on system requirements while installing and upgrading NSX, see the System Requirements for NSX section in NSX documentation.
• Upgrade path for NSX: The VMware Product Interoperability Matrix provides details about the upgrade paths from VMware NSX.
• Cross-vCenter NSX upgrade is covered in the NSX Upgrade Guide.
• Downgrades are not supported:
  • Always capture a backup of NSX Manager before proceeding with an upgrade.
  • Once NSX has been upgraded successfully, NSX cannot be downgraded.
• To validate that your upgrade to NSX 6.4.x was successful see knowledge base article 2134525.
• There is no support for upgrades from vCloud Networking and Security to NSX 6.4.x. You must upgrade to a supported 6.2.x release first.
• Interoperability: Check the VMware Product Interoperability Matrix for all relevant VMware products before upgrading.
  • Upgrading to NSX Data Center for vSphere 6.4.7: VIO is not compatible with NSX 6.4.7 due to multiple scale issues.
  • Upgrading to NSX Data Center for vSphere 6.4: NSX 6.4 is not compatible with vSphere 5.5.
  • Upgrading to NSX Data Center for vSphere 6.4.5: If NSX is deployed with VMware Integrated OpenStack (VIO), upgrade VIO to 4.1.2.2 or 5.1.0.1, as 6.4.5 is incompatible with previous releases due to spring package update to version 5.0.
  • Upgrading to vSphere 6.5: When upgrading to vSphere 6.5a or later 6.5 versions, you must first upgrade to NSX 6.3.0 or later. NSX 6.2.x is not compatible with vSphere 6.5. See Upgrading vSphere in an NSX Environment in the NSX Upgrade Guide.
  • Upgrading to vSphere 6.7: When upgrading to vSphere 6.7 you must first upgrade to NSX 6.4.1 or later. Earlier versions of NSX are not compatible with vSphere 6.7. See Upgrading vSphere in an NSX Environment in the NSX Upgrade Guide.
• Partner services compatibility: If your site uses VMware partner services for Guest Introspection or Network Introspection, you must review the  VMware Compatibility Guide before you upgrade, to verify that your vendor’s service is compatible with this release of NSX.
• Networking and Security plug-in: After upgrading NSX Manager, you must log out and log back in to the vSphere Web Client. If the NSX plug-in does not display correctly, clear your browser cache and history. If the Networking and Security plug-in does not appear in the vSphere Web Client, reset the vSphere Web Client server as explained in the NSX Upgrade Guide.
• Stateless environments: In NSX upgrades in a stateless host environment, the new VIBs are pre-added to the Host Image profile during the NSX upgrade process. As a result, NSX on stateless hosts upgrade process follows this sequence:
• Service Definitions functionality is not supported in NSX 6.4.7 UI with vSphere Client 7.0:
  For example, if you have an old Trend Micro Service Definition registered with vSphere 6.5 or 6.7, follow any one of these two options:
• 1. Option #1: Before upgrading to vSphere 7.0, navigate to the Service Definition tab in the vSphere Web Client, edit the Service Definition to 7.0, and then upgrade to vSphere 7.0.
  2. Option #2: After upgrading to vSphere 7.0, run the following NSX API to add or edit the Service Definition to 7.0.

POST  https://<nsmanager>/api/2.0/si/service/<service-id>/servicedeploymentspec/versioneddeploymentspec

• For new installs of NSX Data Center for vSphere 6.4.2, the NSX components (Manager, Controller, Edge, Guest Introspection) are on VM Hardware version 11.
• For upgrades to NSX Data Center for vSphere 6.4.2, the NSX Edge and Guest Introspection components are automatically upgraded to VM Hardware version 11. The NSX Manager and NSX Controller components remain on VM Hardware version 8 following an upgrade. Users have the option to upgrade the VM Hardware to version 11. Consult KB (https://kb.vmware.com/s/article/1010675) for instructions on upgrading VM Hardware versions.
• For new installs of NSX 6.3.x, 6.4.0, 6.4.1, the NSX components (Manager, Controller, Edge, Guest Introspection) are on VM Hardware version 8.

NSX Manager Upgrade

• Important: If you are upgrading NSX 6.2.0, 6.2.1, or 6.2.2 to NSX 6.3.5 or later, you must complete a workaround before starting the upgrade. See VMware Knowledge Base article 000051624 for details.
• If you are upgrading from NSX 6.3.3 to NSX 6.3.4 or later you must first follow the workaround instructions in VMware Knowledge Base article 2151719.
• If you use SFTP for NSX backups, change to hmac-sha2-256 after upgrading to 6.3.0 or later because there is no support for hmac-sha1. See VMware Knowledge Base article 2149282  for a list of supported security algorithms.
• When you upgrade NSX Manager to NSX 6.4.1, a backup is automatically taken and saved locally as part of the upgrade process. See Upgrade NSX Manager for more information.
• When you upgrade to NSX 6.4.0, the TLS settings are preserved. If you have only TLS 1.0 enabled, you will be able to view the NSX plug-in in the vSphere Web Client, but NSX Managers are not visible. There is no impact to datapath, but you cannot change any NSX Manager configuration. Log in to the NSX appliance management web UI at https://nsx-mgr-ip/ and enable TLS 1.1 and TLS 1.2. This reboots the NSX Manager appliance.

Controller Upgrade

• The NSX Controller cluster must contain three controller nodes. If it has fewer than three controllers, you must add controllers before starting the upgrade. See Deploy NSX Controller Cluster for instructions.
• In NSX 6.3.3, the underlying operating system of the NSX Controller changes. This means that when you upgrade from NSX 6.3.2 or earlier to NSX 6.3.3 or later, instead of an in-place software upgrade, the existing controllers are deleted one at a time, and new Photon OS based controllers are deployed using the same IP addresses.

When the controllers are deleted, this also deletes any associated DRS anti-affinity rules. You must create new anti-affinity rules in vCenter to prevent the new controller VMs from residing on the same host.

See Upgrade the NSX Controller Cluster for more information on controller upgrades.

 Host Cluster Upgrade

• If you upgrade from NSX 6.3.2 or earlier to NSX 6.3.3 or later, the NSX VIB names change.
  The esx-vxlan and esx-vsip VIBs are replaced with esx-nsxv if you have NSX 6.3.3 or later installed on ESXi 6.0 or later.
• Rebootless upgrade and uninstall on hosts: On vSphere 6.0 and later, once you have upgraded from NSX 6.2.x to NSX 6.3.x or later, any subsequent NSX VIB changes will not require a reboot. Instead hosts must enter maintenance mode to complete the VIB change. This affects both NSX host cluster upgrade, and ESXi upgrade. See the NSX Upgrade Guide for more information.

​NSX Edge Upgrade

• Validation added in NSX 6.4.1 to disallow an invalid distributed logical router configurations: In environments where VXLAN is configured and more than one vSphere Distributed Switch is present, distributed logical router interfaces must be connected to the VXLAN-configured vSphere Distributed Switch only. Upgrading a DLR to NSX 6.4.1 or later will fail in those environments if the DLR has interfaces connected to the vSphere Distributed Switch that is not configured for VXLAN. Use the API to connect any incorrectly configured interfaces to port groups on the VXLAN-configured vSphere Distributed Switch. Once the configuration is valid, retry the upgrade. You can change the interface configuration using

PUT /api/4.0/edges/{edgeId} or PUT /api/4.0/edges/{edgeId}/interfaces/{index}. See the NSX API Guide for more information.

• Delete UDLR Control VM from vCenter Server that is associated with secondary NSX Manager before upgrading UDLR from 6.2.7 to 6.4.5:
  In a multi-vCenter environment, when you upgrade NSX UDLRs from 6.2.7 to 6.4.5, the upgrade of the UDLR virtual appliance (UDLR Control VM) fails on the secondary NSX Manager, if HA is enabled on the UDLR Control VM. During the upgrade, the VM with ha index #0 in the HA pair is removed from the NSX database; but, this VM continues to exist on the vCenter Server. Therefore, when the UDLR Control VM is upgraded on the secondary NSX Manager, the upgrade fails because the name of the VM clashes with an existing VM on the vCenter Server. To resolve this issue, delete the Control VM from the vCenter Server that is associated with the UDLR on the secondary NSX Manager, and then upgrade the UDLR from 6.2.7 to 6.4.5.
• Host clusters must be prepared for NSX before upgrading NSX Edge appliances: Management-plane communication between NSX Manager and Edge via the VIX channel is no longer supported starting in 6.3.0. Only the message bus channel is supported. When you upgrade from NSX 6.2.x or earlier to NSX 6.3.0 or later, you must verify that host clusters where NSX Edge appliances are deployed are prepared for NSX, and that the messaging infrastructure status is GREEN. If host clusters are not prepared for NSX, upgrade of the NSX Edge appliance will fail. See Upgrade NSX Edge in the NSX Upgrade Guide for details.
• Upgrading Edge Services Gateway (ESG):
  Starting in NSX 6.2.5, resource reservation is carried out at the time of NSX Edge upgrade. When vSphere HA is enabled on a cluster having insufficient resources, the upgrade operation may fail due to vSphere HA constraints being violated.

To avoid such upgrade failures, perform the following steps before you upgrade an ESG:

The following resource reservations are used by the NSX Manager if you have not explicitly set values at the time of install or upgrade.

1. Always ensure that your installation follows the best practices laid out for vSphere HA. Refer to document KB1002080 .
2. Use the NSX tuning configuration API:
   PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
   ensuring that values for edgeVCpuReservationPercentage and edgeMemoryReservationPercentage fit within available resources for the form factor (see table above for defaults).

• Disable vSphere’s Virtual Machine Startup option where vSphere HA is enabled and Edges are deployed. After you upgrade your 6.2.4 or earlier NSX Edges to 6.2.5 or later, you must turn off the vSphere Virtual Machine Startup option for each NSX Edge in a cluster where vSphere HA is enabled and Edges are deployed. To do this, open the vSphere Web Client, find the ESXi host where NSX Edge virtual machine resides, click Manage > Settings, and, under Virtual Machines, select VM Startup/Shutdown, click Edit, and make sure that the virtual machine is in Manual mode (that is, make sure it is not added to the Automatic Startup/Shutdown list).
• Before upgrading to NSX 6.2.5 or later, make sure all load balancer cipher lists are colon separated. If your cipher list uses another separator such as a comma, make a PUT call to https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles and replace each  <ciphers> </ciphers> list in <clientssl> </clientssl> and <serverssl> </serverssl> with a colon-separated list. For example, the relevant segment of the request body might look like the following. Repeat this procedure for all application profiles:

<applicationProfile>

<name>https-profile</name>

<insertXForwardedFor>false</insertXForwardedFor>

<sslPassthrough>false</sslPassthrough>

<template>HTTPS</template>

<serverSslEnabled>true</serverSslEnabled>

<clientSsl>

<ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>

<clientAuth>ignore</clientAuth>

<serviceCertificate>certificate-4</serviceCertificate>

</clientSsl>

<serverSsl>

<ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>

<serviceCertificate>certificate-4</serviceCertificate>

</serverSsl>

…

</applicationProfile>

• Set Correct Cipher version for Load Balanced Clients on vROps versions older than 6.2.0: vROps pool members on vROps versions older than 6.2.0 use TLS version 1.0 and therefore you must set a monitor extension value explicitly by setting “ssl-version=10” in the NSX Load Balancer configuration. See Create a Service Monitor in the NSX Administration Guide for instructions.

{

“expected” : null,

“extension” : “ssl-version=10”,

“send” : null,

“maxRetries” : 2,

“name” : “sm_vrops”,

“url” : “/suite-api/api/deployment/node/status”,

“timeout” : 5,

“type” : “https”,

“receive” : null,

“interval” : 60,

“method” : “GET”

}

• After upgrading to NSX 6.4.6, L2 bridges and interfaces on a DLR cannot connect to logical switches belonging to different transport zones:  In NSX 6.4.5 or earlier, L2 bridge instances and interfaces on a Distributed Logical Router (DLR) supported use of logical switches that belonged to different transport zones. Starting in NSX 6.4.6, this configuration is not supported. The L2 bridge instances and interfaces on a DLR must connect to logical switches that are in a single transport zone. If logical switches from multiple transport zones are used, edge upgrade is blocked during pre-upgrade validation checks when you upgrade NSX to 6.4.6. To resolve this edge upgrade issue, ensure that the bridge instances and interfaces on a DLR are connected to logical switches in a single transport zone.
• After upgrading to NSX 6.4.7, bridges and interfaces on a DLR cannot connect to dvPortGroups belonging to different VDS: If such a configuration is present, NSX Manager upgrade to 6.4.7 is blocked in pre-upgrade validation checks. To resolve this, ensure that interfaces and L2 bridges of a DLR are connected to a single VDS.
• After upgrading to NSX 6.4.7, DLR cannot be connected to VLAN-backed port groups if the transport zone of logical switch it is connected to spans more than one VDS: This is to ensure correct alignment of DLR instances with logical switch dvPortGroups across hosts. If such configuration is present, NSX Manager upgrade to 6.4.7 is blocked in pre-upgrade validation checks. To resolve this issue, ensure that there are no logical interfaces connected to VLAN-backed port groups, if a logical interface exists with a logical switch belonging to a transport zone spanning multiple VDS.
• After upgrading to NSX 6.4.7, different DLRs cannot have their interfaces and L2 bridges on a same network: If such a configuration is present, NSX Manager upgrade to 6.4.7 is blocked in pre-upgrade validation checks. To resolve this issue, ensure that a network is used in only a single DLR.

Upgrade Notes  |  FIPS Compliance  |  Resolved Issues  |  Known Issues

API Guide  |  vSphere CLI Guide  |  vSphere Configuration Maximums

Firewall Scenarios  |  Identity Firewall Overview  |  Working with Active Directory Domains  |  Using SpoofGuard

Virtual Private Networks (VPN)  |  Logical Load Balancer  |  Other Edge Services

• VMware ESXi
• VMware vCenter
• VMware Workstation Pro / Player (Workstation)
• VMware Fusion Pro / Fusion (Fusion)
• NSX-T
• VMware Cloud Foundation

 Description:
OpenSLP as used in ESXi has a use-after-free issue. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

Known Attack Vectors

A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.

Resolution To remediate CVE-2020-3992 apply the patches listed in the ‘Fixed Version’ column of the ‘Response Matrix’ found below.

Workarounds Workarounds for CVE-2020-3992 have been listed in the ‘Workarounds’ column of the ‘Response Matrix’ below.

Notes

The ESXi patches released on October 20, 2020 did not address CVE-2020-3992 completely. The ESXi patches listed in the Response Matrix below are updated versions that contain the complete fix for CVE-2020-3992.

Workarounds: None

 Workarounds: None

Resolution To remediate CVE-2020-3982 apply the patches listed in the ‘Fixed Version’ column of the ‘Response Matrix’ found below.

 Workarounds: None

Known Attack Vectors A malicious actor with network positioning between vCenter Server and an update repository may be able to perform a session hijack when the vCenter Server Appliance Management Interface is used to download vCenter updates.

Resolution To remediate CVE-2020-3994 apply the patches listed in the ‘Fixed Version’ column of the ‘Response Matrix’ found below.

 Workarounds: None 

Known Attack Vectors A malicious actor with access to a virtual machine may be able to trigger a memory leak issue resulting in memory resource exhaustion on the hypervisor if the attack is sustained for extended periods of time.

 Resolution To remediate CVE-2020-3995 apply the patches listed in the ‘Fixed Version’ column of the ‘Response Matrix’ found below.

 Workarounds: None.

Download
Documentation

VMware ESXi 6.7 ESXi670-202011301-SG  (Updated)
Download
Documentation

VMware ESXi670-202008101-SG  (Included with August’s Release of ESXi670-202008001)

Download
Documentation

 VMware ESXi 6.7 ESXi670-202010401-SG
Download
Documentation

VMware vCenter Server 6.7u3

Download
Documentation

VMware vCenter Server 6.5u3k

Download
Documentation

VMware Workstation Pro 15.6

Download

Documentation

VMware Workstation Player 15.6
Download
Documentation

VMware Fusion 11.5.6
Download
Documentation

 VMware NSX-T 3.0.2
Download
Documentation

 VMware NSX-T 2.5.2.2.0
Download

Documentation

VMware vCloud Foundation 4.1

Download

Documentation

VMware vCloud Foundation 3.10.1 & 3.10.1

Download
Documentation

VMware vCloud Foundation 3.9.0

Download
Documentation

Mitre CVE Dictionary Links:
CVE-2020-3981
CVE-2020-3982
CVE-2020-3992
CVE-2020-3993
CVE-2020-3994
CVE-2020-3995 

FIRST CVSSv3 Calculator:

CVE-2020-3981
CVE-2020-3982 

CVE-2020-3992

CVE-2020-3993

CVE-2020-3994

CVE-2020-3995

2020-11-04 VMSA-2020-0023.1 Updated ESXi patches for section 3a