TA2650 scripts – Part 3 – Checking cluster node configurations

With the cluster profile XML file created in TA2650 scripts – Part 1 – Profiling your vSphere environment you can verify the configuration of the nodes against a reference node.

In the XML file the configuration settings of each node are present in the Config nodes.


With the following script you select one of the nodes as the reference node and the script will then compare the config properties of all the other nodes against this reference node.

The script will produce a CSV file that contains all differences.

Note that a lot of these differences are quite obvious, like for example hostname, MAC address…, and can thus be safely ignored during the review.

The CSV file has this layout


The first column, named Path, is the XMLPath to the property in the XML file.

The 2nd and 3rd columns show the name of the reference node (RefHost) and the name of the node (CmpHost) that was compared against the reference node.

The Name column shows the name of the property.

The RefValue and CmpValue show the property values that were found on the reference node and on the node that was compared against the reference node.

The AttributeDiscrepancy and the ChildrenDiscrepancy columns are Boolean flags that show if the script at one point lost synchronisation between the RefHost and the CmpHost for the attributes or for the child nodes.

As an example of the possible benefit of such a comparison, I discovered that on my test environment the CSV file showed a difference for the Inventory/Cluster/Host/Config/Firewall/Ruleset Count between the two cluster nodes.

cluster-node-compare-3This indicated that the firewall rules on both ESX nodes were not the same. And indeed after further checking I discovered that I forgot to active a firewall rule on the 2nd node.

Note that current script is not too intelligent. It will not try to synchronise between the two nodes when one of the nodes is missing an entry. As an example you will notice that the firewall rules will run async from a certain point onwards. On the other hand this also gives you a good indication where the problem is located. In this case the aam firewall rule was missing on the 2nd node.

Leave a Reply

Your email address will not be published. Required fields are marked *


Buy the Book