Part of a vSphere design is to develop a virtual switch design and for a long time I have been following “best practices” and by that I mean in the context of a virtual switch design, go for hybrid ! I always kind of blindly accepted this until recently I had a discussion with a networking guy about the vSphere design I was presenting to them.

This particular customer had separate physical switches for every type of traffic and I asked the networking people what their reasons are for doing this, furthermore how could they stick to this design if they would move to a 10Gb network infrastructure and their ESX hosts would most likely only have two interfaces ..? The guy turned around to me and said “while I understand your point, you are basically implying that we should consider to move away from having separate switches per type of traffic but on the other hand you (me) just presented us a virtual switch design based on two different types virtual switches (I presented them the Hybrid solution).. “. This person had a point and because I never really thought about it, I didn’t know what to say a part from “..well, this is a best practice, because when you lose your vCenter you can not manage you dVS anymore.

Driving back home, I was still trying to figure out where does this best practice comes from, when I got home I locked myself up in my lab and tested both scenario’s AND still I could not find a decent explanation !

Let’s describe the best practice -> A hybrid model, where you connect your management interface to a vSS and virtual machine traffic to a vDS is the preferred solution because if your vCenter fails you cannot manage your vDS anymore.

Let’s go over both design options, Hybrid and full vDS and determine their impact when vCenter would fail:

• Scenario 1: (Hybrid design)

  If vCenter is down, everything continues to operate as normal (I am assuming the default option “Static Binding”), except you cannot make any changes to vDS neither can you provision or change networking for VM’s. Let’s imagine worst case scenario and your vCenter crashed and you would have to re-provision/restore it. Well in this case you will have to take one uplink (that’s currently linked to a vDS and is connected to a trunk port with access to the appropriate VLAN) and link it to your vSS, restore or rebuild your vCenter and once it is up and running you would migrate it back to the vDS.

• Scenario 2: (Full vDS)

  If vCenter is down, everything continues to operate as normal (I am assuming the default option “Static Binding”), except you cannot make any changes to vDS neither can you provision or change networking for VM’s – (Yes, your ESX hosts continue to operate and are accessible). Let’s imagine worst case scenario and your vCenter crashed and you would have to re-provision/restore it. Well in this case you will have to create a vSS, take one uplink (that’s currently linked to a vDS and is connected to a trunk port with access to the appropriate VLAN) and link it to your vSS, restore or rebuild your vCenter and once it is up and running you would migrate it back to the vDS.

So what is the difference between the two options ? Well, you would have to create a vSS, but irrespective the procedure you are required to follow is basically the same and I am a huge fan of keeping your environment as simple as possible and with that I mean in this context “why using two different types of vSwitches if you are not required to do so”. Additionally let’s be fair, how often would it happen that you would have to restore your vCenter server, you have VMware HA, some of you even might have Heartbeat and I am assuming procedures on how to react on a situation like the one described above are well documented and your company doesn’t only rely on you…

Bottom-line I  changed the design document to include a full vDS design, though I am really interested if somebody could give me a reason why a hybrid model is still the better option.

Update 27-04-2011: Duncan wrote an article about the same topic, check it out !