• ESXi 7.0 Update 2 supports vSphere Quick Boot on the following servers:
  • Dell Inc. PowerEdge M830, PowerEdge R830. HPE ProLiant XL675d Gen10 Plus. Lenovo   ThinkSystem SR 635,  ThinkSystem SR 655
• Some ESXi configuration files become read-only: As of ESXi 7.0 Update 2, configuration formerly stored in the files  /etc/keymap, /etc/vmware/welcome, /etc/sfcb/sfcb.cfg,  /etc/vmware/snmp.xml,  /etc/vmware/logfilters, /etc/vmsyslog.conf, and /etc/vmsyslog.conf.d/*.conf files, now resides in the ConfigStore database. You can modify this configuration only by using ESXCLI commands, and not by editing files. For more information, see VMware knowledge base articles 82637 and 82638.
• VMware vSphere Virtual Volumes statistics for better debugging: With ESXi 7.0 Update 2, you can track performance statistics for vSphere Virtual Volumes to quickly identify issues such as latency in third-party VASA provider responses. By using a set of commands, you can get statistics for all VASA providers in your system, or for a specified namespace or entity in the given namespace, or enable statistics tracking for the complete namespace. For more information, see Collecting Statistical Information for vVols.
• NVIDIA Ampere architecture support: vSphere 7.0 Update 2 adds support for the NVIDIA Ampere architecture that enables you to perform high end AI/ML training, and ML inference workloads, by using the accelerated capacity of the A100 GPU. In addition, vSphere 7.0 Update 2 improves GPU sharing and utilization by supporting the Multi-Instance GPU (MIG) technology. With vSphere 7.0 Update 2, you also see enhanced performance of device-to-device communication, building on the existing NVIDIA GPUDirect functionality, by enabling Address Translation Services (ATS) and Access Control Services (ACS) at the PCIe bus layer in the ESXi kernel.  Read more here…

• Support for Mellanox ConnectX-6 200G NICs: ESXi 7.0 Update 2 supports Mellanox Technologies MT28908 Family (ConnectX-6) and Mellanox Technologies MT2892 Family (ConnectX-6 Dx) 200G NICs.
• Performance improvements for AMD Zen CPUs: With ESXi 7.0 Update 2, out-of-the-box optimizations can increase AMD Zen CPU performance by up to 30% in various benchmarks. The updated ESXi scheduler takes full advantage of the AMD NUMA architecture to make the most appropriate placement decisions for virtual machines and containers. AMD Zen CPU optimizations allow a higher number of VMs or container deployments with better performance.
• Reduced compute and I/O latency, and jitter for latency sensitive workloads: Latency sensitive workloads, such as in financial and telecom applications, can see significant performance benefit from I/O latency and jitter optimizations in ESXi 7.0 Update 2. The optimizations reduce interference and jitter sources to provide a consistent runtime environment. With ESXi 7.0 Update 2, you can also see higher speed in interrupt delivery for passthrough devices.
• 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.
• vSphere Lifecycle Manager fast upgrades: Starting with vSphere 7.0 Update 2, you can significantly reduce upgrade time and system downtime, and minimize system boot time, by suspending virtual machines to memory and using the Quick Boot functionality. You can configure vSphere Lifecycle Manager to suspend virtual machines to memory instead of migrating them, powering them off, or suspending them to disk when you update an ESXi host. For more information, see Configuring vSphere Lifecycle Manager for Fast Upgrades.
• Encrypted Fault Tolerance log traffic: Starting with vSphere 7.0 Update 2, you can encrypt Fault Tolerance log traffic to get enhanced security. vSphere Fault Tolerance performs frequent checks between the primary and secondary VMs to enable quick resumption from the last successful checkpoint. The checkpoint contains the VM state that has been modified since the previous checkpoint. Encrypting the log traffic prevents malicious access or network attacks.

• In the Lifecycle Manager plug-in of the vSphere Client, the release date for the ESXi 7.0.2 base image, profiles, and components is 2021-02-17. This is expected. To ensure you can use correct filters by release date, only the release date of the rollup bulletin is 2021-03-09.
• Starting with vSphere 7.0, VMware uses components for packaging VIBs along with bulletins. The ESXi and esx-update bulletins are dependent on each other. Always include both in a single ESXi host patch baseline or include the rollup bulletin in the baseline to avoid failure during host patching.
• When patching ESXi hosts by using VMware Update Manager from a version prior to ESXi 7.0 Update 2, it is strongly recommended to use the rollup bulletin in the patch baseline. If you cannot use the rollup bulletin, be sure to include all of the following packages in the patching baseline. If the following packages are not included in the baseline, the update operation fails:
  • VMware-vmkusb_0.1-1vmw.701.0.0.16850804 or higher
  • VMware-vmkata_0.1-1vmw.701.0.0.16850804 or higher
  • VMware-vmkfcoe_1.0.0.2-1vmw.701.0.0.16850804 or higher
  • VMware-NVMeoF-RDMA_1.0.1.2-1vmw.701.0.0.16850804 or higher

Product Support Notices

• 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.
• Standard formats of log files and syslog transmissions: In a future major ESXi release, VMware plans to standardize the formats of all ESXi log files and syslog transmissions. This standardization affects the metadata associated with each log file line or syslog transmission. For example, the time stamp, programmatic source identifier, message severity, and operation identifier data. For more information, visit https://core.vmware.com/esxi-log-message-formats. 

• Upgrade paths possible from ESXi 6.5 U2+

Impact on ESXi upgrade due to expired ESXi VIB Certificate (76555)

Refer to the Interoperability Matrix for more product support notices.

vSphere Storage  |  vSphere Security  |  vSphere Resource Management  |  vSphere Availability  |  Monitoring & Performance

vSphere Single Host Management – VMware Host Client

Introducing the vSphere Native Key Provider

ESXi Log Message Formats

Introduction to vSphere Native Key Provider video (9 min video)

Explore the new security features of vSphere, including the Trusted Platform Module (TPM) 2.0 for ESXi, the Virtual TPM 2.0 for virtual machines (VM), and support for Microsoft Virtualization Based Security (VBS)

HOL-2111-05-SDC – VMware vSphere Automation and Development – API and SDK

The vSphere Automation API and SDK are developer-friendly and have simplified interfaces.

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