Did anybody else notice the ~44 new and ~5 updated modules around VMware dropping in the last hour or so? Does anyone know how to implement these new modules? Since there was talk of making the instances into resources I don’t want to just bring them in without knowing how it’s going to mess with my device list (which is tightly bound to billing for us).

That would be interesting… one of our pain points at the moment is putting vSphere hosts into SDT. We don’t actually monitor the hosts as such at the moment, just through the vCenter, so the vCenter is the only resource. As I understand it, if our operations team wants to SDT a host, we’d have to do it under each datasource it appears in under it’s parent vCenter. If hosts and datastores etc show up a devices that can be separately SDT’d then that’d be great. Likewise, we’re setting up a separate LM instance to do stuff like this in! Dave To accomplish this with the new modules and onboarding process, you can have the Enhanced Script NetScan add your desired vSphere Clusters (ESXi hosts) as Resources and disable the following DataSources:VMware_vCenter_HostPerformanceVMware_vCenter_HostVSwitchVMware_vCenter_HostInterfacesAfter doing this, you can selectively SDT by DataCenter, Cluster, Resource Pool, or individual ESXi host.

Below are some highlights about the new VMware vSphere modules.

https://www.logicmonitor.com/support/vmware-vsphere-monitoring

Did anybody else notice the ~44 new and ~5 updated modules around VMware dropping in the last hour or so? Does anyone know how to implement these new modules? Since there was talk of making the instances into resources I don’t want to just bring them in without knowing how it’s going to mess with my device list (which is tightly bound to billing for us). Hi, @Stuart Weenig. Migrating to the new modules will not convert instances into Resources. However, the Enhanced Script NetScan filters make it easy to add the ESXi hosts and Mission Critical VMs you want to monitor as Resources. You can setup filters that mirror your business logic and schedule the NetScan to query vCenter on (as frequent as) an hourly basis to add the exact resources you want, so what you deem to need monitoring gets monitored automatically.

We’re part the way through onboarding a load of internal and customer VMware platform platforms into LM, so interested in this as well. I’d be interested to understand the reason for releasing new modules over updating the existing? The commit history for the brand new ones mentioned ‘optimized for vSphere 8’ but the AppliesTo doesn’t seem to limit them to vSphere 8 vCenters/hosts, so loathed to import them just yet as I expect we’ll have a lot of duplication in data collection and alerts if we did. Dave Hi, @Dave Lee. Because the new VMware_vSphere* and VMware_vCenterAppliance* modules communicate with vCenter (via API), we recommend following your change control process for migrations rather than running the previous and new modules in parallel (which could put an unnecessary burden on vCenter).To maintain historical data, make sure to disable previous datasources rather than changing the AppliesTo or deleting them.

New VMware modules dropped | LogicMonitor

Anonymous
2 years ago

I imported the VMware troubleshooter under a different name and ran them side by side for a few days. There is one instance discovered under the old module that isn’t discovered under the new module: Incorrect Statistics Level.

Is this because the new modules don’t care about the statistics level? Or does the new troubleshooter not check for that particular error (i.e. it doesn’t have feature parity with the module it’s replacing)?
Cole_McDonald
Professor
2 years ago
DO NOT USE THESE YET… I’m dropping a support ticket in with the issues we saw when we turned them on… purestorage array utilization tripled instantly on import!
Specifically the VMWare ESXi * set of them… not sure if it was one or multiple/cumulative yet.
Anonymous
2 years ago
Let me illustrate the complexity of integrating these updates with existing stuff:
I have to have the exchange (not the module toolbox?) pulled up to know if a module is new or existing (could have just been signaled in the docs).

I have to have the documentation pulled up to know which modules replace which modules.

I have to have the module toolbox pulled up so I can pull in the changes.

