I’ve read Ken’s article on Service Console redundancy a couple of times, When is it OK to default on your VI? As I also wrote on the VMTN Blog I really love Ken’s posts so far. They are in depth and Ken knows what he is talking about. His argument, keep it simple, make sense.
Basically, what we’ve done is to let everything default. All the adapters are active, the load balancing method is virtual switch port based and nothing is overridden by the port groups.
But I actually don’t agree with Ken on this one. I never use “virtual port id” load balancing for the Service Console and VMkernel, especially not if I combine these two port groups on one vSwitch.
Call me a control freak if you like, but I want to know which port group is using which vmnic. I always use an Active/Standby scenario for the vSwitch that holds the Service Console and VMkernel. Let me steal Ken’s excellent diagram to give you an idea what I’m talking about:
If anything goes wrong there’s full redundancy, which is a must have. The setup can be scripted in a couple of lines and if you need to troubleshoot you know exactly which physical NIC is being used for what purpose. The Service Console and the VMkernel/VMotion are just too important to be guessing where they are running in my opinion, especially in large environments. I want every server to be exactly the same, I don’t want to have the Service Console running on vmnic0 on the first server and on vmnic2 on the next. Like I said… I like to be in control, full control.
For those who want to set this up via a scripted install:
/usr/bin/vimsh -n -e “hostsvc/net/portgroup_set –nicorderpolicy-active=vmnic0 –nicorderpolicy-standby=vmnic2 vSwitch0 ‘Service Console’”
/usr/bin/vimsh -n -e “hostsvc/net/portgroup_set –nicorderpolicy-active=vmnic2 –nicorderpolicy-standby=vmnico vSwitch0 VMkernel”
Tom says
If possible, a diagram showing what your idea looks like in the VMware networking section with IPs would help people understand this better.
This would help people make the connection between your comments and Ken’s diagram.
And Ken’s approach (KISS) works just fine in small environments of <5 hosts.
Ken Cline says
Duncan, you graphic thief! I understand your position – and it is valid…as long as you know what you’re doing and you’re making conscious choices regarding the complexity of your environment, go for it!
The problem I have is that far too many people deviate from the default because they’ve seen someone else do it and they think it’s cool, or simply to try to justify their drawing a paycheck.
There are times when complexity serves a purpose. In those instances, I’m all for it! If your changes from default improve the manageability of your environment, than that’s a good thing. Just make sure you document the decision drivers so the next person behind you understands why you did something!
btw – you are using virtual port ID load balancing…you’re just setting a single vmnic active for each port group so there’s not enough resources to distribute the load. If you were to add additional vmnics to one or both of your port groups, the effective policy would be vPort ID.
Thanks for the compliment, and you’re welcome to steal my graphics whenever you want.
KLC
Justin says
I follow the same approach for all my ESX hosts, and thankfully VMware is making it easier to get a consistent setup across hosts.
Duncan Epping says
@Tom : I think the diagram above clearly shows the idea…
@Ken : I agree, but I usually work for enterprise companies that’s why I use this approach. Then again I also used it for SMB environments, like I said I like to be in control. I also never use more then 1 nic for vmotion btw, I’ve never encountered an environment so far that needs more then 1GB
Keith says
We use the same in our deployments although we trunk both connections (dot1q) to redundant switches and allow both VLANS in the allow list for console/vmotion traffic but do set the failover/standby nic order as you’ve both described 😉 great blog posts Duncan/Ken keep em coming 😉
vmmeup says
I totally agree this is the configuration I always recommend. I script this the same way you described but for good measure I also include the following:
vmware-vim-cmd hostsvc/net/vswitch_setpolicy –nicorderpolicy-active=vmnic0,vmnic6 vSwitch0
It shouldn’t be necessary but I have seen instances where for some reason vimsh changes the vswitch failover and makes one of the nics standby after setting the portgroup failover options.
-Sid