Skip to main content

Hello everyone,
 

As part of our project to update our dedicated VMware connectors, we are deploying the foundation of the VMware 8 ESX monitoring connector via REST API this month. This connector is a lightweight version, as it only includes CPU, memory, power and host discovery modes. We have already planned to enhance this connector in the coming months with new modes. It is marked as experimental because, at this stage, we still need to verify its functionality with numerous metrics (as may be the case in certain production environments). Feel free to share your feedback on this and more generally on this connector here. We will keep you informed of progress on this subject.

 

I am monitoring my VMWare 8 VCenters and ESXi (CPU, health, memory, network, status,swap, VMCount) with “usual Centreon plugin”, and it’s working well.

Is there any limitation?


I am monitoring my VMWare 8 VCenters and ESXi (CPU, health, memory, network, status,swap, VMCount) with “usual Centreon plugin”, and it’s working well.

Is there any limitation?

Hi, the usual Centreon plugins use the centreon_vmware daemon, which relies the Perl VMware SDK which is not maintained anymore. It works with vSphere’s SOAP API and its latest version is guaranteed for vSphere 7 or prior.

vSphere 8 provides a new REST API we intend to use for our new plugins.

 


I am monitoring my VMWare 8 VCenters and ESXi (CPU, health, memory, network, status,swap, VMCount) with “usual Centreon plugin”, and it’s working well.

Is there any limitation?

Hi, the usual Centreon plugins use the centreon_vmware daemon, which relies the Perl VMware SDK which is not maintained anymore. It works with vSphere’s SOAP API and its latest version is guaranteed for vSphere 7 or prior.

vSphere 8 provides a new REST API we intend to use for our new plugins.

 

But I see that the old sdk based plugin (centreon_vmware.pm) still works with vcenter 8 environment. Although I have SOAP errors in the logs

$ sudo tail -f /var/log/centreon/centreon_vmware.log 

<2025-03-28 09:09:40] 8error] 'drc' SOAP request error - possibly a protocol issue: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 397.
e2025-03-28 09:09:40] 8error] 'drc' SOAP request error - possibly a protocol issue: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 397.
e2025-03-28 09:09:41] 8error] 'pdc' SOAP request error - possibly a protocol issue: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 397.

 


But I see that the old sdk based plugin (centreon_vmware.pm) still works with vcenter 8 environment. Although I have SOAP errors in the logs

$ sudo tail -f /var/log/centreon/centreon_vmware.log 

[2025-03-28 09:09:40] [error] 'drc' SOAP request error - possibly a protocol issue: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 397.
[2025-03-28 09:09:40] [error] 'drc' SOAP request error - possibly a protocol issue: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 397.
[2025-03-28 09:09:41] [error] 'pdc' SOAP request error - possibly a protocol issue: Server closed connection without sending any data back at /usr/share/perl5/Net/HTTP/Methods.pm line 397.

Hi ​@centreon_s,

Indeed, the legacy SDK still appears to be at least partially working with vSphere 8. But since it is not maintained anymore, there is no warranty it will remain compatible, so we have to move forward and develop new plugins that use the REST API.

 


Hi,

 

Just testing this out against our vCenter v8 environment, and I get this for all the sensors:

UNKNOWN: compose_type_from_rsrc_id: cannot extract type from '10.125.214.9'

Yes, the host is actually called “10.125.214.9”, it’s historical but not much we can do about it.

At first it didn’t work because it was trying to use the system proxy, and we hadn’t added the vCenter to the proxy exclusion list. Perhaps add a

--no-proxy

option just to avoid this without needing to make system changes.

I really hope this new connector, and all the VMware ones, get quick traction, because we have so many issues with the older ones, especially with annoyances like 

UNKNOWN: Cannot get value for counters (Maybe, object(s) cannot be reached: disconnected, not running, time not synced (see time-host mode) check option --time-shift and ensure this specific metric is retrieved and not late in the vcenter)

when none of that is relevant and other similar on the same host have no issues.

BTW, I hope you noticed the vCenter v9 is now out and I’m sure all the other v9 parts like ESXi won’t be far behind. Broadcom seem to be pushing a lot of changes at the moment and you need to keep up. We won’t be looking at v9 before at least this September.


Hi,

This is a general remark: it is a lot easier to provide help on plugins when the exact command (without the sensitive data such as logins and passwords of course) is provided in the message. And it’s even better with the output of the --debug option. 🙏🏻

Now, if I try to guess, I suppose you’ve been using this option --esx-id=10.125.214.9?

If so, try using --esx-name=10.125.214.9 instead.


@omercier sorry about that, but hopefully this will help. My original command was using both --esx-id and --esx-name not sure why, so from the command line I tested each separately, this was the results:

