VMware ESX host (no vSphere/vCenter) auth problem | Product Discussions

ldoodle · 2024-02-08T18:46:23Z

Hi,In vSphere I have added a local account (Read-only) for LM to poll it. This works fine.However when trying to add an actual ESX host I get access denied. In vSphere for each host, I can see that the local account I created has propagated down just fine, so what else can be the cause?When the Add Device Wizard fails, if I manually specify the creds it still fails, but I can manually specify the ESX host built-in root account and it works fine. So do we need to additionally have a local user account on each ESX host, and that the vSphere inherited perms don’t work for LM?Thanks

LM User

·2 years ago

The git repo is official from LM, but i don’t know the “supported” status of it.

ldoodle

OP2 years ago

I’m not aware of any kinda versioning or updating system for dashboards

Is the Git repo official LM, and just another source to grab them from? Because that at least has a ‘Last commit’ date?

Or is Git community driven also?

We don’t even clone them by default

Yeah the more I’m starting to build out the dash’s the more I’m starting to avoid that too.

LM User

·2 years ago

One option is setting up a template dashboard group with various standard dashboards you want, for each customer with some customer-based tokens. When you onboard new customers just clone the whole group.

This is what we do too. The only difference is that we do it via the api, but Mike may be doing that too.

Joe Williams

·2 years ago

I’m not aware of any kinda versioning or updating system for dashboards. You can import/export dashboards via json but I believe some widgets can’t be exported fully. Atleast for me, while I might first start with a built-in or github dashboard, I’ve heavily modified them for our needs. Luckily it’s easy to clone/move widgets between dashboards so I might import a new github dashboard and clone over the widgets I want, into what I’ve already have.

One option is setting up a template dashboard group with various standard dashboards you want, for each customer with some customer-based tokens. When you onboard new customers just clone the whole group. You can then focus mostly on keeping the template up-to-date and “upgrade” existing customers by replacing the old ones with the newer template ones. You still need to deal with any per-customer customization that have been made. But that is the case with a lot of things and hopefully you don’t need to do that too much.

