WilliamLam.com

NSX-T Policy PowerShell Community Module for VMC

by // 12 Comments

Earlier this week I had published an article on how to get started with the new NSX-T Policy API in VMware Cloud on AWS (VMC), if you have not read through that guide yet, I recommend you take a look at that first as this covers the prerequisites which will be required. As mentioned in that article, I planned to add a few more NSX-T Policy API examples and now the community NSX-T Policy PowerShell includes 37 additional functions which you can see the complete list below:

  • Connect-NSXTProxy
  • Get-NSXTFirewall
  • Get-NSXTGroup
  • Get-NSXTSegment
  • Get-NSXTService
  • New-NSXTFirewall
  • New-NSXTGroup
  • New-NSXTSegment
  • New-NSXTServiceDefinition (renamed as of 07/01/2019)
  • Remove-NSXTFirewall
  • Remove-NSXTGroup
  • Remove-NSXTSegment
  • Get-NSXTDistFirewallSection (as of 01/02/2019)
  • Get-NSXTDistFirewall (as of 01/02/2019)
  • New-NSXTDistFirewall (as of 01/03/2019)
  • Remove-NSXTDistFirewall (as of 01/03/2019)
  • Get-NSXTOverviewInfo (as of 02/02/2019)
  • Get-NSXTInfraScope (as of 03/14/2019)
  • Get-NSXTInfraGroup (as of 03/14/2019)
  • New-NSXTDistFirewallSection (as of 04/19/2019)
  • Remove-NSXTService (as of 04/19/2019)
  • Get-NSXTPolicyBasedVPN (as of 05/09/2019)
  • New-NSXTPolicyBasedVPN (as of 05/09/2019)
  • Remove-NSXTPolicyBasedVPN (as of 05/09/2019)
  • Get-NSXTDNS (as of 06/08/2019)
  • Set-NSXTDNS (as of 06/08/2019)
  • Get-NSXTPublicIP (as of 07/01/2019)
  • New-NSXTPublicIP (as of 07/01/2019)
  • Remove-NSXTPublicIP (as of 07/01/2019)
  • Get-NSXTNatRule (as of 07/01/2019)
  • New-NSXTNatRule (as of 07/01/2019)
  • Remove-NSXTNatRule (as of 07/01/2019)
  • Set-NSXTSegment (as of 03/05/2020)
  • Get-NSXTT0Stats (as of 07/16/2020)
  • Get-NSXTLinkedVpc (as of 08/01/2020)
  • Get-NSXTL2VPN (as of 08/01/2020)
  • Get-NSXTPortMirror (as of 08/01/2020)
  • Get-NSXTIPFIXCollector (as of 08/01/2020)
  • Get-NSXTDirectConnectVIF (as of 08/01/2020)
  • Get-NSXTVifPerHost (as of 08/01/2020)
  • Get-NSXTVM (as of 08/01/2020)
  • Get-NSXTSegmentPort (as of 08/01/2020)
  • Get-NSXTGroupMember (as of 08/01/2020)

After importing the module, to see the list of all functions, you can run the following command:

Get-Command -Module VMware.VMC.NSXT


[Read more...]

vMotion across different VDS version between onPrem and VMC

by // 21 Comments

For those of you who have attempted a vMotion (whether that is within a vCenter Server or between different vCenter Servers (including across SSO Domains), if the VM is running on a Distributed Virtual Switch (VDS) and the version of the VDS is not the same between the source and destination (VDS 6.5 to VDS 6.7), the operation will fail with the following error message (UI and API):

Currently connected network interface 'Network adapter 1' cannot use network 'DVPG-VM-Network (VDS-67)', because the destination distributed switch has a different version or vendor than the source distributed switch.


This behavior is no different on VMware Cloud on AWS (VMC) or at least, I thought it was, until I recently learned about a really neat feature that was introduced in the VMC 1.4p2 release, here is a snippet from the release notes:

Cross VDS version vMotion Compatibility
With this advanced configuration option enabled, bi-directional vMotion between on-premises and VMware Cloud on AWS can be achieved across different virtual distributed switch (VDS) versions (greater than or equal to version 6.0). This must be enabled on the on-premises vCenter.

It turns out there is actually a way to allow vMotions across different VDS versions, this is important for VMC because the software stack will always be using a newer version than what we ship to our onPrem customers. However, due to this limitation, we could not benefit from the latest VDS version but had to default it to VDS 6.0 to ensure that customers could migrate their workloads. The advanced setting mentioned in the release notes allows us to disable the strict compatibility check which is performed on the destination vCenter Server when a vMotion is initiated, this setting is now enabled by default on the VMC vCenter Server which is why you can perform migration across different VDS without having to do anything special on your onPrem vCenter Server.

UPDATE (11/07/21) - Thanks to Robert Cranedonk, it looks like you can now also vMotion across different NSX-T Logical Switches by adding vCenter advanced setting called  config.vpxd.network.allowVmotionBetweenLogicalSwitches and set the value to true.

UPDATE (01/02/21) - If you are running vSphere 7.x, an additional advanced setting must be configured called config.vmprov.enableHybridMode and set the value to true. For more details, you can refer to this VMware KB 79446. Thanks to reader Marc Alumbaugh for sharing this finding!

UPDATE (10/16/18) - With the release of vSphere 6.7 Update 1, customers can now also vMotion VMs from on-prem running on a VDS to VMC with NSX-T N-VDS.

[Read more...]

Getting started with the new NSX-T Policy API in VMC

by // 26 Comments

Today, when you deploy a new SDDC on VMware Cloud on AWS (VMC), NSX-T is now the default networking stack and NSX-V is no longer used for net new deployments. In fact, we are about to start migrating existing VMC customers who have an NSX-V SDDC and converting them to an NSX-T SDDC. Humair Ahmed who works over in our Networking & Security Business Unit has an excellent blog post here that goes into more details on what NSX-T brings to VMC.


Upon first glance, you might think that this is the exact same version of NSX-T that we have been shipping to our on-premises customers but in fact, it is actually a brand new and improved version. Similar to vSphere (vCenter and ESXi) and VSAN, VMC is always running a newer version of our software than our on-prem customers. One immediate difference that you should be aware of when using NSX-T in VMC is that the current NSX-T API is not available and instead a new NSX-T Policy API has been introduced to help simplify the consumption of NSX-T. All functionality in the current on-prem NSX-T API can be consumed using the new Policy API.

At VMworld, I spoke to a number of current and upcoming customers with NSX-T based SDDCs and they were really interested in using the new NSX-T Policy API and as the title of this blog post suggests, this will be a quick primer on how to do that. Before we get started, confirm that you have an NSX-T based SDDC deployed. If you are not sure, there are a few ways to determine this using either the VMC Console UI or API, instructions can be found here and here.

[Read more...]