VMware NSX based VCP-NV - Lets hits it !!

Hi,

Recently VMware has released the Certifications based on VMware Network Virtualization

1) VCP-NV

2) VCDX-NV

Now any one can download the Blueprint for VCP-NV from the site and it covers mainly the following topics.


Section 1 – Define VMware NSX Technology and Architecture

Objective 1.1 – Describe the Benefits of a VMware NSX Implementation
Objective 1.2 – Describe VMware NSX Architecture
Objective 1.3 – Differentiate VMware Network and Security Technologies
Objective 1.4 – Contrast Physical and Virtual Network Technologies
Objective 1.5 –Explain VMware NSX Integration with Third-Party Products and Services


Section 2 – Plan and Configure vSphere Networking

Objective 2.1 – Define Benefits of Running VMware NSX on Physical Network Fabrics
Objective 2.2 – Describe Physical Infrastructure Requirements for a VMware NSX Implementation


Section 3 – Configure and Manage vSphere Networking

Objective 3.1 – Configure and Manage vSphere Standard Switches (vSS)
Objective 3.2 – Configure and Manage vSphere Distributed Switches (vDS)
Objective 3.3 – Configure and Manage vSS and vDS Policies


Section 4 – Install and Upgrade VMware NSX

Objective 4.1 – Configure Environment for Network Virtualization
Objective 4.2 – Deploy VMware NSX Components
Objective 4.3 – Upgrade Existing vCNS/NSX Implementation
Objective 4.4 – Expand Transport Zone to Include New Cluster(s)


Section 5 – Configure VMware NSX Virtual Networks

Objective 5.1 – Create and Administer Logical Switches
Objective 5.2 – Configure VXLAN
Objective 5.3 – Configure and
Objective 5.4 – Configure and Manage Logical Routers Manage Layer 2 Bridging


Section 6 – Configure and Manage NSX Network Services

Objective 6.1 – Configure and Manage Logical Load Balancing
Objective 6.2 – Configure and Manage Logical Virtual Private Networks (VPN)
Objective 6.3 – Configure and Manage DHCP/DNS/NAT
Objective 6.4 – Configure and Manage Edge Services High Availability


Section 7 – Configure and Administer Network Security

Objective 7.1 – Configure and Administer Logical Firewall Services
Objective 7.2 – Configure Distributed Firewall Services
Objective 7.3 – Configure and Manage Service Composer


Section 8 – Perform Operations Tasks in a VMware NSX Environment

Objective 8.1 – Configure Roles, Permissions, and Scopes
Objective 8.2 – Describe NSX Automation
Objective 8.3 – Monitor a VMware NSX Implementation
Objective 8.4 – Perform Auditing and Compliance
Objective 8.5 – Administer Logging
Objective 8.6 – Backup and Recover Configurations


Section 9 – Troubleshoot a VMware Network Virtualization Implementation

Objective 9.1 – Identify Tools Available for Troubleshooting
Objective 9.2 – Troubleshoot Common NSX Installation/Configuration Issues
Objective 9.3 – Troubleshoot Common NSX Component Issues
Objective 9.4 – Troubleshoot Common Connectivity Issues
Objective 9.5 – Troubleshoot Common vSphere Networking Issues


For those who wants to know how the exam looks like than have a look at the practice exam released by VMware Education and also by @pmcsharry which you can find here.

I will try to cover each objective separately and if possible I can also present it on vBrownBag (if time and resource permits as don't have Lab for NSX) but till then lets just get started here with the study.

Mainly the documents referred for covering the objectives are all released by VMware and the information can be formed under the Whitepapers mentioned in the Blueprint.

I have updated my NSX Resource post today as well so take a look at it here to study more about NSX. All the documents/Whitepapers can be found here.

If you feel if I missed anything while covering the objectives then please leave a comment to get in touch with me an I can update the post at the earliest with your feedback.

Enjoy reading and wish you good luck towards your journey of VCDX-NV :-) !!

Share and care !!

Recovering vCenter Server after the major Outage

Hi,

I have discussed this issue so many time with my colleagues and friends who experienced the situation where the whole Datacenter had an Outage due to X reason and then depending on the products running in the environment, it is getting difficult to restore everything back to normal.

The products which can add complexity in the restoration process can be Nexus 1000v, SRM, VMware VDS. Now let me emphasize here that there is nothing wrong with these products but to recover vCenter Server which is a Critical/Key component in the whole infrastructure.