We don’t even clone them by default. Since we standardize our folder structures and have dynamic rollup folders, we simply have a curated dashboards area. They are pointing to */ZZZ_Firewalls_PaloAlto/* for example for a Palo Alto dashboard. The clients’s roles are restricted to their devices, so it just works. We also give them their own folder where they can make their own, or clone out one of our curated dashboards.

Mike Moniz

·2 years ago

I’m not aware of any kinda versioning or updating system for dashboards. You can import/export dashboards via json but I believe some widgets can’t be exported fully. Atleast for me, while I might first start with a built-in or github dashboard, I’ve heavily modified them for our needs. Luckily it’s easy to clone/move widgets between dashboards so I might import a new github dashboard and clone over the widgets I want, into what I’ve already have.

One option is setting up a template dashboard group with various standard dashboards you want, for each customer with some customer-based tokens. When you onboard new customers just clone the whole group. You can then focus mostly on keeping the template up-to-date and “upgrade” existing customers by replacing the old ones with the newer template ones. You still need to deal with any per-customer customization that have been made. But that is the case with a lot of things and hopefully you don’t need to do that too much.

ldoodle

OP2 years ago

Brilliant, thank you.

I was looking for a way to import/update the built-in dashboards like you can with DataSources.

Is there an easy way to check the versions between what I have and what’s available on that link? Or is it a case of grabbing the ones I need now and just deleting the existing and replacing with hopefully a new one.

Mike Moniz

·2 years ago

Not sure how up-to-date these are, but LM has a repo of dashboards, there might be an updated one:

ldoodle

OP2 years ago

P.S. Welcome to the fun of DataSource upgrades :)

Oh wow do I know now. A couple of widgets have lost their data now so I have to rejig them!

ldoodle

OP2 years ago

def user = hostProps.get('vcenter.user') ?: hostProps.get("vcsa.user") ?: hostProps.get("esx.user")

This simply means use vcenter.user if it exists, If not, use vcsa.user if it exists. If not, use esx.user.

yeah I realise that. I’m used to other programming languages from my day job.

Mike Moniz

·2 years ago

VMware_vCenter_VMInterface is deprecated, so you may have old DSes that have been replaced with newer ones. See https://www.logicmonitor.com/support/logicmodules/about-logicmodules/deprecated-logicmodules

P.S. Welcome to the fun of DataSource upgrades :)

LM User

·2 years ago

def user = hostProps.get('vcenter.user') ?: hostProps.get("vcsa.user") ?: hostProps.get("esx.user")

This simply means use vcenter.user if it exists, If not, use vcsa.user if it exists. If not, use esx.user.

ldoodle

OP2 years ago

If I spot check some of the VMware DataSources…

some are like this:

Example: VMware_vCenter_VMInterface

def user = hostProps.get("esx.user")
def pass = hostProps.get("esx.pass")

others are like this:

Example: VMware_vCenterAppliance_Power

def user = hostProps.get('vcenter.user') ?: hostProps.get("vcsa.user") ?: hostProps.get("esx.user")
def pass = hostProps.get('vcenter.pass') ?: hostProps.get("vcsa.pass") ?: hostProps.get("esx.pass")

ldoodle

OP2 years ago

Taking a quick peak at a sampling the latest vmware datasource code in Exchange. It looks like:

VMware_ESXi_* looks at esx only
VMware_vSphere looks at vcenter first, then vcsa, then esx
VMware_vCenterAppliance_* looks at vcsa first, then vcenter, then esx
VMware_vCenter_* looks at vcenter first, then vcsa, then esx

I didn’t really test these, but I would make sure you have the latest Vmware PropertySources and DataSources.

Had a deeper dig in to the docs at VMware vSphere Monitoring | LogicMonitor:

vCenter Server Appliance Host Properties

Property	Value	Required
vcenter.user	vCenter read-only user	Yes
vcenter.pass	vCenter read-only password	Yes

Note: For backwards compatibility with older generations of vCenter modules, if the credentials are not set, the follwoing vCenter User Properties are used. However, it is recommended to use the preceding vCenter Server Appliance Host Properties vcenter prefix when configuring devices.

vCenter User Properties

Property	Value
vcsa.user	vCenter read-only user
vcsa.pass	vCenter read-only password
esx.user	vCenter read-only user
esx.pass	vCenter read-only password

Neither vcenter.* or vcsa.* seem to work work for me when esx.* is also present (unless as above I override esx.user directly on the resource). If I remove esx.* and leave just vcenter.* (or vcsa.*) at the parent for inheritence, vCenter works but ESX host do not.

ldoodle

OP2 years ago

ldoodle

OP2 years ago

I worked around it by overriding just esx.user property directly on the vCenter resource and that made it work (with an inherited esx.pass property).

I also just updated/installed any VMware DataSources then removed the esx.user property directly on vCenter resource, and within a couple of minutes vCenter dashboard is back to NaN.

So esx.user must not be just for ESX hosts.

ldoodle

OP2 years ago

should I be using VMware_ prefix or is that just for documentation purposes only?

Mike Moniz

·2 years ago

Taking a quick peak at a sampling the latest vmware datasource code in Exchange. It looks like:

VMware_ESXi_* looks at esx only
VMware_vSphere looks at vcenter first, then vcsa, then esx
VMware_vCenterAppliance_* looks at vcsa first, then vcenter, then esx
VMware_vCenter_* looks at vcenter first, then vcsa, then esx

I didn’t really test these, but I would make sure you have the latest Vmware PropertySources and DataSources.

ldoodle

OP2 years ago

I’m having a bit of trouble with this one;

In vCenter we have a read-only account, let’s say ‘LMMonitor@vsphere.local’
In ESX hosts we have a read-only account, let’s say ‘LMMonitor’ (no @vsphere.local suffix)

LM is getting confused by which account to use for each resource type. As for properties we have:

esx.user / esx.pass
vcenter.user / vcenter.pass / vcenter.hostname

However, LM appears to prefer esx.* properties and ignores vcenter.* ones. I’m seeing this behaviour:

when esx.user is set to ‘LMMonitor’, ESX host dashboards show properly, but vCenter dashboards show NaN for most things
when esx.user is set to ‘LMMonitor@vsphere.local’, ESX host dashboards now show NaN, but vCenter dashboards show properly

This is despite having vcenter.* properties in addition, e.g. this combo works okay for ESX dashboards but not for vCenter dashboards

esx.user = ‘LMMonitor’
vcenter.user = ‘LMMonitor@vsphere.local’

and this combo works okay for vCenter dashboards but not for ESX dashboards

esx.user = ‘LMMonitor@vsphere.local’
vcenter.user = ‘LMMonitor@vsphere.local’

These properties are set at the resources parent group level.

ldoodle

OP2 years ago

OK, thanks. I’ll give that a go.

Justin Lanoue

·2 years ago

I’ve only gotten it to work by adding a read-only user within the ESX Host directly.

ldoodle

OP2 years ago

Title meant to say “Not vSphere/vCenter”