ocentreon-engine@SERVER003 ~]$ /usr/lib/centreon/plugins//centreon_vmware8_esx_restapi.pl --plugin=apps::vmware::vsphere8::esx::plugin --mode=power --hostname='SERVERAVDIPV001' --port='443' --proto='https' --esx-id='10.125.214.9' --username='<redacted>@vsphere.local' --password='<redacted>' --verbose --warning-usage-watts='' --critical-usage-watts='' --debug
UNKNOWN: compose_type_from_rsrc_id: cannot extract type from '10.125.214.9'
== Info: Uses proxy env variable no_proxy == '10.*.*.*, .mydomain.com, serveravdipv001, serveravdipv002, SERVER003, SERVER004, SERVER005, SERVER007, SERVER008, SERVER009, SERVER010, SERVER011, SERVER012, SERVER013'
== Info: Trying 10.125.214.10...
== Info: TCP_NODELAY set
== Info: Connected to SERVERAVDIPV001 (10.125.214.10) port 443 (#0)
== Info: ALPN, offering http/1.1
== Info: successfully set certificate verify locations:
== Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
== Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
== Info: TLSv1.2 (IN), TLS handshake, Certificate (11):
== Info: TLSv1.2 (IN), TLS handshake, Server key exchange (12):
== Info: TLSv1.2 (IN), TLS handshake, Server finished (14):
== Info: TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
== Info: TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
== Info: TLSv1.2 (OUT), TLS handshake, Finished (20):
== Info: TLSv1.2 (IN), TLS handshake, Finished (20):
== Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
== Info: ALPN, server accepted to use http/1.1
== Info: Server certificate:
== Info: subject: C=LU; ST=Luxembourg; L=Luxembourg; O=My Comapany=IT; CN=SERVERAVDIPV001.mydomain.com
== Info: start date: Apr 22 08:03:42 2025 GMT
== Info: expire date: Apr 22 08:03:42 2026 GMT
== Info: issuer: DC=com; DC=mydomain; CN=My Company SHA2 Level 3 CA 7
== Info: SSL certificate verify ok.
=> Send header: GET /api/stats/acq-specs HTTP/1.1
Host: SERVERAVDIPV001
Accept: */*
vmware-api-session-id: 0d41334461e33e94304ac1b6bbc41cfa

=> Recv header: HTTP/1.1 200 OK
=> Recv header: date: Fri, 27 Jun 2025 07:31:23 GMT
=> Recv header: content-type: application/json
=> Recv header: x-envoy-upstream-service-time: 5
=> Recv header: vary: Accept-Encoding
=> Recv header: transfer-encoding: chunked
=> Recv header:
=> Recv data: 100
{"acq_specs":c{"counters":{"cid_mid":{"mid":"","cid":"*"},"set_id":""},"resources":e{"predicate":"EQUAL","scheme":"name","type":"OBS","id_value":"OBS"}],"expiration":10000000000,"interval":30,"memo_":"SupportBundle_Acqspec","id":"109","status":"ENABLED"}]}
0

== Info: Connection #0 to host SERVERAVDIPV001 left intact
ocentreon-engine@SERVER003 ~]$ /usr/lib/centreon/plugins//centreon_vmware8_esx_restapi.pl --plugin=apps::vmware::vsphere8::esx::plugin --mode=power --hostname='SERVERAVDIPV001' --port='443' --proto='https' --esx-name='10.125.214.9' --username='centreon@vsphere.local' --password='<redacted>' --verbose --warning-usage-watts='' --critical-usage-watts='' --debug
UNKNOWN: API returns error of type UNAUTHORIZED: EId: vapi.security.authorization.permission.denied - Msg: Permission to perform this operation was denied ()]
== Info: Uses proxy env variable no_proxy == '10.*.*.*, .mydomain.com, serveravdipv001, serveravdipv002, SERVER003, SERVER004, SERVER005, SERVER007, SERVER008, SERVER009, SERVER010, SERVER011, SERVER012, SERVER013'
== Info: Trying 10.125.214.10...
== Info: TCP_NODELAY set
== Info: Connected to SERVERAVDIPV001 (10.125.214.10) port 443 (#0)
== Info: ALPN, offering http/1.1
== Info: successfully set certificate verify locations:
== Info: CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
== Info: TLSv1.3 (IN), TLS handshake, Server hello (2):
== Info: TLSv1.2 (IN), TLS handshake, Certificate (11):
== Info: TLSv1.2 (IN), TLS handshake, Server key exchange (12):
== Info: TLSv1.2 (IN), TLS handshake, Server finished (14):
== Info: TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
== Info: TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
== Info: TLSv1.2 (OUT), TLS handshake, Finished (20):
== Info: TLSv1.2 (IN), TLS handshake, Finished (20):
== Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
== Info: ALPN, server accepted to use http/1.1
== Info: Server certificate:
== Info: subject: C=LU; ST=Luxembourg; L=Luxembourg; O=My Company; OU=IT; CN=SERVERAVDIPV001.mydomain.com
== Info: start date: Apr 22 08:03:42 2025 GMT
== Info: expire date: Apr 22 08:03:42 2026 GMT
== Info: issuer: DC=com; DC=mydomain; CN=My Company SHA2 Level 3 CA 7
== Info: SSL certificate verify ok.
=> Send header: GET /api/vcenter/host HTTP/1.1
Host: SERVERAVDIPV001
Accept: */*
vmware-api-session-id: 0d41334461e33e94304ac1b6bbc41cfa

=> Recv header: HTTP/1.1 200 OK
=> Recv header: date: Fri, 27 Jun 2025 07:36:29 GMT
=> Recv header: content-type: application/json
=> Recv header: x-envoy-upstream-service-time: 11
=> Recv header: vary: Accept-Encoding
=> Recv header: transfer-encoding: chunked
=> Recv header:
=> Recv data: 528
r{"host":"host-10","name":"10.125.214.9","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4366221","name":"serverehyppp004.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4366225","name":"serverehyppp005.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4366245","name":"serverehyppp002.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4366266","name":"serverehyppp001.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4374177","name":"serverehyppp006.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4374181","name":"serverehyppp007.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4382133","name":"serverehyppp008.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4382137","name":"serverehyppp009.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4382141","name":"serverehyppp012.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"},{"host":"host-4382145","name":"serverehyppp013.mydomain.com","connection_state":"CONNECTED","power_state":"POWERED_ON"}]
0