I am going to explain few scenarios on how to recover vCenter Server and get everything up and running which may take time from minutes to few hours and sometimes a day or two (depends on the size and inventory of  the Datacenter).

1) If running VMware VDS, Nexus 1000v VDS

First of all one needs to find out where the vCenter Server was running lastly.

Now lets assume you are running fewer number of ESXi hosts in the cluster/Datacenter (lets say 1-20) then if you have the location documented if the vCenter was tied up on certain hosts only using the DRS rules then you can connect directly (assuming network connection is working or else we need to get that working first) to that particular ESXi host (using putty or DCUI and later using vSphere client) and find out if the vCenter Virtual Machine is still registered on that host or not. (If running WebClient then I will be covering that in an upcoming blog post).

vmware-cmd -l

The above command will tell us which VMs are still registered on the host and you can power on the vCenter Server through command line or from vSphere Client. Once logged in you can open the console of the vCenter and login using the local administrator account. Now here there is another assumption going here that if the vCenter Database is residing on another VM or a physical machine than there should be network connectivity available between the DB machine and vCenter Server.

Now lets take a situation where the management Network of ESXi host is configured on VDS (VMware) then if needed you need to restore the Standard Switch on the ESXi host so that atleast you can connect to the Management interface. Then you can try accessing vCenter Server from the console right on the vCenter server VM using localhost option and you can see all the inventory within the VC virtual machine. Once you power on all the ESXi hosts you should be able to see all the VMs and other inventory items.

If the VMs are showing inaccessible or orphaned then you can simply unregister the VMs and register them again. (This needs the information documented somewhere about the names of the virtual machines, network they are using / connected to, Datastores they are using or configured on).

If running Nexus 1000v then make sure both VSMs are powered on and can reach to vCenter Server and ESXi host/s. If needed you can register the VSMs on the same host as vCenter Server to make things easy. You can put them back on to the host where they belong as per the DRS rules (if any specified for Nexus
VSMs) set for them once everything is in working order.

2) Where you have large number of Hosts in the cluster (more than 20-50) so atleast you need the name of the Datastore where the vCenter Server files are residing. (Assuming no Storage vMotion occurred before the outage happened) so it will be a good practice to designate a specific datastore for vCenter Server virtual machine files so that it will be easy to just connect to that datastore using ssh from one of the ESXi host which is using as a shared datastore.

You can setup ssh to the host or use local ESXi shell option from DCUI and browse to the datastore and register the vCenter Server on that ESXi host.


vmware-cmd -s register .vmx

or

vim-cmd solo/reistervm /vmfs/volumes/datastore_name/VM_directory/VM_name.vmx

Once you see the vCenter entry in the inventory then just power it on. Make sure the vNIC is connected. Now if the VM was part of VDS then it must be connected to one of the dvPortGroup on the VDS which is not accessible as vCenter Service is not available yet. So you need to create a Standard vSwitch on the ESXi host where you registered the vCenter Server VM. Provide at least one uplink which can carry the same VALN traffic (if there was VLAN configured for the vCenter network) so get the connectivity. Now again you need to see if you have a spare NIC which you can use on VSS and if not (assuming all the NICs are used by VDS) then you just need to use one on VSS which was assigned to VDS before the outage.

3) Now assume you don't know the Datastore / ESXi host name where the vCenter Server was residing and running lastly and you have more than 50/100 hosts in the cluster. 

Here's comes the real part of this post so be patient and read on.

The question is how to find the vCenter Server virtual machine directory.

There are few methods you can go with

a) Run the PowerCLI script across all the ESXi hosts which definitely is a time consuming task as you need to connect to each host individually and run the command.

I can update the post here if someone comes with a PowerCLI one liner so please leave a comment.

b) If you are running SQL Database for vCenter Server database then you need to find out that VM first.
Login to the SQL VM (with local admin or using Domain Admin account (if DC/AD machine is available and accessible). Then login to the SQL Database using the Administrator Account. Run the following query against the VC Database.

First query only returns a host ID

select HOST_ID from VPX_VM where DNS_NAME like '%vcenter%'

You need to use the valued derived in the 2nd query. You just need to replace "vcenter' in the above query to the actual name of your vCenter Server VM name.

select * from VPX_ENTITY where ID='x'

The above will give you the result with the ESXi host where it was lastly registered and running.

Hopefully you can use the same query on Oracle Database as well but not sure so if someone is Oracle Expert then please leave a comment and I will modify the post with actual Query for Oracle database.

The above methods are having certain assumptions such as connectivity, login information to vCenter Server, SQL Server, ESXi host etc. etc. which are needed in the whole restore process.

4) Now the last situation where you dont know the name of the vCenter Server/ESXi Host/Datastore name then you just cross the fingers, pray to God and start digging for the VM on each and every direction possible and make a resolution first that you will DOCUMENT everything about your virtual Inventory going forward. Not joking here as seen instances like this too.