I have to search through all my groups for custom thresholds that I have to recreate on the new modules, but I can’t do that until they’re imported. And searching for custom thresholds is made more complicated by the fact that on the alert tuning tab they are displayed by display name, not name. The documentation uses name (rightly so), so knowing which one is which requires me to also look up the module in the repo/toolbox. I can run a report, but those have become less and less reliable with the new schedule-now bug.

I also have to identify all the customizations that we’ve done to the existing modules and apply those to the new modules, which I can’t do until I’ve already pulled the new modules into prod, by which time, they’re already alerting with non-custom alert thresholds, trigger/clear interval settings, discovery customizations, etc..
Forgive me for being a little salty, but this isn’t something that we can just import and see how it goes. The existing modules weren’t tuned for reality/usability, so we had to make significant modifications to get them to work well in a real environment.
Patrick_Rouse
Product Manager
2 years ago

Let me illustrate the complexity of integrating these updates with existing stuff:

I have to have the exchange (not the module toolbox?) pulled up to know if a module is new or existing (could have just been signaled in the docs).

I have to have the documentation pulled up to know which modules replace which modules.

I have to have the module toolbox pulled up so I can pull in the changes.

I have to search through all my groups for custom thresholds that I have to recreate on the new modules, but I can’t do that until they’re imported. And searching for custom thresholds is made more complicated by the fact that on the alert tuning tab they are displayed by display name, not name. The documentation uses name (rightly so), so knowing which one is which requires me to also look up the module in the repo/toolbox. I can run a report, but those have become less and less reliable with the new schedule-now bug.

I also have to identify all the customizations that we’ve done to the existing modules and apply those to the new modules, which I can’t do until I’ve already pulled the new modules into prod, by which time, they’re already alerting with non-custom alert thresholds, trigger/clear interval settings, discovery customizations, etc..

Forgive me for being a little salty, but this isn’t something that we can just import and see how it goes. The existing modules weren’t tuned for reality/usability, so we had to make significant modifications to get them to work well in a real environment.

Hi, @Stuart Weenig. This is great feedback that we can use to improve our product documentation and in-product (LM Exchange/Toolbox).

Your words “this isn’t something that we can just import and see how it goes” are very important for others to read. If IT personnel don’t have a formal change control process (ITIL or otherwise) and follow the “install it and see how it goes” in a stable production environment, they are taking unnecessary risk that at some point with some product is going to have unintended consequences. Change Control is critically important.

Thanks again.
Anonymous
2 years ago
No, that’s not really the best answer and didn’t answer my question.
Joe_Williams
Professor
2 years ago
Coming from a MSP as well, I agree with Stuart. Is the future plan to deprecate the current modules? And move to a non instance based one? If so that impacts us on our license counts, billing to clients, etc….
Patrick_Rouse
Product Manager
2 years ago

if you have some logic in vCenters that determine what should be monitored as a resource, i.e. tags, naming conventions

As an MSP, we never have that luxury. For the same reason, we can’t use LM’s fancy interface alert filtering.

you don’t have to have a manual process to do this

I don’t have a manual process to do this. It’s sync’d in from our billing system of record.

Any chance you’re going to put out documentation on how to utilize the new datasources without using the netscan? If I import these today, will they start monitoring since I already have things like esx/vcenter/vsphere credentials already added as properties? What’s the migration process for existing customers? Will there be/is there part of this update a property source that will pull the tags so we can still do dynamic grouping based on tags?

From the new product docs → https://www.logicmonitor.com/support/vmware-vsphere-monitoring
Patrick_Rouse
Product Manager
2 years ago
The PropertySource:
Patrick_Rouse
Product Manager
2 years ago
The new dashboard are here:

https://github.com/logicmonitor/dashboards/tree/master/Virtualization/VMware%20(Current)

Thanks @Kerry DeVilbiss
Patrick_Rouse
Product Manager
2 years ago

Coming from a MSP as well, I agree with Stuart. Is the future plan to deprecate the current modules? And move to a non instance based one? If so that impacts us on our license counts, billing to clients, etc….

Which current modules? Thanks