I receive the same question around dvSwitches almost every week; should I only use dvSwitches or go for a hybrid model? The whitepaper that has been released a couple of months ago clearly states that a hybrid model is a supported configuration but would I recommend it? Or would a pure vDS model make more senses?
Let me first start with the most obvious answer: it depends. Let’s break it down and create two categories:
- Hosts with two NIC ports
- Hosts with more than two NIC ports
Now most of you would probably say who the hell would only have two NIC ports? Think 10Gbe in blade environments for instance. With only two physical NIC ports available you would not have many options. You would have exactly two options(if not using Flex-10 of course):
- Pure vDS
- Pure vSwitch
Indeed, no hybrid option as you would still want to have full redundancy which means you will need at least 2 physical ports for any virtual switch. Now what would I recommend when there are only two physical NIC ports available; I guess it depends on the customer. There are multiple pros and cons for both models but I will pick the most obvious and relevant two for now:
- PRO vDS: Operational benefits. Updating port groups, consistency and increased flexibility with vDS.
- CON vDS: If vCenter fails there’s no way to manage your vDS
There it is; probably the most important argument on why or why not to run your Service Console on a vDS. If vCenter fails there’s no way to manage your vDS. For me personally this is the main reason why I would most like not recommend running your Service Console/VMkernel portgroups on a dvSwitch. In other words: Hybrid is the way to go…
vSphere 4.0 Quick Start Guide
totally agree to go for hybrid because of losing the ability to manage after losing vCenter – or having license issues. Furthermore not all features are already able to use dvSwitches flawlesse, for example if you import a virtual appliance (ovf). You´ll end up with a message telling you that no network switches could be recognized. After creating a standard vSwitch everything works fine.
In this type of environment where do you recommend placing the 2nd service console?
2nd Service Console? I usually don’t even set it up. It’s more complex and confusing to most people. But if you do set it up, it’s a secondary so it would be fine to use the dvSwitch for that!
So if vCenter fails and there’s no way to manage your vDS, what would you be able to do by having your SC and VMkernal ports on a standard vSwitch? I’m probably thinking you would still be able to login locally to an ESX host and then manage the standard vSwitch but what use will that be when your vCentre has gone down?
Also – where did you get the icons for your diagram?
with a normal vSwitch you can do everything from the COS. (VLANs, amount of ports, you name it and you can do it)
Diagram is a copy from the Whitepaper VMware released linked in the article. Most of them however can be found on VI:OPS.
Duncan, thanks for your writeup and link to the whitepaper! I’ve been dealing with having to maximize available vSwitch’es while maintaining redundancy and bandwidth (standby, load balancing schemes, etc) in ‘low nic environments’.
It’s always been working fine for me.. but having had some remarks about ‘hey, that’s not a best practice!!’, this has reinforced that what I’m doing is the right thing to do in such environments.
You saved the day again!
thanks!
Thanks for brining awareness to this whitepaper. I’m a fan of VMs on on the vDS and VMkernel ports on traditional switches. The end.
Another thought – if you have configured Lockdown mode so that ESX hosts can only be managed via vCenter, and your vCenter server goes down, can you still connect to your ESX host?
Thanks for posting this awareness about the vCenter. Actually, I was already in my way to configure it, but after reading your blog i decided not to till I got my CPU’s that are supported for FT.
Once I got them, then I will configure the vCenter with FT Mode and then play around with the vDS