Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
This article provides information on the planned transition from N-VDS (NSX Virtual Distributed Switch) to Virtual Distributed Switch (VDS) in the VMware Cloud on AWS (VMConAWS) and VMware Cloud on Dell EMC solutions. It also provides VMConAWS specific API changes to enable customers and partners who are using them will be able to make the transition to the VDS API calls. Customer SDDCs being upgraded to 1.16 from previous releases will need to work with the support team to schedule a maintenance operation. It is recommended that this second maintenance operation should be scheduled one week or more after the initial upgrade to 1.16. During this operation the SDDC will be migrated from N-VDS to VDS. It is recommended that during this maintenance operation that no networking changes are made to facilitate a smooth migration. Hosts will be placed in maintenance mode and guests moved from N-VDS to VDS using vMotion to minimize workload disruption. Estimated time to complete the migration will be provided by the support team as it will vary depending on the number of networks and hosts in the SDDC. The VDS maintenance is similar to SDDC maintenance Phase 2 with maintenance mode methodology.Note: This second maintenance operation must be completed before the SDDC can be upgraded to 1.18.
For background on the history of N-VDS detailed API and UI changes for on-premises NSX-T as well as a detailed explanation of opaque networks compared to Distributed Virtual Port Groups (DVPGs), refer to this KB 79872.VMware Cloud on AWS (VMConAWS) and VMware Cloud on Dell EMC are managed services and many of the configuration options that are specific to on-premises NSX-T deployments are not available to VMConAWS and VMC on Dell EMC customers as VMware manages those configurations. The simplicity and ease of use of VMConAWS and VMC on Dell EMC reduces the need for customers to work with some of the lower level configuration.However, there are a few changes that will be present for customers to manage and therefore, be aware of and plan for. These are enumerated below.There are some changes you need to be aware of: Existing opaque network will be replaced by NSX DVPG after upgrading.The backing of VM VNIC will be changed from "OpaqueNetworkBackingInfo" to "DistributedVirtualPortBackingInfo" if it connected to an opaque network before upgrading.The config of vmk nic will be changed from "opaqueNetworkspecify" to "distributedVirtualPort". Object/APIPropertyNewly AddedvSphere DVPGNSX DVPGDistributedVirtualPortgroupConfigInfo.transportZoneUuidYesUnset ConfigInfo.transportZoneNameYesUnset ConfigInfo.logicalSwitchUuidYesUnset ConfigInfo.segmentIdYesUnset Connect VM VNIC to target network Use vim.vm.device.VirtualEthernetCard.DistributedVirtualPortBackingInfo to specify the target network. User needs to provide switchUuid and portgroupKey.(1) Use vim.vm.device.VirtualEthernetCard.DistributedVirtualPortBackingInfo to specify the target network. User needs to provide switchUuid and portgroupKey(Same as normal DVPG). OR (2) Use vim.vm.device.VirtualEthernetCard.OpaqueNetworkBackingInfo User needs to provide opaqueNetworkId and opaqueNetworkType(Same as Opaque Network). Read VM VNIC backing API returns vim.vm.device.VirtualEthernetCard.DistributedVirtualPortBackingInfoAPI returns vim.vm.device.VirtualEthernetCard.DistributedVirtualPortBackingInfo(same as normal DVPG), DistributedVirtualPortBackingInfo/OpaqueNetworkBackingInfo to connect the VM VNIC to the network.Read vmk backing API returns vim.host.VirtualNic.Specification.distributedVirtualPortAPI returns vim.host.VirtualNic.Specification.distributedVirtualPort(Same as normal DVPG), distributedVirtualPort/opaqueNetworkspecify to connect the vmk nic to the network. Additionally, the vCenter User Interface network objects will change as depicted below. Figure 1 – Opaque Network in VMConAWS and VMC on Dell EMC Figure 2 – Distributed Port Group in VMConAWS and VMC on Dell EMC 2nd and 3rd Party Products and Applications with VDS SupportThe table below reflects the minimum version of 2nd and 3rd party products and applications with VDS support. 2nd Party Product NameSupported VersionAnsibleNSX-T 3.0.0AVI Load BalancerAVI 20.1.1BOSH CPI54.1.0Datrium7.21.4.0Horizon 7/87.13 or 8.1HCXHCX 4.2.4PowerCLIPowerCLI 12.0Terraform NSX-T ProviderNSX-T Provider 3.0VMware Cloud Director (vCD)10.1.1VMware Cloud Foundation (VCF)VCF J1VMware Pivotal Container Service (PKS)PKS 1.8VMware Site Recovery Manager (SRM)8.3.1VMware Tanzu Application Service (TAS)TAS 2.9.2VMware Tanzu Kubernetes Grid (TKG)N/AvRealize Automation (vRA) Greenfield8.1vRealize Automation (vRA) Brownfield8.5vRealize Network Insight (vRNI)vRNI 5.2vRealize Operations (vROPS)vROPS 8.2VxRailVxRail 7.0.0 3rd Party Product NameSupported VersionClumioSaaSCohesitySaaSCommvault11.19DruvaSaaSEmbotics vCommanderContact your vendorEMC AvamarContact your vendorEMC NetworkerContact your vendorEMC PowerProtectContact your vendorEMC Unity VSAContact your vendorIBM Spectrum Protect8.1.12IBM Spectrum Protect Plus10.1.8Primary IOContact your vendorRubrik5.3Terraform vSphere ProvidervSphere Provider 1.17.1Veeam11.0Veritas BackupExec21.2VMware Safekeeping (open source)Source code updated Summary The VMware Cloud on AWS and VMware Cloud on Dell EMC services will be migrating from N-VDS to VDS by the VMConAWS and VMware Cloud on Dell EMC releases in Q1 Calendar Year 2022. This migration is expected to be transparent to the vast majority of customers with only the few API and UI changes mentioned above being customer facing.