WilliamLam.com

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 Hybrid Cloud Extension (HCX) APIs

by // Leave a Comment

VMware Hybrid Cloud Extension (HCX) is the de facto VMware solution when it comes to Enterprise scale workload migration whether that is from onPrem to onPrem or from onPrem to Cloud, including our VMware Cloud on AWS (VMC) offering. In fact, one of the most popular use cases for HCX right now is datacenter evacuation/consolidation and customers are migrating their workloads to VMC because they want to get out of the business of running datacenters and get back to running their core business. This is especially attractive for customers wanting to expand to new markets without requiring the need of new datacenters. This makes a ton of sense, especially when you go beyond the initial CapEx, its the on-going OpEx costs that folks may not always be thinking about immediately and being able to easily scale up or down is not always possible for most onPrem environments.

HCX already provides a rich UI interface within the vSphere Client for scheduling migrations including the new Cloud Motion with vSphere Replication feature which was announced at VMworld US 2018.


However, it should come as no surprise that our customers are also interested in Automation, especially as it can help expedite migrations and remove potential user error, especially around mapping the destination networks which can be quite daunting for a large number of migrations. The good news is that HCX provides a Restful API that allows customers to automate all aspects of HCX including the HCX VAMI UI for initial configuration as well as consuming the HCX services which are exposed in the vSphere UI.

[Read more...]

How to unregister Hybrid Cloud Extension (HCX) from your onPrem vCenter Server?

by // 1 Comment

I recently had to redeploy my Hybrid Cloud Extension (HCX) setup on my onPrem vCenter Server as a newer version had been released since the last time I had looked at this which was some time last year. I had already deleted my HCX Manager and cleaned up the other HCX VMs but one thing that is not handled for you currently are the extension plugins that HCX uses to register with vCenter Server, which is no different than any other solution that integrates with vCenter Server.

Today, the only easy way to unregister an extension is to use the vSphere MOB, which I have blogged about in the past here. As you can see from the screenshot below, HCX has a number of plugins and because this is done by hand, its entirely possible that you may accidentally unregister the wrong extension which could severely impact your vCenter Server.


To help reduce that risk, an alternative and recommended method is to simply use the vSphere API (which is exactly what the vSphere MOB is talking to) and specifying the specific extensions to unregister. Below is a quick PowerCLI snippet which talks to the vSphere API and unregisters the 8 extensions related to HCX. After this, if you are still logged into the vSphere Client, you simply need to logout and log back in for the UI components to go away. If you are still seeing the UI plugins, you may need to restart the vSphere Client service.

$extensionManager = Get-View $global:DefaultVIServer.ExtensionData.Content.ExtensionManager

$hcxExtensions = @(
"com.vmware.hybridity"
"com.vmware.hybridity.dr"
"com.vmware.hybridity.hcsp-dashboard"
"com.vmware.hybridity.publisher"
"com.vmware.hybridity.troubleshooting"
"com.vmware.hybridity.hybrid-interconnect-ui"
"com.vmware.hybridity.auditlog-ui"
"com.vmware.vca.marketing.ngc.ui"
"com.vmware.hybridity.mobility-app"
"com.vmware.hcsp.alarm"
)

foreach ($hcxExtension in $hcxExtensions) {
    $extensionManager.UnregisterExtension($hcxExtension)
}

Once the HCX extensions have been removed, you can now download the new HCX Manager appliance from the VMC portal and redeploy.

If you are still seeing the HCX Plugin in the vSphere UI after unregistering the extension, I have found that you also needed to clear the H5 Plugins on the vCenter Server itself. Here is what I needed to do to fully clean it up. Login to the VCSA and then run the following commands:

cd /etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/
rm -rf com.vmware.hybridity*
rm com.vmware.vca.marketing.*
cd /usr/lib/vmware-vsphere-ui/server/pickup/
rm -rf com.vmware.hybridity*
rm com.vmware.vca.marketing.*