Where are We?
By this point we should be in the position of having our lab cluster up and running, configured for storage and able to authenticate against a real domain with all the control that gives us. We haven’t yet enabled any of the advanced features like vMotion though as this would have required network configuration that we would have removed in this stage.
VMware provides two different ways to configure networking Virtual Standard Switches (VSS) and Virtual Distributed Switches (vDS). So, what’s the difference? Standard switches are, simple, easily configurable switches that have to be configured individually on every ESXi host you have. They also dont need Virtual Center to work. Additionally, for features like vMotion to work they must be configured identically across all hosts. This a management pain and when you scale, it doesn’t!
Virtual Distributed Switches are a centeralised switch that hosts can be members of. They are managed from vCenter and provide unified management of the estates networking and advanced features not in VSS (such as pVLAN tagging).
So, in this part of our tutorial we are going to do a few things.
- Create a new Virtual Distributed Switch
- Migrate the initial VSS configuration and virtual machine networking over to the vDS
- Create a vDS VMKernel Port Group and enable vMotion (because we havent set this up in VSS at this moment).
A small note. In a real environment you would be running with network uplink redundency and would be able to do this in 2 stages. In this example we only have 3 NICs and we will have to migrate components one at a time using the ‘spare’ physical NIC. This means that there is a lot of repition in this part of the blog. It’ll help to understand the process!
Why Do I Want to Do This?
Simply because in the real world you’re unlikley to encounter many enterprises using VSS configurations. vDS setups are more flexible and more widly in use. From a lab perspective it also means you get to play with more advanced features once you’re familar with vSphere so you may as well enable that functionality now.
Step 1: Create a new Virtual Distributed Switch
First we have to create the actual switch within vCenter. So, log on to the vCenter Web Client as before with administrator rights and swititch to the networking tab on the left. Select you Data Center and then click the Actions dropdown. Expand Distributed Switch and select New Distributed Switch.
This brings up a familiar looking wizard. Give your switch a friendly name (it’s good practice to denote that it’s a distributed switch in the name). Click Next.
You can now select the version (feature level) of you vDS. In this example we’re going for the newest to enable all features. In the real world you may want to select an older version if you are integrating with an older VSphere suite. Select the newest version. Click Next.
We now get to choose the number of uplinks we want to assign to the switch. Uplinks map to physical network adapters. The default is 4 and we are going to go with this (even though the lab in this example only has 3 Physical NICs). You can have more uplinks than Physical NICs no problem (they just wont work or don anything).
We also get the option to Create a default Port Group (A port group is analgous to a set of network ports you’d plug wires into, grouped together for a similar task). This first Port Group is the one you’d probably assign for connecting Virtual Machine vNIC to (to enable communication). Give it a friendly name and click Next.
You now get a summery page detailing what has happened and, interestingly, what your next actions should be. Click Finish.
So, we’ve now created a basic Distributed Switch, created a set of uplinks for it (as yet NOT assigned to a Physical NIC) and created a default Purt Group which we shall use for VM connectivity.
Step 2: Add Hosts to the vDS
Now the vDS is created we have to assign our ESXi hosts to the switch and create the additional port groups we are going to need (for Storage and vMotion in our case). To do this navigate to the Networking tab in the Webclient, select the distributed switch we created above, Select the Manage tab (configure in version 6.5), selct settings and then Topology you’ll now need to click on the icon.
This will bring up the Add and Manage Hosts configuration Wizard. This is a Wizard we will keep returning to whenever we make a change to the vDS.
Firstly we will need to add our hosts to the vDS. Select Add Hosts and click Next.
Here you’ll need to select all the hosts you have in your lab and click OK.
You’re shown a confirmation screen. Click Next. Continue to the end of the Wizard and Finish (without altering any configuration). Remember, we’re just connecting the hosts at this point, taking it step by step.
Step 3: Crete Other Port Groups
Now we’re going to create the remaining Port Groups we will need for ther lab. These include:
- A portgroup for iSCSI storage that we will migrate our ‘storage’ VSS to.
- A portgroup for vMotion to enable this feature.
Each portgroup will have a dedicated uplink associated with it (and each uplink will have a dedicated physical NIC).
So, from the vSphere Web Client, navigate to the Networking tab, select the Distributed Switch we have created and right click on it. Select Distributed Port Group and then New Distributed Port Group.
You’ll now be presented with a simple wizard:
Give the Port Group a friendly, descriptive name. Click Next.
Keep the default options for the switch (we can do configuration and explination in detail another time). Click Next.
The Summary screen is shown. Click Finish.
Repeat this Wizard three times. I have created three Port Groups called:
- StorageDPG (for iSCSI traffic and access to storage).
- VMNetworkDPG (for Management and VM communication) [Renamed default Port Group from Step 2].
- vMotionDPG (for vMotion traffic).
At the end of the process you should have something like this.
Back in the Topology view for the vDS you should now see something like this. IT shown the Distributed Switch with it’s uplinks (notice there’s still no physical NICs associated with them). You can also see t he portgroups on the left (currently with no details or items assigned to them).
Now, we have to add Physical NICs to the Uplinks.
Step 4: Add Physical NICS to Uplinks
Click on the icon fromt he topology view to initiate the Add and Manage Hosts wizard again.
Click the Green plus symbol labelled Attached hosts.
Select all the hosts in the lab cluster (all of the ones shown below in this example).
The confirmation will be shown as below. Click Next.
On the next wizard screen select the Manage Host Networking option and click Next.
Now ensure only Manage Physical Adapters is selected and click Next. In this step we are only going to add the spare adapter.
Select the currently not used (or extra) vNIC and click the Assign Uplink button. Assign it to Uplink 1. Note: In the example below if we try to assign one of the vNICS from vSwitch0 or Storage we would end up disconnecting the physical link from the switches BEFORE migrating the networking over to the vDS. This would mean that either Management+VM networking or (worse) storage to the running VMs (Including this vCSA) would die. This causes a horrible mess and is why you should probably run dual NICS / switch in reality (so we could connect half to the new vDS and leave half where they were and do a seemles switchover).
As mentioned above this lab example doesnt have this so we have to perform a rolling migration with our currently unassigned NIC. If you’re messing around in a lab that has multi physical NICs but no spare (but vMotion has been configured) then use the NIC assigned to the vMotion interface as the ‘spare’ as this isn’t a critical componant of keeping a VM alive.
Check everying is assigned to the correct (free) NIC. Click Next.
The next screen shows an impact summary and should alert you is you’re about to do anything stupid. We’re not. Click Next.
Click Finish and the process should complete momentarily. Back at the Topology screen you should notice that the Uplinks sections of the diagram now shows adapters assigned to Uplink 1. In tis example, 2. One for each host.
Step 5: Migrate Networking
Again, click the Add and Manage Hosts button from the topology view and ensure, this time, that just Manage host Networking is selected.
Select both hosts again.
Now ensure Manage VMkernel adapter and Migrate virtual machine networking options are selected.
Now select the VMK0 adapter currently assigned to vSwitch0 (Management Network) and select the Assign Port Group button.
Assign this to the newley created VMNetworkDPG vDS port group and ensure the same is done for the second (and any other additional) hosts in your environment. Click Next. Leave the storage adapter alone for the moment.
Check that nothing will be broken in the Analyze Impact window.
Now, on the Migrate vm Networking window expand and ensure all the VMs currently in the lab are migrated over to the new Port Group. In the example be low you can see the three VMs already in my lab (including this VCSA) ready to migrate from the VM Network VSS Port group to the VMNetworkDPG vDS Portgroup.
Review the settings to ensure everything is as it should be. Finish the wizard.
You should now see, in the topology view, the three VMs attached to Uplink 1 and, crucially, you should still have network connectivity to the LVCA web interface.
Next, restart the Add and Manage Hosts wizard to move the next set of items over.
Select all the hosts in the lab.
Select Manage physical adapters and Manage VMkernel adapters.
Now assign the NIC in use by vSwitch0 (which we migrated the networking OFF off in the last step through the wizard) to Uplink 2. Do this for all hosts in the environment.
Now click the Assign Port Group button and ensure that the vmkernel port currently used for storage in the VSS is migrated to the StorageDPG . Notice how we are rotating the next VSS switch to the DPG to free up the final adapter in the next step.
A final check on the Analyse Impact screen and it is showing a warning. In this instance it is simply telling us that we are switching physical NICs in this operation. We know this to be the case as were having to shuffle non resilliant connections.
Check the summery screen and Finish
Once complete we, again, should still ahve access to our VMs (the storage is still connected) and the StorageDPG portgroup and vmk ports anre connected to Uplink 2
For one final time. Restart the Wiard and select Manage host networking
Add all the hosts from the environment.
Ensure the Manage physical adapters and Manage VMkernel adapters options are selected.
Assign the final unused NIC from the VSS to Uplink 3. This should be the NIC assigned to the Storage switch in the old networking.
On the Manage VMkernel adapters screen click the New adapter button.
One the Select target device screen click browse to select an existing network.
Now select the vMotionDPG portgroup that was created right back at the start of this stage of the guide. Note in the screenshot belowthe WRONG network is hilighted…
For the Port Propeties tick vMotion traffic under enable services.
Assign the new VMkernel port for vMotion an IP address and appropriate subnet.
Now assign this new VMK port to the vMotionDPG distributed port group on all hosts. NOTE: In the picture below I got it wrong for host esxi01. Host esxi02 is CORRECT.
One final Analyse Impact screen is shown. Move on to thee Summary screen and complete the wizard.
Like before, you should be able to see the two new VMkernel ports assigned to the vMotionDPG port group.
That’s it. We have migrated all the networking from VSS to vDS and created a final DPG and VMK port for vMotion capabilities. We now have centerally managed networking from within vCenter with the ability to migrate VMs across hosts. We also have the storage and regular network traffic controlled fromt he same area.
Step 6: Cleanup
Now everything is controlled by the vDS we just need to clean up the older VSS configuration. To do this from the Web Client select the individual host from the Hosts and Clusters view, select the 1st host, the manage tab, networking and then virtual switches. This will list the vDS and the two (obsolete) standard switches (vSwitch0 and Storage). Select the 1st VSS and click the red ‘x’ to delete it. Now do the same for the final VSS. NOTE: In version 6.5 select the switch, click actions then select remove.
Remember that you will have to do this for all the hosts you have as VSS and not centerally controlled.
Next we will roll through some of the feaures in vCenter such as HA, DRS and vMotion. this will be in part 5 of this beginners series.