Let me know if you feel to add/update the existing information and I will be happy to do it. Just need your comment through any available medium.

Please share and care !!

Thanks for your time.

Simulating Management Network Redundancy

Hello Readers,

First of all let me thank you, for your time, you will be investing in reading this post. And as this is a long post, I appreciate your patience as the information documented here is very important and helps you Design/Configure/Troubleshoot/Maintain your VMware environment accordingly.


So many times during discussion I came across a situation where power outage happened in the environment and everything went down completely or partially. Now this really depends on the configuration and design you have opted on the Network side of things when you lost the connectivity to your Management Network (either to Service Console - ESX 3.x, ESX 4.x or to vmkernel post ESXi 5.x).

As this is a long post I appreciate your patience as the information documented here is very important and helps you design your environment accordingly.

The purpose of this article is to simulate a condition with which you can test the redundancy of your service console/vmkernel used for carrying the Management Network.

Assumptions made before we proceed:

1) Here I am making an assumption that the configuration on the ESX/ESXi host with atleast two uplinks for redundancy either in NIC Teaming or only have one uplink or more than one uplinks on one vSwitch/VDS or having a second vSwitch/dvportgroup on VDS configured wither either 1 or 2 uplinks.

2) Both NICs are either connected to one physical switch or if connected to two separate physical switches then both uplink switches are connected at L2 using any workable technologies such as vPC, MLAG, SMTL etc. etc.

3) vSwitch port group or VDS dvportgroup are configured with correct Load Balancing policies which corresponds to the configuration on the uplink physical switches

4) Environment is not running any Production workload and it could be Dev/Test/Lab so that no impact on the running Production VMs.

5) The default gateway is reachable from ESX/ESXi

6) If more than one isolation address is required on the Cluster/Host then necessary configuration is done on ESX/ESXi

7) Physical connectivity is configured properly for each ESX/ESXi host irrespective of hardware and other components necessary.

8) ESX/ESXi host is configured to use any of the available tools such as SSH (putty)/DCUI/ILO/DRAC/RSA/KVM etc.

9) All the network cables which are used for providing an uplink/s to ESX/ESXi host are identified properly and marked/documented properly on both ESX/ESXi and physical Switch/es Side.


10) Familiarity with vSphere Networking and use of the necessary commands where not listed.

11) Make changes at the vSwitch level only when you a separate vSwitch configured for Management Network with a different uplink or if using VDS you should have a different dvportgroup configured for Management Network.


1st Method

You can go into VSS port group settings and go to NIC teaming Tab where you can see the two uplinks in Active Active, check mark the box Override failover order, select one of the NICs from the Tea, select the arrow Move Down and click it twice so the NIC will be moved to Unused state from Active state

At this time the vSwitch/VDS will still shows both NICs as Active/Active state. Once you move the NIC into unused state you will see the Management Network will have only one uplink and you will received the warning under the Summary Tab "Host currently has no management network redundancy".

Now HA may also gives you an error but related information is not under the scope of this article and user should be aware about the impact and able to recover if needed.

