The new release of the VMware Cloud Foundation 9.0 platform, which includes the server and storage virtualization components, VMware vSphere 9.0, and the network virtualization component, VMware NSX 9, not only brings many improvements but also removes a number of outdated technologies and features. Many capabilities present in earlier releases of ESX (formerly ESXi), vCenter, and NSX have been declared deprecated or completely removed in VCF 9. This has been done to simplify the architecture, improve security, and transition to new approaches in private and public cloud architecture.
Below, we take a detailed look at which features are no longer available in vSphere 9 (in the ESX and vCenter components) and NSX 9, and what alternatives or migration recommendations exist for administrators and architects.
Why Is It Important to Know about Removed Features?
New releases are often accompanied by notices of deprecation and end of support for legacy capabilities. Ignoring these changes can lead to problems during upgrades and operations. Therefore, before moving to VCF 9, you should analyze whether you are using any of the functions listed below and plan in advance to abandon them or migrate to new tools.
VMware vSphere 9: Removed and Deprecated Features in ESX and vCenter
In VMware vSphere 9.0 (ESX 9.0 hypervisor and vCenter 9.0 management server), support for several legacy administration tools has been discontinued, and new approaches have been introduced.
Below is a list of the main features that are deprecated (scheduled for removal in future versions) or already removed in version 9, as well as recommendations for moving to modern alternatives:
- vSphere Auto Deploy (deprecated) – automated ESX host deployment over the network using PXE boot has been deprecated. In ESX 9.0, Auto Deploy (together with Host Profiles) will be removed in one of the subsequent 9.x releases.
Recommendation: if you have been using Auto Deploy for diskless host deployment, begin planning to install ESX on local disks or use scripts to automate the installation process. Going forward, host configuration management should be performed using vLCM images and vSphere Configuration Profiles instead of network boot. - vSphere Host Profiles (deprecated) – the Host Profiles feature, which enabled consistent configuration across multiple ESX hosts, will be replaced by the new Configuration Profiles functionality. Starting with vCenter 9.0, Host Profiles have been deprecated and will be fully removed in future releases.
Recommendation: replace Host Profiles with vSphere Configuration Profiles, which allow configuration management at the cluster level. This new approach is integrated with vSphere Lifecycle Manager (vLCM) and provides more reliable and simplified configuration management. - vSphere ESX Image Builder (deprecated) – the ESX Image Builder tool, used for creating custom ESX images (adding drivers and VIB packages), is no longer being developed. Its functionality is now incorporated into vSphere Lifecycle Manager. In vSphere 9, you can create an ESX image library directly in vCenter and build desired images from components (drivers, vendor add-ons, etc.) within vCenter.
Recommendation: use vLCM Desired State Images and the new ESX Image Library in vCenter 9 to create ESX images and manage cluster images consistently, eliminating the need to manually build ISO files. - vSphere Virtual Volumes (vVols, deprecated) – the vVols storage technology did not gain wide adoption and has been deprecated as of VCF 9.0 / vSphere 9.0. Support for vVols will be limited to critical fixes in vSphere 8.x (VCF 5.x) until the end of support. In VCF/VVF 9.1, vVols functionality is planned to be completely removed.
Recommendation: if your infrastructure uses vVol-based storage, plan to migrate VMs to alternative storage. Preferably use VMFS or vSAN, or check with your storage vendor about vVol support in VCF 9.0 (limited support may be available on a case-by-case basis, subject to agreement with Broadcom). Long term, VMware’s strategy is clearly shifting towards vSAN and NVMe, so vVol usage should be minimized. - vCenter Enhanced Linked Mode (deprecated) – Enhanced Linked Mode (ELM), which allowed multiple vCenter Servers to be joined in a single SSO domain with a shared console, is no longer used in VCF 9. In vCenter 9.0, ELM is deprecated and will be removed in future releases. Although ELM support remains in version 9 for upgrading existing environments, VCF 9 adopts a different approach: unified multi-vCenter management is now handled via VCF Operations instead of ELM.
Recommendation: when planning VCF 9 deployments, do not set up new linked vCenter groups. After upgrading to version 9, consider converting existing vCenters from ELM to standalone mode with grouping via VCF Operations, which provides centralized management without traditional ELM. Functions previously offered by ELM (unified SSO, shared roles, tag synchronization, single API endpoint, etc.) are now provided by VCF Operations and related services. - vSphere Clustering Service (vCLS, deprecated) – the built-in clustering service, which, since vSphere 7 U1, deployed small service VMs (vCLS VMs) to support DRS and HA, is no longer needed in vSphere 9. In vCenter 9.0, vCLS is deprecated and will be removed in future versions. vSphere 9 clusters can operate without these service VMs: after the upgrade, it will be possible to enable Retreat Mode and disable the deployment of vCLS agents without any impact on DRS/HA functionality.
Recommendation: disable vCLS in vSphere 9 clusters (by enabling Retreat Mode in the cluster settings) – vCLS deactivation has no effect on DRS and HA operation. ESX 9 includes a distributed embedded key-value store directly on the hosts, enabling the cluster to maintain and restore its configuration without external service VMs. This simplifies the environment (no more “extra” service VMs) and eliminates related overhead. - ESX Host Cache (deprecated) – in ESX 9.0, the use of host-level SSD cache as a write-back cache for virtual machine swap files has been declared deprecated and will be removed in a future release. As an alternative, VMware recommends using the Memory Tiering mechanism based on NVMe. NVMe-based Memory Tiering allows you to increase the amount of available RAM on a host and intelligently distribute a VM’s memory between high-speed DRAM and the host’s NVMe device.
Recommendation: use Advanced Memory Tiering features with NVMe devices as a secondary memory tier. This approach can expand the available memory up to four times while utilizing existing server slots for cost-effective hardware. - Intel Optane Persistent Memory (removed) – ESX 9.0 has ended support for Intel Optane Persistent Memory (PMEM) technology. For alternative solutions, consult your OEM server hardware provider.
Recommendation: as an alternative, you can use the Memory Tiering functionality officially introduced in ESX 9.0. This technology enables you to add local NVMe devices to an ESX host as an additional memory tier. For more details, see VMware KB article 326910. - Storage I/O Control (SIOC) and Storage DRS Load Balancer (removed) – in vCenter 9.0, VMware has discontinued:
- The Storage DRS (SDRS) I/O Load Balancer
- SDRS I/O Reservations-Based Load Balancer
- vSphere Storage I/O Control Components
These functions are still supported in current 8.x and 7.x releases. The removal affects both I/O latency-based and I/O reservations-based load balancing between datastores in a Storage DRS cluster. Support has also ended for enabling Storage I/O Control (SIOC) on individual datastores and configuring I/O Reservations and Shares via SPBM Storage Policy. However, initial placement of VMs using Storage DRS, as well as space-based load balancing and SPBM policy-based limits, remain operational in vCenter 9.0.
Recommendation: switch to using space-based load balancing and SPBM policies. Replace I/O Reservations and Shares settings with alternative performance control mechanisms provided by your storage system (for example, built-in QoS features). After migration, monitor performance closely to address potential issues promptly.
- vSphere Lifecycle Manager Baselines (removed) – in vSphere 9, the classic patch management mode using baselines is no longer supported. Starting with vCenter 9.0, VUM/vLCM Baselines have been fully removed – all clusters and hosts must now use the image-based lifecycle workflow. When upgrading from vSphere 8, any clusters still using baselines must be migrated to image-based management before upgrading to ESX 9.
Recommendation: migrate from legacy baselines to vLCM images – desired cluster images. vSphere 9 allows you to apply a single image to multiple clusters or hosts, manage compliance and updates at a global level, simplify administration, and eliminate the need for manually creating and applying numerous baseline profiles. - Integrated Windows Authentication (IWA, removed) – in vCenter 9.0, support for Integrated Windows Authentication – direct vCenter joining to an Active Directory domain – has been removed. Instead of IWA, use LDAP(S) or federation mechanisms. VMware officially states that IWA is no longer supported in vCenter 9.0; to maintain secure access, administrators must migrate accounts to Active Directory over LDAPS or configure federation (for example, via ADFS) with multi-factor authentication.
Recommendation: before upgrading vCenter, disable IWA and migrate AD integration to LDAP(S), or set up VMware Identity Federation with MFA (available since vSphere 7). This will preserve secure vCenter AD domain integration after upgrading to version 9. - Interface localizations (reduced) – in vSphere 9, the number of supported web interface languages has been reduced. While earlier versions of vCenter supported many language packs, version 9 includes only English (US) plus three locales: Japanese, Spanish, and French. All other languages are no longer available.
Recommendation: administrators using the vSphere Client interface in other languages should prepare to work in English or one of the remaining three locales. Training materials and documentation should be aligned to the English interface to avoid misunderstandings.
General Migration Advice for vSphere: before upgrading, inventory your infrastructure for use of the functions listed above. Upgrading to vSphere 9 is a good opportunity to adopt modern approaches:
- Replace Host Profiles with Configuration Profiles;
- Switch from VUM baselines to image-based lifecycle management;
- Move away from ELM (Enhanced Linked Mode) in favor of newer management tools.
By doing so, your upgrade process will be smoother, and your platform will align with VMware’s current best practices.
The above list includes only the most important VMware vSphere 9 features that have been deprecated or removed. For the full set of changes, refer to the official Broadcom article.
VMware NSX 9: Deprecated and Unsupported Features
VMware NSX 9.0 (formerly known as NSX-T) – the network virtualization component within VCF 9 – has also undergone significant changes. The new version of NSX is focused on unified operation with VMware Cloud Foundation and drops a number of older capabilities, especially those related to multi-platform flexibility.
Below are the key technologies no longer supported in NSX 9, along with guidance on how to adapt:
- Physical Server Connectivity via NSX Agent (removed) – in NSX 9.0, it is no longer possible to deploy the NSX bare-metal agent on physical servers to integrate them directly into an NSX overlay network. Previously, such agents allowed physical nodes to participate in NSX logical segments (overlay networks). Starting with version 9, overlay connectivity for physical servers is no longer supported – Distributed Firewall (DFW) for physical servers remains available, but L2 overlay connectivity has been removed.
Recommendation: to connect physical workloads to NSX virtual networks, use L2 bridging on an NSX Edge node. VMware explicitly recommends using NSX Edge bridging for new physical server connections to provide L2 connectivity with the overlay, instead of installing agents directly on the servers. In practice, this means physical servers should be connected to a VLAN, which is then bridged into an NSX logical segment via an Edge Node. This allows integration of physical infrastructure with virtual networks without installing NSX components on the servers. If you previously implemented bare-metal transport nodes in NSX-T 3.x, you will need to redesign them to use Edge bridging before upgrading to NSX 9.
Note: the Distributed TGW bridge introduced in VCF 9 can also provide direct VM connectivity to the ToR (Top-of-Rack) switch without an Edge node, which is relevant for advanced use cases. However, the default approach remains the Edge L2 bridge. - N-VDS Virtual Switch on ESX (removed) – historically, NSX-T used its own virtual switch (N-VDS) for ESXi and KVM hosts. In NSX 9, this technology is no longer used for ESX hosts – support for N-VDS on ESX was removed starting with NSX 4.0.0.1 (the version included in VCF 9). Now, NSX integrates only with the native vSphere Distributed Switch (VDS) version 7.0 or later. This means that all ESX-based environments must use the converged VDS switch for NSX networking.
N-VDS remains only in certain scenarios: for Edge nodes, cloud agents, or bare-metal Linux deployments (where vSphere is not present) – but not for ESX hypervisors.
Recommendation: before upgrading to NSX 9, migrate all ESX transport nodes from N-VDS to VDS. VMware provides host switch migration tools (available since NSX 3.2) to assist in moving existing NSX-T 3.x host transport nodes to VDS. After migration, NSX 9 will have tighter integration with vCenter, and network management will be simplified, since NSX network policies are bound to the standard vSphere VDS.
Keep in mind that NSX 9 requires vCenter for network configuration – NSX no longer operates independently from vSphere – so plan your infrastructure accordingly. - Support for KVM Hypervisors and Third-Party OpenStack (removed) – NSX-T was originally positioned as a multi-hypervisor solution, supporting not only vSphere but also KVM (Linux) and integration with open-source OpenStack. With the release of NSX 4.0 (and NSX 9), this strategy has changed – NSX 9.0 no longer supports KVM hypervisors or third-party OpenStack distributions. Only VMware Integrated OpenStack (VIO) remains supported as an exception. In other words, NSX is now fully focused on the VMware ecosystem.
Recommendation: if you have NSX policies deployed on KVM hosts or use NSX-T with non-VMware OpenStack, migration to NSX 9 will not be possible without architectural changes. Your options are:- remain on older NSX-T 3.x versions for these workloads;
- replace network virtualization in those environments with an alternative solution.
In a VCF 9 deployment, this scenario is unlikely, since VCF assumes a vSphere-based stack. So, the main action item is to ensure all NSX workloads are migrated to vSphere, or to keep NSX-T 3.x isolated for specific use cases outside VCF. VMware will continue to evolve NSX as part of a unified platform, and multi-platform capabilities have been reduced in favor of optimization for vSphere.
- NSX for vSphere (NSX-V) 6.x – no longer used – it’s worth explicitly noting that the legacy NSX-V platform (NSX 6.x for vSphere) has been fully retired and is not included in VCF 9. VMware ended support for NSX-V in early 2022, and migration to NSX-T (now NSX 4.x) has been mandatory since then. In VMware Cloud Foundation version 4.x and higher, NSX-V is no longer available, so upgrading environments older than VCF 3 requires migrating network virtualization to NSX-T in advance.
Recommendation: if you are still using NSX-V in older network segments, you must deploy NSX 4.x (NSX-T) in parallel and migrate your network policies and services. This can be done using the Migration Coordinator utility if your version is supported. Only after transitioning to NSX-T, you will be able to upgrade to VCF 9. In the new architecture, all network functions are provided by NSX 9, and NSX-V is completely retired.
Summary up on NSX: VMware NSX 9 is focused on consolidating features for private cloud environments based on vSphere. Capabilities that fall outside this scope – such as multi-hypervisor support, physical server agents, and similar – have been removed in favor of simplification and performance improvements. Administrators should plan for these changes ahead of time: migrate networks to VDS, reconsider methods of connecting physical servers, and ensure that all workloads requiring NSX run in a supported configuration. This will make the transition to VCF 9 predictable, while the new environment will be more unified, secure, and efficient. By preparing to migrate from legacy technologies to modern equivalents, you can leverage the benefits of VMware Cloud Foundation 9.0 without prolonged downtime and with minimal risk to datacenter operations.
Final Notes
Most of the changes described above are officially documented in the Product Support Notes for VMware Cloud Foundation 9.0 for vSphere and NSX. Before upgrading, it is strongly recommended to thoroughly review the release notes and ensure that none of the deprecated features your infrastructure depends on will become a critical issue after the transition. By following VMware’s guidance on adopting the new toolset – such as vLCM, Configuration Profiles, Edge Bridge, and others – you can ensure your infrastructure remains fully supported and ready for future updates in the VMware Cloud Foundation ecosystem.
