WilliamLam.com

PowerCLI remediation script for running NSX Edge on AMD Ryzen for VCF 9.0

by // 1 Comment

If you are planning to deploy VMware Cloud Foundation (VCF) 9.0 on an AMD Ryzen processor (consumer CPU), make sure you are aware of the required workaround to get the NSX Edge node to function properly, which I had shared the solution back in 2020.

Fortunately or unfortunately, the workaround is still applicable with VCF 9.0 due to lack of support for Data Plane Development Kit (DPDK) with Ryzen processors. One of the challenges you could face depending on where you deploy the NSX Edge, since there is a new workflow that is built right into vCenter Server 9.0 and SSH is not enabled by default, which means you would need to go to VM Console of the NSX Edge VM to apply the workaround.


To make this even less fun, during this time the NSX Edge is going through its initialization process and because it fails to detect DPDK support, the required NSX services can not start and keeps re-trying which is not a bad thing. The reason the looping is a problem is because the workaround requires editing a configuration file and depending on how fast you can type, the initialization process will restart and cause your session to end and you now need to log back in, thus causing a less than ideal experience.

As you can probably guess, I got hit by this re-initialization loop and I just got tired of trying to be faster than the computer ?

[Read more...]

Quick Tip - Retrieving NSX segment information from vCenter Server

by // Leave a Comment

Since vSphere 7.0, it has been much simpler to correlate between an NSX network segment defined in NSX Manager and its representation as a vSphere Distributed Virtual Portgroup (DVG) in vCenter Server as demonstrated in screenshot below using the vSphere UI.


With the additional NSX information such as NSX Transport Zone ID, Transport Zone ID Name, Logical Switch ID, Segment Name and VNI (Virtual Network Identifier), users can streamline debugging and troubleshooting issues with their network team by quickly providing this relevant information.

I recently had a user ask about retrieving the VNI information for a given NSX segment in vCenter Server using PowerCLI, so here is a quick snippet including other NSX information for those interested.

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