Note: If the warning continues to appear, disable and re-enable VMware High Availability/FDM (depending on the version of ESX/ESXi in the Cluster.

To set das.ignoreRedundantNetWarning to true (for ESX 3.x and 4.x):

   1. From the VMware Infrastructure Client, right-click on the cluster and click Edit Settings.
   2. Select vSphere HA and click Advanced Options.
   3. In the Options column, enter das.ignoreRedundantNetWarning
   4. In the Value column, type true.

      Note: Steps 3 and 4 create a new option.
   5. Click OK.
   6. Right-click the host and click Reconfigure for vSphere HA. This reconfigures HA.

To set das.ignoreRedundantNetWarning to true in the vSphere 5.1 Web Client:

   1. From the vSphere Web Client, right click on the cluster.
   2. Click on the Manage tab for the cluster, then under Settings click vSphere HA.
   3. Click on the Edit button in the top right corner.
   4. Expand the Advanced Options section, and click Add.
   5. In the Options column, type das.ignoreRedundantNetWarning.
   6. In the Value column, type true.
   7. Click OK.
   8. Right-click the host and click Reconfigure for vSphere HA.

2nd Method

If you do not have access through vSphere client or Web Client then you can set the NIC to unused state using command line through ssh session to the ESX/ESXi hos. Now this command will move the NIC into unsed state for the whole vSwitch or VDS and will NOT make change at the particular port group (VSS) or dvport group (VDS) level.

If using vSwitch (VSS)

#esxcfg-vswitch -U vmnicX vSwitchX

(Note: Replace X with the actual NIC number and vSwitch Number)

For ESXi 5.x

Remove network card (known as vmnics) to or from a Standard vSwitch using these commands:

#esxcli network vswitch standard uplink remove --uplink-name=vmnic --vswitch-name=vSwitch 

Change the link status of one of the uplinks vmnic with one of these commands:

#esxcli network nic down -n vmnicX

If using VDS

To get the dvport ID for the dvportgroup

#esxcfg-vswitch -l | more

To unlink the uplink from VDS

#esxcfg-vswitch -Q vmnicX -V dvPort_ID_of_vmnic dvSwitch

3rd Method

For ESX/ESXi 3.x/4.x, ESXi 5.0 you can change the VLAN property on the VSS/VDS which carries the Management Network though SSH/DCUI

#esxcfg-vswitch -v -p “Service Console” vSwitch0

(Note: for ESXi 5.1 the rollback feature won't allow you to make such change due to which the ESXi host may get disconnected from vCenter server but you can still try the command as we have one uplink still available)

4th Method

You can change the load balancing policy using the command line as well for the vSwitch where the Management Network is configured using Service Console or vmkernel and we are using only one vSwitch with one uplink and have a 2nd vSwitch configured separately with 2nd Management Network (Service Console/VMkernel) with one uplink.

Here you have to use a different teaming policy than the physical switch which results in to loss of Network connectivity on the uplink/s used for Management Network VSS/dvportgroup.

Run the command on ESX/ESXi 3.x/4.x:

#vim-cmd /hostsvc/net/vswitch_setpolicy --nicteaming-policy='loadbalance_ip' vSwitch0

To change the load balancing policy on an ESXi 5.x host, run this command:

#esxcli network vswitch standard policy failover set -l iphash -v vSwitch0

* To change the load balancing policy to a route based on the originating virtual port ID, run this command:

#vim-cmd /hostsvc/net/vswitch_setpolicy --nicteaming-policy='loadbalance_srcid' vSwitch0

* To change the load balancing policy to a route based on the MAC hash, run this command:

#vim-cmd /hostsvc/net/vswitch_setpolicy --nicteaming-policy='loadbalance_srcmac' vSwitch0

Or

#Set load balancing policy. The options are:

    *      Port ID = loadbalance_srcid
    *      IP Hash = loadbalance_ip
    *      MAC = loadbalance_srcmac
    *      Failover Only = failover_explicit

Here is an example command:

#vimsh -n -e "hostsvc/net/vSwitch_setpolicy --nicteaming-policy loadbalance_iphash vSwitch#"

Refresh network settings with the command:
#vimsh -n -e "/internalsvc/refresh_network"

Restart the management service with the command:

#service mgmt-vmware restart

On ESXi 5.x,

* To change the load balancing policy to a route based on the originating virtual port ID, run this command:

#esxcli network vswitch standard policy failover set -l portid -v vSwitch0

* To change the load balancing policy to a route based on the MAC hash, run this command:

#esxcli network vswitch standard policy failover set -l mac -v vSwitchX

* To change the load balancing policy to a route based on the IP hash, run this command:

#esxcli network vswitch standard policy failover set -l iphash -v vSwitchX

Restart the management service with the command:

#/etc/init.d/hostd restart

5th Method

Using Cisco CDP protocol find out the uplink switch port (assuming the uplink switch/es are Cisco branded), access the uplink switch using SSH and go to the port configuration for one of the NIC which is used as an uplink for Management Network, and just shut the port down administratively.

You can click on the small Blue icon right beside the vmnic to find out the CDP information as shown in the attachment.





You will see red X against the NIC which is disconnected in vSphere client which means the link is down.

Using the command "esxcfg-nics -l" will show you the Link is down for that particular NIC as well.

6th Method

By changing the MTU for the portgorup/dvportgorup used for Service Console/vmkernel Management Network

For ESX/ESXi 3.x/4.x if the MTU value selected is Default of 1500 then use the command and use the commands if the configuration is vice versa.

Find out the vmkernel or Service Console first using the command/s.

#esxcfg-vswif -l

#esxcfg-vmknic -l

Find out the port group/dvportgroup name from the out put of the above command/s.

# esxcfg-vmknic -m 9000 portgroup_name

Run this command for ESXi 5.x:

# esxcli network ip interface set -m 9000 -i vmk_interface

7th Method (Need more testing)

Once you connect to the ESX/ESXi host using SSH (putty) or any other tools and use the following command which will blink the NIC for 5-6 seconds.

#ethtool -p  vmnicX

8th Method

You can actually pull the cable from the back of the physical ESX/ESXi host which is carrying the Management Traffic so you need to have the information about the port mapping and related cable used for port/s used for Management Network on VSS/VDS.

9th Method

Warning: Using vsish interface which is currently NOT SUPPORTED by VMware so be careful when using it.

To block a particular link for a certain NIC of the vmkernel, run this command:

vsish -e set /net/pNics/vmnicX/block 1

All the above methods basically isolating the uplink connectivity for one NIC which in turn should break the redundancy status for the Management Network and the host should stay connected inside Virtual Center Server/ vCenter Server.

Enjoy the information and test out your Management Network properly and DO NOT use Production Host/s to test out the above methods.

Share and Care !!

Cheers !!

vSphere VSS & VDS - Cisco Nexus1000v Feature Comparison

I have been asked or requested, so many times before, while talking to the end user or with some one about the features offered by VMware VSS (Virtual Standard Switch), VDS (VMware Distributed Switch) and Cisco Nexus 1000v VDS and I was thinking to gather as much information as I could and blog about it. So here it is.

I believe that any advanced user, working with VMware environment for few years, is aware of the fact that Nexus 1000v is Cisco's product and it will appear as a VDS inside the vSphere GUI. So by looking at the GUI if the naming convention is not used properly for the VDS than you may interpret as a regular VMware VDS so to avoid the confusion one can check the "Summary" Tab of the VDS to verify the vendor of that VDS and also the version of that VDS.

IBM has released Nexus 5000 VDS about which I have not heard much discussion till date. So in this comparison I am not including IBM VDS.

Have a look at the following Table, which I have tried including possibly every feature offered by the VMware VSS, VMware VDS and Nexus VDS. If I miss something then do leave the comment or get in touch with me and I will update the article.

Feature	VMware vSphere 4.x VSS	VMware vSphere 5.5 VDS	Cisco Nexus 1000V 4.2 (1)-SV2(2.2)
Switching Features
Layer 2 Forwarding	YES	YES	YES
IEEE 802.1Q VLAN tagging	YES	YES	YES
Multicast Support (IGMP V2 and V3 support)	YES	YES	YES
IGMP V3 Snooping	-	-	YES
VMware vMotion	YES	YES	YES
Network VMware vMotion	-	YES	YES
Multi-Nic vMotion Support	-	YES	YES
Physical Switch Connectivity
Virtual Mac Pinning	YES	YES	YES
EtherChannel	YES	YES	YES
Virtual Port Channels	-	-	YES
Link Aggregation Control Protocol (LACP)	-	YES	YES
Static LAG	-	YES	YES
Dynamic LAG	-	YES	YES
Load – Balancing Algorithms
Virtual Port ID	YES	YES	YES
Source MAC Address	YES	YES	YES
Source and destination IP Address	YES	YES	YES
Source MAC Address	-	YES	YES
Additional hashing Options	-	YES	YES
Load Based Teaming	-	YES	-
Source and Destination port IP	-	YES	YES
Advanced Port channel	-	YES	YES
IP Hash	YES	YES	YES
Traffic Management Features
Transmit-rate (from Virtual Machine) limiting	YES	YES	YES
Receive-rate (to Virtual Machine) limiting	-	YES	YES
ISCSI Mutipathing	YES	YES	YES
Unicast Flooding Control	-	YES	YES
Quality-of-Service (QoS) marking
Differentiated Serviecs Code Point (DSCP)	-	YES	YES
Type of Service	-	-	YES
Class of Service	-	YES	YES
802.1Q	-	YES	YES
Network IO control (NIOC)	-	YES	YES
Transmit-rate (from Virtual Machine) limiting	YES	YES	YES
Receive-rate (to a Virtual Machine) limiting	-	YES	YES
802.1p	-	YES	YES

Security Features
Port Security	YES	YES	YES
VMware VMsafe Compatible	YES	YES	YES
Private VLANs (PVLANs) 512	-	YES (no limit)	YES(512)
Local PVLAN enforcement	-	YES	YES
PVLAN with Promiscuous Trunk	-	YES	YES
Access Control List (ACLs)	-	YES	YES
Virtual Service Domain	-	-	YES
DHCP Snooping	-	-	YES
IP source Guard	-	-	YES
Dynamic ARP Inspection	-	-	YES
MAC ACL	-	YES	YES
VXLAN	-	YES (no limit)	YES (2048)

Management Features
VMware vCenter Support	YES	YES	YES
VMware vCloud Director Support	YES	YES	YES
vCloud Director Automation Center support	YES	YES	YES
RESTful API	YES	YES	YES
Third-party-Accessible APIs	YES	YES	YES
Network Policy Groups	YES	YES	YES
Multitier Policy Groups	-	-	YES
Packet Capture and Analysis	-	YES	YES
RADIUS and TACACS+	-	-	YES
LLDP	-	YES	-
Network CLI	-	-	YES
Server CLI	YES	YES	-
Configuration and Management Console Interface	vSphere Client	vSphere Web Client/vSphere Client	vCenter and Cisco CLI
Graphical UI	YES	YES	-
Config Backup and Restore	-	YES	YES
Network Rollback and Recovery	-	YES	-
IPv6 for Management	YES	YES	YES
Monitoring and Troubleshooting
VMware Port Mirroring (promiscuous)	YES	YES	YES
Switched Port Analyzer (SPAN)	-	YES	YES
Encapsulated Remote SPAN (ERSPAN)	-	YES	YES
NetFlow ver. 9	-	-	YES
NetFlow ver. 10 (Ipv6, VXLAN flows)	-	YES	-
Network Health Check	-	YES	-

Simple Network Management Protocol (SNMP) V3 Read and Write (V1,V2C)	-	YES	YES
Cisco Discovery Protocol (CDP) v1 and v2	YES	YES	YES
Syslog *	YES	YES	YES
ACL Logging	-	YES	YES
SNMP ACLs	-	-	YES
Network Virtualization
VXLAN support with Multicast	-	YES	YES
VXLAN support without Multicast	-	-	YES
ARP suppression for VXLAN	-	-	YES
L3 Gateway for NV	-	YES	YES
Site-to-Site IPSec VPN	-	YES	YES
Remote Access SSL VPN	-	YES	-
Scalability
Hosts per Switch	500	500	128
Switches per management system (VC)	128	128	32
VXLAN segments	-	10000 (VCNS)	2048
VLAN (no vxlan)	4096	4096	2048
Port Groups/Profiles per Switch	4096	10000	2048
Virtual Ports per host	4096	4096	300
Virtual Ports per Switch	10000	60000	4096
Max Active Virtual ports per Host	1016	1016	300
Max MAC Addresses per Host	No limit	No limit	32000

(NOTE: Above Table is updated for VDS 5.5 so some features which are not shown as supported on VDS 5.5 are fully supported for VDS with NSX so please verify the same.)

* Syslog information is exported and included with VMware ESX/ESXi server events

So you can select the option depending on the features you need. Both VMware and Cisco VDS requires Enterprise + License. Now if you see that I have not included the column for VMware VDS 4.1. The reason behind it, as most of the features available with VDS 5.5 and there are some more features offered with the latest version of VDS so I encourage the reader to use the latest version anyway. Even the Cisco Nexus VDS version is 4.2 (1) - SV2(2.2) which is the latest one.

For configuration of VDS you can refer the online documentation available on www.vmware.com and for Cisco Nexus 1000v VDS you can refer the documentation page here.

I will update the Sheet with NSX 6.0.5 once I get some time so please be waited till then and DO NOT leave the comment for the requesting the same Update :-) but I appreciate any Feedback or comments regarding any features (if missed) or needs an update to the above Table.

Share and Care !!

Enjoy !!