Yellow Bricks

by Duncan Epping

network

ESXi “Management traffic” tickbox, what does it do?

· ·

I have seen this popping up various times over the last few years. That little tickbox on your VMkernel NIC that says “Management traffic” (aka management network) what is it for? What if I untick it, will SSH to that VMkernel still work? Will the HA heartbeat still work? Can I still ping the VMkernel NIC? Those are all questions I have had in the past, and I can understand why… I would say that the term “Management traffic” is really really poorly chosen, but why?

The feature described as “Management traffic” does nothing more than enabling that VMkernel NIC for HA heartbeat traffic. Yes that is it. Even if you disable this feature, management traffic, you can still use the VMkernel’s associated IP address for adding it to vCenter Server. You can still SSH that VMkernel associated IP address if you have SSH enabled. So keep that in mind.

Yes I fully agree, very confusing but there you have it: the “management traffic” enables the HA heartbeat network, nothing more and nothing less.

Testing your infrastructure!

· ·

Last week I was helping someone on the VMTN community forums. They were hitting what appeared to be strange HA behavior. After some standard questions this person told me that all VMs were powered down after a network outage. Sounds like a familiar problem? Yes I can hear most of you think: Isolation response set to “power off” and no proper network redundancy?

Well yes and no. They had the isolation response indeed configured to “power off” all VMs when the host is isolated. They did however have proper network redundancy, so how on earth did this happen? With 2 physical NICs and 2 physical switches and only 1 being impacted this should not have happened right?!?

Wrong! In this case the fail-over from a “vmkernel” perspective worked fine. The first “path” went down, so the second was used for this management vmkernel. All VMs were up and running until this point, and they remained running until… network connection was restored and the vmnic returned to the original physical NIC. Meaning that the mac address that showed up on port 1 popped up on port 2 and then went back to 1 again. The switch was not impressed and went through the spanning tree process and traffic was blocked instantly as a result of it. Now when traffic is blocked bad things can happen, especially when you configure HA to “power off” VMs. Basically what caused this issue to happen was the fact the spanning tree was not set to the recommended “port fast”, more details here.

I knew instantly that this was the reason for this problem, not because I know stuff about HA but because I had seen this many times in the past while testing environments I configured and designed. Not just testing after implementing a new infrastructure, but also testing after making changes to an infrastructure or introducing a new version / feature. I guess this kind of comes back to the “disaster” scenario as well, test it if you want to know if it works as expected. Just a simple example, I want to introduce QoS for my vMotion network and make changes to my physical network. Now what? How do I test these changes? How many times do I run through my test scenarios? What kind of “problems” do I introduce during my tests?

So I guess by now some might wonder why on earth I brought this up… well the problem above could have been prevented by simply testing the infrastructure when implemented and after changes have been introduced, and maybe even on a regular basis. If HA / Networking was tested properly, those VMs would not have been powered off…

Network port diagram for vSphere 5.x

· ·

Somehow I missed this one, but as I reviewed the diagram and helped selecting the right format I figured I would still share it. This Network port diagram for vSphere 5.x is one awesome resource for those folks who want to get to the bottom of how components interact with each other.

I don’t think there is a lot more I can say about it, those who love diagrams and like to know the details make sure to hit: http://kb.vmware.com/kb/2054806

Back to Basics: Using the vSphere 5.1 Web Client to configure a vSwitch

· ·

In the previous articles we created a Datacenter, a cluster and added hosts to it. Now that we have done that we can start finalizing the configuration. This is just one example out of the many ways to configure networking for an ESXi host, and I kept it really really simple. This is not following any best practices, I just wanted to show some of the steps. In this scenario I have 4 network cards per host and I have VLANs for each network segment. Separating traffic through the use of VLAN is highly recommended and is a best practice.

Lets configure the virtual switch first. I will use a “standard vSwitch” for now. In this case we will set all vmnics to active on the vSwitch and control NIC usage on a portgroup level. [Read more…] about Back to Basics: Using the vSphere 5.1 Web Client to configure a vSwitch