Question

VMware ESX host (no vSphere/vCenter) auth problem

  • 8 February 2024
  • 21 replies
  • 112 views

Userlevel 4
Badge +5

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


21 replies

Userlevel 4
Badge +5

Title meant to say “Not vSphere/vCenter”

Userlevel 3
Badge +1

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

Userlevel 4
Badge +5

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

Userlevel 4
Badge +5

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.

Userlevel 6
Badge +11

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.

Userlevel 4
Badge +5

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

Userlevel 4
Badge +5

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.

Userlevel 4
Badge +5

 

Userlevel 4
Badge +5

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.

Userlevel 4
Badge +5

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")
 

Userlevel 7
Badge +20

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.

Userlevel 6
Badge +11

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 :)

Userlevel 4
Badge +5

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.

Userlevel 4
Badge +5

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!

Userlevel 6
Badge +11

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

 

Userlevel 4
Badge +5

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.

Userlevel 6
Badge +11

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.

Userlevel 6
Badge +13

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.

Userlevel 7
Badge +20

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.

Userlevel 4
Badge +5

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.

Userlevel 7
Badge +20

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

Reply