Generate VMware Product Interoperability report…the PowerCLI way.
Contents
Challenge
If you are working with VMware products, you have probably already used the VMware Product Interoperability Matrices.
It is perfectly fine with few products, especially when using “All Solutions” in the second field.
However it has limitation when starting to work with many products because all products must be checked against each other.
For example:
2 products = 1 check
3 products = 3 check
4 products = 6 check
…
10 products = 45 check
10 products in a SDDC platform is not uncommon.
But it is not that simple, some VMware products are never “Compatible” in the matrices, like NSX and vSphere Replication.
So there is no point to check compatibility between these two products…but you need to have checked it at least once to know it.
Second limitation, it is not possible to generate a report automatically.
(Generate CSV reports from the web site is a manual process)
Solution
PowerShell is the answer to the Ultimate Question of Life, the Universe, and Everything.
Three PowerShell functions that will make your life easier.
VMware Product Interoperability Matrices PowerCLI in GitHub.
get-InteroperabilityMatrixVersion
get-InteroperabilityMatrixVersion #Result: #2017-05-12-1115
The above command is useful to check if the “database” in the VMware website has been modified since last time you have checked.
In the format Year-Month-Day-“Build?”
get-SolutionAndVersion
get-SolutionAndVersion #Result extract: #AirWatch Console - 8.2 #.... #vSphere PowerCLI for Tenants - 5.8.0 (get-SolutionAndVersion | measure-object).count #Result: #923 get-SolutionAndVersion | ogv #Result
The command above list ALL products with ALL version existing in the interoperability matrices. More than 900.
By design all “unsupported releases” are removed from the output but the function has a switch to include them if needed.
I like to use “Out-GridView” and copy paste to excel, however this is a PowerShell table so you can do anything with it.
Then create a PowerShell array with all “ProductVersion” that you want to test against each other.
It will be used in the next function.
For example:
$SolutionAndVersionTable = @() $SolutionAndVersionTable += "VMware NSX for vSphere - 6.3.2" $SolutionAndVersionTable += "VMware PowerCLI - 6.5.1" $SolutionAndVersionTable += "VMware Site Recovery Manager - 6.1.2" $SolutionAndVersionTable += "VMware Tools - 10.0.9" $SolutionAndVersionTable += "VMware vCenter Server - 6.0 U3" $SolutionAndVersionTable += "VMware vRealize Automation - 7.3.0" $SolutionAndVersionTable += "VMware vRealize Orchestrator - 7.3.0" $SolutionAndVersionTable += "VMware vSAN\u2122 - 6.2" $SolutionAndVersionTable += "VMware vSphere Hypervisor (ESXi) - 6.0 U3" $SolutionAndVersionTable += "VMware vSphere Replication - 6.1.2"
get-SolutionVersionInterCompatibility
get-SolutionVersionInterCompatibility -SolutionAndVersionTable $SolutionAndVersionTable #Result extract SolutionAndVersion1 SolutionAndVersion2 Compatibility CompatibilityDetails ------------------- ------------------- ------------- -------------------- VMware NSX for vSphere - 6.3.2 VMware Site Recovery Manager - 6.1.2 Compatible null VMware NSX for vSphere - 6.3.2 VMware Tools - 10.0.9 Compatible null VMware NSX for vSphere - 6.3.2 VMware vCenter Server - 6.0 U3 Compatible null VMware NSX for vSphere - 6.3.2 VMware vRealize Automation - 7.3.0 Compatible null VMware NSX for vSphere - 6.3.2 VMware vRealize Orchestrator - 7.3.0 Compatible null VMware NSX for vSphere - 6.3.2 VMware vSAN\u2122 - 6.2 Compatible null VMware NSX for vSphere - 6.3.2 VMware vSphere Hypervisor (ESXi) ... Compatible null VMware PowerCLI - 6.5.1 VMware Site Recovery Manager - 6.1.2 Not supported null VMware PowerCLI - 6.5.1 VMware vCenter Server - 6.0 U3 Compatible null VMware PowerCLI - 6.5.1 VMware vRealize Automation - 7.3.0 Not supported null VMware PowerCLI - 6.5.1 VMware vSAN\u2122 - 6.2 Compatible null VMware PowerCLI - 6.5.1 VMware vSphere Hypervisor (ESXi) ... Compatible null VMware Site Recovery Manage... VMware NSX for vSphere - 6.3.2 Compatible null VMware Site Recovery Manage... VMware PowerCLI - 6.5.1 Not supported null VMware Site Recovery Manage... VMware Tools - 10.0.9 Not supported null VMware Site Recovery Manage... VMware vCenter Server - 6.0 U3 Compatible null VMware Site Recovery Manage... VMware vRealize Automation - 7.3.0 Compatible Requires CloudCli... VMware Site Recovery Manage... VMware vRealize Orchestrator - 7.3.0 Not supported null VMware Site Recovery Manage... VMware vSAN\u2122 - 6.2 Compatible null VMware Site Recovery Manage... VMware vSphere Hypervisor (ESXi) ... Compatible null VMware Site Recovery Manage... VMware vSphere Replication - 6.1.2 Compatible null VMware Tools - 10.0.9 VMware NSX for vSphere - 6.3.2 Compatible null VMware Tools - 10.0.9 VMware Site Recovery Manager - 6.1.2 Not supported null VMware Tools - 10.0.9 VMware vCenter Server - 6.0 U3 Not supported null VMware Tools - 10.0.9 VMware vRealize Automation - 7.3.0 Not supported null VMware Tools - 10.0.9 VMware vSphere Hypervisor (ESXi) ... Compatible null get-SolutionVersionInterCompatibility -SolutionAndVersionTable $SolutionAndVersionTable | ogv
You have now a PowerShell table with all products tested against each other.
The “Compatibility” column match what you will find in the compatibility matrices.
“Compatible”
“Not supported”
“Incompatible”
In this example “SRM 6.1.2” is “not supported” with “Orchestrator 7.3”.
The “Compatibility details” is the little “Info” that you have on some “Compatible” products. (Slightly different icon in the website)
SRM 6.1.2 and Automation 7.3 is such a case, and the info is “Requires Cloud Client 4.3.0 or 4.4.0”
By design, each product version will be tested against all others…even if the compatibility check has also been done in the “reverse order”.
For example:
SRM 6.1.2 VS Automation 7.3
and later
Automation 7.3 VS SRM 6.1.2
It helps to identify quickly which products are “Not supported” with many others.
If you see a “Serie” of “Not supported”, then the associated product should be replaced by another version.
In this case, from the extract, the “VMware Tools” must be changed in priority.
Moreover, this is not visible on the table, but if two products do not have any single version compatible between them, they will be removed from the result.
There is no reason to check compatibility between products that are independent of each other.
The function has a switch to display them if you are curious.
(The value in the “Compatibility field” will be “Solution never compatible”)
How does it work?
An analysis of the code source of the webpage VMware Product Interoperability Matrices provides all information on how the webpage works.
In fact all the work is done on the “Client side”.
The “database” is in: data.php
It is a script language (Javascript/PHP ?) that create multidimensional array object.
High level steps
Step 1: Read the information from the website
Step 2: Convert this “unknown language” to PowerShell.
Step 3: Create PowerShell multidimensional array
Step 4: Convert these multidimensional “not friendly” objects in “friendly” single dimensional PowerShell array and/or Hashtable
Step 5: Magic to get a working result…read the comments in the code for more details.
Bugs in the compatibility matrices
This PowerShell script is totally dependent on the accuracy of the VMware compatibility matrices.
Actually some issues in the script are due to “bug” in the website.
Product and version associated to more that one index:
VMware ThinApp – 5.0.1
VMware Horizon Clients – 3.5.2
It is easy to see this bug from the website.
Example if you try:
Solution 1: VMware ThinApp > All versions
Solution 2: All Solutions
There will be two columns with the title “5.0.1”, and worst there are not compatibles with the same products.
The PowerShell function use “Product – Version” as a “Primary key”.
So this bug breaks it.
The functions can’t work with these two versions now.
Database not cleaned?
In the “array” containing all “compatible” match, there are the following Version Index.
398
923
But these “version index” are not in the “array” containing all “products version”…so it is impossible to know to which product and version they are associated.
I guess it is old data that have not been cleaned.
Bug in the PowerShell functions?
So far I have only tested the script with two versions of “data.php”
It was actually necessary to do minors modifications to make it work on the new version.
It is very likely that adjustments will be needed in the future.
If you have any issues with the script please let me know.
Update 2017_08_15: Bug fix
Due to new features in the VMware Product Interoperability Matrices, the script was not working anymore. (Tested with database version 2017-07-20-1205)
This bug is fixed now.
To discover the new feature, hover your mouse over the product version at the top or left of the product interoperability matrices.
It will give details about GA dates and in some cases “Download Pages” and “Release Notes”.