WilliamLam.com

Search Results for: vmc

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...]

Using VMC API to answer commonly asked questions about your SDDC

by // Leave a Comment

In the past month or so since joining the VMware Cloud on AWS (VMC) team, I have seen a number of inquiries from our Customer Success team, partners and customers on how to retrieve certain pieces information about their deployed SDDC, usually for information or integration purposes. Some of these questions can simply be answered by using the VMC Console UI, however there are others that is only available when using the VMC API, which provides a ton more data than what the UI could ever display. In any case, I figure it would be useful to share some of this information, especially as it pertains to the VMC API.

Below are just some of the frequently asked questions that I have seen and they can all be answered simply performing a GET /api/orgs/<orgId>/sddcs/<sddcId> on your specific SDDC via VMC API. In addition, I have also create two sample scripts which exercises these VMC APIs, one using the native VMC REST API and another with PowerCLI using the VMC cmdlet, which you can find more details below.

1) What version is my SDDC running?

This can be found in the VMC Console UI under the "Support" tab for a given SDDC.


You can also find this information using the VMC API by referring to the resource_config.sddc_manifest.vmc_version property.

2) When was my SDDC created?

This can be found in the VMC Console UI under the "Support" tab for a given SDDC.


You can also find this information using the VMC API by referring to the created property.

3) How long do I have until my 1-Node SDDC expires?

This can be found in the VMC Console UI under the SDDC card summary view or detailed view.


You can also find this information using the VMC API by referring to the expiration_date property. This property will be null if your SDDC is NOT a 1-Node, which is the only configuration which has an expiration.

[Read more...]