Tal Gerafi

Port Group Configuration Inconsistencies Among Cluster Hosts

  • July 13, 2016
  • 3 min read

About Continuity™

Continuity™ provides the industry’s ONLY storage & backup security solution, to help you protect your most valuable data.

Read more

[vc_row][vc_column width=”2/3″][vc_column_text]

The Enviroment

VMware vSphere HA offers a robust set of capabilities for ensuring continuous uptime, even when one of the host servers fails. However, high availability, fault tolerant and vMotion depend on the correct configuration of its host options, hardware, storage, and virtual networking.

What Can Go Wrong?

As part of best practice, port groups must be configured for every host server in the cluster that is required to support VMs that depend on the port group. Virtual switches and subnetwork port group names are case and space sensitive. Configuring hundreds of settings with zero errors can be extremely challenging and human error is essentially unavoidable: especially for IT teams with stretched resources and assignment overload.

When a host fails, vSphere HA will assign the VMs running on it to other hosts in the cluster. If a port group associated with a VM has not been configured correctly (or even at all) on a target host, once the failover is complete the VM will not be able to communicate over the network. In other words, even though vSphere will consider the failover to be successful, the VM will not function. IT teams may never know about it until it’s too late.

Here are several examples of how this can occur:

  • A simple typo
  • Certain port groups are intended to be configured on some hosts in the cluster, but not all (common when affinity and anti-affinity rules are used). An error can occur when a port group is configured on host ‘B’ instead of host ‘A’ (Perhaps as the result of a miscommunication between team members, incorrect documentation, etc.).
  • The automation scripts contain a bug.

The Impact

Ultimately, it is the end-users that will be affected by the lack of communication between applications running on the virtual cluster. The risk level and possible damage depend on how critical the applications are to the organization and its users. Examples include:

  • End-users that cannot reach websites or other online resources.
  • Traders that cannot access real-time information or execute buy & sell orders.
  • Customers that cannot access online accounts, online information, or other services.

[/vc_column_text][/vc_column][vc_column width=”1/3″ css=”.vc_custom_1457025019211{border-top-width: 1px !important;border-right-width: 1px !important;border-bottom-width: 1px !important;border-left-width: 1px !important;padding-top: 35px !important;padding-right: 35px !important;padding-bottom: 35px !important;padding-left: 35px !important;border-left-color: #cccccc !important;border-left-style: solid !important;border-right-color: #cccccc !important;border-right-style: solid !important;border-top-color: #cccccc !important;border-top-style: solid !important;border-bottom-color: #cccccc !important;border-bottom-style: solid !important;}”][vc_column_text]

The Solution

AvailabilityGuard™ offers automated detection and analysis of performance and availability risks across your entire private cloud infrastructure. For example, AvailabilityGuard detects missing or incorrect port group configurations and alerts the IT team, enabling them to fix the issue before it impacts end-users.


Talk To An Expert

It’s time to automate the secure configuration of your storage & backup systems.

Join Our 10-Minute Quick Demo - Wednesday, June 5 at 12 PM ET

We use cookies to enable website functionality, understand the performance of our site, provide social media features, and serve more relevant content to you.
We may also place cookies on our and our partners’ behalf to help us deliver more targeted ads and assess the performance of these campaigns. You may review our
Privacy Policy I Agree