== Info: Connection #0 to host SERVERAVDIPV001 left intact
get_esx_id_from_name method called to get 10.125.214.9's id: host-10. Prefer using --esx-id to spare a query to the API.
== Info: Uses proxy env variable no_proxy == '10.*.*.*, .mydomain.com, serveravdipv001, serveravdipv002, SERVER003, SERVER004, SERVER005, SERVER007, SERVER008, SERVER009, SERVER010, SERVER011, SERVER012, SERVER013'
== Info: Found bundle for host SERVERAVDIPV001: 0x560059bf8790 7can pipeline]
== Info: Re-using existing connection! (#0) with host SERVERAVDIPV001
== Info: Connected to SERVERAVDIPV001 (10.125.214.10) port 443 (#0)
=> Send header: GET /api/stats/acq-specs HTTP/1.1
Host: SERVERAVDIPV001
Accept: */*
vmware-api-session-id: 0d41334461e33e94304ac1b6bbc41cfa

I checked into the permission denied, and I could only find this mentioned in the vCenter logging

Privilege check failed for user VSPHERE.LOCAL\centreon for missing permission Global.Licenses. Session user performing the check: VSPHERE.LOCAL\centreon

Now although I could give the account the role “Licenses”, I can’t because according to the Broadcom documentation for Global Licenses:

Allows viewing installed licenses and adding or removing licenses.

“adding or removing”, no, no it’s not getting that access, sorry.

The account has no other issues accessing vCenter or the ESXi hosts for information, otherwise our production Centreon server would be screaming at me. When I do try with my own administrator account, I get the same for --esx-id, but for --esx-name:

OK: usage-watts : skipped (no value(s)) - no data for host host-10 counter power.capacity.usage.HOST at the moment.
get_esx_id_from_name method called to get 10.125.214.9's id: host-10. Prefer using --esx-id to spare a query to the API.

Let me know if you need anything else


I don’t think the Licenses privilege is needed here, but have you complied with the prerequisites listed here?


I don’t think the Licenses privilege is needed here

So you’ll remove that for the next release?

but have you complied with the prerequisites listed here?

Yes, the account at the top level of vCenter has the role “vStatsUser” and is defined “This object and its children

vSphere Stats Privileges:

Collect Stats Data
Query Stats Data

I need to create a custom role as this also includes:

vSphere Tagging

Assign or Unassign vSphere Tag on Object

Which I need to remove, but it’s not critical for the moment


I don’t think the Licenses privilege is needed here

So you’ll remove that for the next release?

Hi, this message comes from the API itself. We’re not responsible for it.

 

but have you complied with the prerequisites listed here?

Yes, the account at the top level of vCenter has the role “vStatsUser” and is defined “This object and its children

vSphere Stats Privileges:

Collect Stats Data
Query Stats Data

I need to create a custom role as this also includes:

vSphere Tagging

Assign or Unassign vSphere Tag on Object

Which I need to remove, but it’s not critical for the moment

Does the command work now?


Reply