I guess we are all familiar with the concept of virtualization. Now days we virtualize virtually anything : servers, desktops, network, storage, … As a one friend of mine said “I have just virtualized a virtual machine inside of yet another virtual machine”.
There is so much to talk about this concept that I hardly could find a right topic to begin with. Because I’m also in a networking world, I guess the logical choice would be to talk about networking in the virtual world, about switches, to be precise.
I will start off with an assumption that the reader of this blog has some general ideas and basic experience with the virtualization with a VMWare vSphere platform and has a knowledge of virtual switches within it. This blog will be about the distributed virtual switches or vDSs. What is the difference between them and standard virtual switches or vSSs, why would we need a vDS when we have a vSS and how to migrate from vSS to vDS.
As usual, let’s see what we are dealing with:
This is a basic view of a vSphere 5.1 infrastructure. Many things said in this blog apply to previous versions as well. As we can see, we are viewing this virtual infrastructure through a Virtual center called “vSpop”, we have a datacenter named “SPOP” and we have a cluster of four ESXi hosts. This cluster is called “CLUSTER1” and is located within the “ABACUS” folder. We also have some virtual machines running on different hosts within this cluster.
Now I would like to talk about the way these virtual machines (VMs) interacts with the “outside world” or our corporate resources. Let me try explain this by using the following snapshot:
From here, we can see a lot. First of all, we are viewing a network settings on “esxabacusbn1”. We can see that under the networking a vSS “vSwitch0” switch exists and is bound to a physical NIC “vmnic4”. Inside this vSS several port groups are created, such as “VLAN12”. This name could be anything, like “Marketing” or whatever. I just prefer to call port groups according to VLANs they represent. Inside of these port groups (essentially VLANs) a VMs exist. Further to the right we can see that “vmnic4” is attached to a physical Cisco switch, to port GigabitEthernet1/0/9. This port is a trunk port with nothing smart within its config:
switchport trunk native vlan 99
switchport trunk allowed vlan 10,12,112,141-143
switchport mode trunk
spanning-tree portfast trunk
If we would like to describe the communication from a “W7-1” VM to the outside world using a single sentence. That sentence could be: “A W7-1 PC is attached to a virtual switch vSwitch0, and belongs to VLAN12. The traffic from this PC is carried to a physical world through the physical adapter vmnic4 that connects a virtual switch and a physical switch over a trunk link.” Ok, two sentences
Now let’s take a look to another server in the cluster:
This is from “esxabacusbn3”. We can see similar layout, but if we look closely, we could see that we have a port group “VLAN12” created with no VMs inside. Big question here is why we would need a port groups created if we didn’t have any VMs inside? Well the answer could be – VMotion. Within a cluster, we could move VMs from one host to another. Either manually or as a part of HA functionality. So for this “W7-1” VM to operate properly if moved from “esxabacusbn1” to “esxabacusbn3”, on both hosts we need to have the same port group defined. The same goes with all other ESX hosts within a cluster. I guess a problem starts to be obvious with vSSs: we have to have all port groups defined on all ESX hosts and these port groups must be set up the same way! Now imagine a cluster with a ten hosts and a request that a VM is added to some VLAN. This VM belongs to one of Marketing dpt’s VLANs. So we create a port group called “Marketing_BA_VLAN100” on one of the hosts and set up a VM. To be sure this VM is able to power on on other nine hosts in the cluster, we have to define “Marketing_BA_VLAN100” on all of these nine hosts. Now imagine that we forget to set this port group on one host or we make a mistake and create a port group “Marketing_BAVLAN100” (one underscore is omitted by mistake). This VM will not be able to power on on this host! Bummer! There you have a call from a Marketing dpt’s director. One call that would not be made if we had a vDS!
Here goes a tough question: how do we migrate to a vDS? I guess there could be more than one way, but this time I will describe one. Let me say that I won’t be discussing a licensing issues with vSphere infrastructure and vDS or a hardware compatibility issues. This is where every man is for himself.
Ideally all servers have a spare physical NIC, because this makes things easier and less stressful. Remember this Marketing director? We don’t want to have any network disruptions. Now I’m not saying this cannot be done without that spare NIC, but like I said, I will describe one way…
After we made sure we have a spare NICs and made note about their names, we could start by creating a vDS. From a “Networking” inventory tab, we click “Add a vSphere Distributed Switch”:
Depending on our infrastructure, we select appropriate vDS version and click “Next”:
Next we name this switch and state the number of physical NICs per server that we want to allocate to this vDS. I will chose only one, but in real environment we would chose at least two and connected them to two different physical swithes:
Click “Next” and an opportunity will be presented to us to add ESX hosts to this vDS. We could do this now or after the vDS is created. We will include all four hosts now:
Here we can see that on “esxabacusbn1” a “vmnic2” is selected. We can also see that we want other three hosts to participate in this vDS. We click “Next”.
On the “Ready to Complete” screen we deselect “Automatically create a default port group”, because we will create port groups later. We click “Finish”.
In the “Recent Tasks” pane, we could verify that the vDS created successfully, and on the “Networking” inventory we can see our dVS with selected uplink ports and no port groups. Before we create or migrate port groups from vSS, let’s go under the “Hosts” tab in the “Networking” inventory and verify our hosts are indeed a part of this vDS:
So, we are good to go! These “Connected” states mean that some sort of agent is installed on all hosts through which vSphere controls a networking that belongs to a vDS.
If we go back to a network settings on “esxabacusbn1” we could see a previously discussed vSS shown on the top of the blog. Now, in addition to this vSS, we have a vDS as well:
Didn’t we select “vmnic2” to be part of this vDS in the installation wizard?
Now we need to create that “Marketing_BA_VLAN100” only once and all hosts will have the knowledge about it. From the “Networking” inventory, we click our vDS, click “Create a new port group” and complete a simple wizard:
After this, on all vDS members we should see this port group created. For example, “esxabacusbn4”:
Now we can install, power on and move any VM belonging to this port group from any host to any other. Of course, we should not forget to add this VLAN 100 to the list of allowed VLANS on appropriate trunk links on a physical switch.
Finally, when we have a vDS, we could migrate our VMs from a vSS to a vDS. Remember that “W7-1” PC from the begining ? Let’s do that.
First we create port group for that VLAN inside the vDS:
Then we edit “W7-1” machine properties to change the switch membership:
In green, we can see an old setting and in red the new one. It’s the same VLAN, but on different virtual switches. Let’s apply this setting and verify that it is as expected and that we have a connectivity to/from “W7-1”:
Depending on application(s) running on “W7-1”, we will or will not have any downtime with this migration.
Now we could move all other VMs and have only vDS, or we can have a so-called hybrid solution with, for example “VMKernel” ports on vSS and VM ports on vDS, or any other combination. You know what is fun? Having vSS along with vDS and adding a Cisco Nexus 1000V
Beside this VMotion thing, vDS has other features that vSS does not and I advise you to go to VMWare site to find more about those features.
Thanks for reading and join me in the next blog.