Some of the key features released in vSphere Distributed Switch (VDS) addresses the management and operational aspects. I talked about the Network Health Check feature, which reduces the time it takes to identify configuration issues across virtual and physical switches, in an earlier post . In this post I am going to cover the following features that further simplify the management and operation of VDS:
1) Rollback and Recovery
2) Configuration Backup and Restore
The above features are briefly discussed in the What’s new paper. I will provide some more technical details beyond what is discussed in this paper.
One of the common questions I get asked is whether to have management network on a standard switch (VSS) or distributed switch (VDS) ? For those who are new to this term management network, it is primarily used to provide communication between vCenter Server and vSphere hosts. I will address this question in this post.
I also know that there were concerns of not being able to recover the management network easily while using a VDS. Especially in a scenario when users mis configured their management network port group and lost all hosts connectivity to vCenter Server. In this situation users had to go to each host individually and configure a VSS with proper management network through Direct Console User Interface (DCUI). To avoid the operational overhead of re-configuring the management network on a VSS, in this release of vSphere 5.1, we have introduced the Rollback and Recovery feature.
First of all, Rollback prevents any mis configuration of the management network that could happen while changing any configuration parameters at the VDS and Host level. This in turn will not allow the hosts to disconnect from the vCenter Server. If you perform network configuration changes on a physical switch and those changes cause the hosts to disconnect from vCenter Server, this situation can be addressed through the Recovery feature. The figure below shows the three different points (Circle with number) where the network configuration changes can happen.
Three different points where network configuration changes can happen
Let’s take a look at the details on how rollback features prevents any changes at the VDS (Circle with number 1) and Host (Circle with number 2) level that could impact the connectivity between hosts and vCenter Server.
Rollback feature:
1) It monitors any network configurations change performed at the VDS and Host level. The example of VDS level change is – Management port group properties such as VLAN, teaming and MTU are modified. The example of Host level change is – Management network properties (VLAN, uplinks etc.) are modified through DCUI.
2) When a VDS or Host level configuration change is detected, before committing the change, a network connectivity test is performed with the new network configuration. If the network connectivity test between the host and vCenter Server fails the new configuration is discarded and VDS or Host modifications are reverted back to last working config.
3) Rollback feature can’t monitor any changes on the physical switch side.
Let’s now talk about the Recovery feature. It helps in scenarios where hosts have lost connectivity to vCenter Server. It allows users to reconfigure the management network on individual hosts, directly on a VDS and recover from the failure. There is no need to connect to standard switch (VSS) anymore.
Recovery feature helps in these two scenarios
– When the default rollback feature is disabled (not recommended), and VDS and host level changes disconnect the hosts from vCenter Server
– When the changes on the physical switches disconnect the hosts from VC, and users only have the option to change the management network on hosts.
Recovery feature:
1) This feature requires manual operation. Users have to connect to the hosts direct console user interface (DCUI) and then select Network restore option as shown below.
Select Network Restore Option
2) Users have an option to restore a VSS or VDS. Select VDS.
Select VDS
3) Provide the parameters such as VLAN, uplinks for the management network interface.
Change Management Network parameters
After completing this recovery step a local port is created on the VDS and vmknic vmk0 is connected to that port. As you know, VDS is managed by the vCenter Server, and performing a change locally on a host has made VDS configuration out of synch with VC database. It is important to synchronize the VDS configuration once the host is connected to the vCenter Server. For more details on the step please refer to this post and play the VMware vSphere 5.1 – Networking Rollback and Recovery video.
Rollback and Recovery feature eliminates the concern that users have about putting management network on a VDS. Instead of configuring a separate switch for management network users can have one VDS and simplify their virtual network. This also removes the requirement of at least 4 physical NICs on a host – two NICs for VSS with management network and two NICs for VDS that carries other traffic. Also, the use of two virtual switches is not possible when you have only two -10 gig NICs on a host. In this situation, you have to use one VDS and configure all traffic on the same switch.
The other important feature of the vSPhere 5.1 release is the ability to take a backup of VDS configuration and the ability to restore it. William Lam has already written a post and discussed how you can automate this feature and perform regular backups of your virtual network configurations.
The following are some of the key use cases where configuration backup and restore feature is useful:
1) Administrators can now save the VDS configurations and use it to restore the exact same VDS setup after any failure or in any new environment.
2) Users can also build a revision control system over VDS configuration by saving configurations after each change and use this to restore to any older configuration
Please let me know if you have any specific questions on this feature.
Get notification of these blogs postings and more VMware Networking information by following me on Twitter: @VMWNetworking
