Manage Learn to apply best practices and optimize your operations.

Best practices for your hypervisor management network

When it comes to hypervisor configurations, setting up the management network can often be overlooked. The key to it is the number of network adaptors.

Whether your organization uses VMware, Hyper-V or something else, there is a whole laundry list of best practices...

when it comes to hypervisor configurations. One aspect of the configuration process that sometimes gets lost in the shuffle is the hypervisor management network. In this tip, I will share some best practices for configuring your management network.

The configuration of your management network really comes down to the number of network adapters that are installed in your host servers and the way in which those network adapters are utilized.

Hyper-V and VMware ESXi can function on a server that is equipped with a single network adapter. But just because you can do something doesn't necessarily mean that you should. I typically recommend that hypervisor­ servers be provisioned with as many physical network adapters as the server will hold. Of course quantity isn't everything. How you use those network adapters is just as important.

I recommend using a bare minimum of three network adapters in a Hyper-V environment, but more when possible. The first of these network adapters should be used for the management network. This segment should be used primarily for management and monitoring tasks.

Being that physical servers have a limited number of network adapters, some organizations share a segment between the management network and the cluster network. If you decide to use this approach, you have to be very careful about how the cluster network is configured.

Figure A shows the Cluster Network Properties dialog box for a network segment. As you can see in the figure, you can use the available radio buttons to either allow or disallow cluster communications on the selected network. The thing that you have to be careful about is user traffic. If you choose to allow cluster network communications across a network then client connectivity is allowed by default. You can disallow client connectivity by deselecting the "Allow Clients to Connect Through This Network" checkbox.

Figure A - Clients are allowed to connect through cluster networks by default.
Figure A. Clients are allowed to connect through cluster networks by default.

If you are going to use a dedicated network for cluster communications then your best option is to use a dedicated backbone segment for cluster configuration. However, if you are going to use a segment for both cluster traffic and management traffic, then using an isolated backbone segment won't be an option unless you have a dedicated management station that is connected to the segment.

Earlier I mentioned that production Hyper-V servers should have a minimum of three network adapters, and that the first of these adapters should be used for cluster and management traffic. The second network adapter should be used for user traffic and the third network adapter should be used for storage traffic. Obviously this arrangement doesn't work 100% of the time. For instance a server might use direct attached storage or Fibre Channel storage. Even so, the three network adapter rule is a good guideline.

Beyond the three physical network adapters that production Hyper-V servers should have, users should install as many physical network adapters as your server will accommodate. But where do the remaining network adapters come into play?

If your Hyper-V server has more than three physical network adapters then I recommend using the remaining NICs to build NIC teams. A NIC team is a collection of physical NICs that collectively function as one. Windows Server 2012 and 2012 R2 allow NIC teams to be defined at the software level. The best part is that NIC teams can be based around commodity NICs. No specialized hardware is required.

NIC teams are often discussed in terms of performance. NIC teams perform bandwidth aggregation and together provide more bandwidth than what a single NIC would be able to deliver. This is great for VM networks and storage networks because these types of networks can almost always benefit from extra bandwidth. However, the use of NIC teams is also a good idea for management networks even though they are rarely bandwidth intensive (except during some backups). The reason for this is that a NIC team can be provisioned with a spare NIC so that the team will keep on working after a single NIC failure has occurred. NIC teams can be configured for failover or for load balancing, and can be implemented in either a switch independent or a switch dependent configuration. It is important to use the configuration that makes the most sense for your network.

Your hypervisor management network should be logically isolated so that it only carries management, monitoring and perhaps clustering traffic. You can help to ensure traffic isolation by avoiding the installation of applications directly on your host servers and by configuring firewall rules to block any types of traffic that are not specifically required.

Dig Deeper on Improving server management with virtualization