Support of 3rd party vSwitches removed

VMware has announced the discontinuation of the 3rd party vSwitch program in vSphere 6.5 u1, most notably the Nexus 1000v,

When I say they’re discontinuing the program, I mean they’re actually removing the APIs 3rd party switches interact with! [ref 1]

Customers who remain on 5.5 or 6.0 and stick with the 1k will still be entitled to support.

Full disclosure, I’m an ex VCE (Now Dell EMC CPSD) employee. I was an Escalation Engineer responsible for Vblock support, Vblocks come pre-packaged with the Nexus 1000v. You’d think that level of exposure would lead me down a path of whimsical nostalgia… “It had its place” or “it’ll be missed” maybe phrases you’d expect an advocate of the Vblock to spout against the back drop of such news, however…  I’m ecstatic

My feelings about the 1K are best summed up by Moff from human traffic and his hatred for Peter Andre…

The vDS is more than adequate to fit the use cases that previously could only be meet by the 1K. As we move further into the world of converged infrastructure and software defined the 1K represents a time where infrastructure teams had stricter silos, where network engineers wanted more control over the virtual network.

Not to mention the hundreds of hours of downtime caused by server engineers trying to find their way around a nexus switch for the first time. (if you ever missed the word “add” when adding VLANs to the Uplink Port Profiles you’ll understand my pain)

VMware have a 1000v to vDS automated migration tool available on their download site, however the documentation shows a support matrix that’s a bit thin on the ground when it comes to supported 1K versions [ref 2]

At time of writing, it lists only 2 supported 1k Versions which I assume translate as follows.

2.2.3 = SV2(2.3)

3.1.3 = SV3(1.3)

Table 1‑1 Support Matrix

ESXi Version Nexus 1000v Version
5.5 2.2.3
3.1.3
5.1 2.2.3
1.5.2b

If the above rings true, from a Vblock perspective only RCMs 5.0.5 > 5.0.8 are officially in scope/tested for this tool, although I’m sure the good people at CPSD have a plan\announcement pending for this relating to their own tool/guide/professional service to move away from the 1K.

Of course, it’s worth reiterating that this only becomes relevant if you intend to move to vSphere 6.5, an RCM based on 6.5 isn’t even GA yet…

Those that will stay on RCM 5.0.* or RCM 6.0 .* until tech refresh can sit back and relax knowing they can still get support.

The download also contains a manual guide to migrating away; the process is straight forward but could be lengthy if you have a large number of port-profiles to migrate to port groups.

For Vblock or for those using the 1k in a UCS environment, if you go down the manual migration route keep in mind what load balancing algorithm you can select. UCS only supports route based on virtual port ID or route based on source MAC hash.

Route based on IP Hash and route base on physical NIC Load are not supported in UCS [ref 3]

[ref1]

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2149722

[ref2]

https://my.vmware.com/web/vmware/details?downloadGroup=MIGRATION-TOOL&productId=614

[ref3]

http://www.cisco.com/c/en/us/support/docs/servers-unified-computing/ucs-b-series-blade-servers/200519-UCS-B-series-Teaming-Bonding-Options-wi.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s