New VMware modules dropped

Support answered like this:

Yes this is intentional that the instances being discovered are different. While this module still has the same name as its previous versions, it is now setup to be alerting on only issues that would impact the new modules. While the new suite has a lot of similarities with the old one there are bit of under-the-hood improvements that I made and so we need a different set of checks.
 
The old alert for 'levels' was referring to the counter levels: https://vdc-download.vmware.com/vmwb-repository/dcr-public/b50dcbbf-051d-4204-a3e7-e1b618c1e384/538cf2ec-b34f-4bae-a332-3820ef9e7773/index.html
While updating the lmTroubleshooter I found that the check we were performing for levels was outdated and incorrectly configured for modern versions of vCenter, leading it to generate false positives whenever there were not actual issues with the levels. The counters monitored in the new modules should all work with a level of 1, which is the minimum level. Therefor we don't need to check if the level is a higher more verbose level.

Here’s my take on the new VMware modules (this is after talking to various people and pouring over the docs to understand what is actually happening). If this is correct, this is the kind of documentation I asked for earlier in this thread:

Problem

1. vSphere v8.x support

The current vSphere modules do not yet support v8.x of vSphere.

2. ESX Host Monitoring

There are two ways to monitor ESX hosts in LM. You might be doing one, the other, or both.

1. ESX hosts as instances
2. ESX hosts as resources

Method 1 is easy to maintain because datasource ActiveDiscovery maintains the list of ESX hosts as instances to monitor. However, the disadvantage is that the data collected isn’t as rich as Method 2 because of <reasons I don’t care to enumerate>.

Method 2 has much richer data because of <reasons I don’t care to enumerate>. However, maintaining the ESX hosts in LM becomes more problematic (unless you’re idempotently sync’ing from a SoR, which everybody should) since you have to manually maintain the list.

Solution

The new modules support v6.x through v8.x of vSphere. Problem #1 solved.

The new Netscan script overcomes the problem of keeping ESX resources current (problem #2) by doing what ActiveDiscovery did for instances, but adding the ESX hosts as resources instead of instances. At the same time, the Netscan script recreates the group structure from vSphere in LogicMonitor. You can use the NetScan to add the devices but not create the groups by <unknown how to do this if it’s even possible without modifying the script>.

Actions

If you are using Method 1 only you should:

1. If you are using this method, you have no ESX hosts as resources, so the new DSs will not apply to anything. You can safely import the new DSs without any impact.
2. If you do not want to monitor ESX hosts directly, you are done. Otherwise...
3. Modify the DS thresholds/filters to match any existing customizations you’ve made.
4. Figure out if you want to use the Netscan to add the ESX hosts as resources (with or without group creation) or if you want to manually add them to LM as resources. Either configure the Netscan to run or add the ESX hosts manually.
5. Verify the new DSs are collecting data for the newly added ESX hosts.
6. Disable DS name1, name2, and name3 (the modules currently used to monitor ESX hosts as instances under vSphere/vCenter) by going to each instance and disabling them. (You could do this in bulk by eating a giant red flower and shooting fireballs at LM. Oh right, you can’t do this in bulk in LM.)

If you are using Method 2 only you should:

1. If you are using this method, you have already disabled DS name1, name2, and name3 (the modules currently used to monitor ESX hosts as instances under vSphere/vCenter).
2. Set SDT on all your ESX hosts so that you can import the DSs without causing false positive alerts to open before you have a chance to modify the thresholds to match any customization you’ve put in place.
3. Import the new DSs.
4. Modify the DS thresholds to match any existing alert customizations you’ve made.
5. Figure out if you want to use the Netscan to replace your current method of keeping the ESX resource list current. If you do, start running it (with or without group creation).
6. Verify the new DSs have data for your ESX hosts and end SDT.

If you are using both Method 1 and Method 2 you should:

1. If you are using this method, you have ESX hosts as resources that will be impacted by importing the new DSs. Set SDT on all your ESX hosts so that you can import the DSs without causing false positive alerts to open before you have a chance to modify the thresholds to match any customization you’ve put in place.
2. Figure out if you want to use the Netscan to replace your current method of keeping the ESX resource list current. If you do, start running it (with or without group creation).
3. Import the new DSs.
4. Modify the DS thresholds to match any existing alert customizations you’ve made.
5. Verify the new DSs have data for you ESX hosts.
6. Disable DS name1, name2, and name3 (the modules currently used to monitor ESX hosts as instances under vSphere/vCenter) by going to each instance and disabling them. (You could do this in bulk by eating a giant red flower and shooting fireballs at LM. Oh right, you can’t do this in bulk in LM.)

I would love to hear from LM if this is the right path forward.