Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to get Datastore info for vsan #25

Open
woutervb opened this issue Apr 13, 2016 · 3 comments
Open

Unable to get Datastore info for vsan #25

woutervb opened this issue Apr 13, 2016 · 3 comments

Comments

@woutervb
Copy link

Getting the release 2.0 up and running was quite trivial on a centos 7 machine.

The issue I am now facing is that the datastore(s) cannot be monitored. It might be an vsan specific thing, but I have the following symptoms.

zabbix_get -s 127.0.0.1 -p 12050 -k datastore.discovery[*]
zabbix_get [19651]: Timeout while executing operation

And in the logging I see the following passing by:

Apr 13 11:56:27 cz01 vmbixd: 11:56:27.403 [Thread-2] INFO net.dav3860.VmBix - thread created, collecting data in 1 threads
Apr 13 11:56:29 cz01 vmbixd: 11:56:29.451 [Thread-2] INFO net.dav3860.VmBix - thread  closed, collecting data in 0 threads
Apr 13 11:56:38 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 11:56:42 cz01 vmbixd: 11:56:42.555 [Thread-3] INFO net.dav3860.VmBix - thread created, collecting data in 1 threads
Apr 13 11:56:45 cz01 vmbixd: 11:56:45.254 [Thread-3] INFO net.dav3860.VmBix - thread  closed, collecting data in 0 threads
Apr 13 11:57:08 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 11:57:17 cz01 vmbixd: 11:57:17.657 [Thread-4] INFO net.dav3860.VmBix - thread created, collecting data in 1 threads
Apr 13 11:57:17 cz01 vmbixd: Exception in thread "Thread-4" java.lang.ClassCastException: com.vmware.vim25.DatastoreInfo cannot be cast to com.vmware.vim25.VmfsDatastoreInfo
Apr 13 11:57:17 cz01 vmbixd:    at net.dav3860.VmBix$Connection.getDatastores(VmBix.java:1673)
Apr 13 11:57:17 cz01 vmbixd:    at net.dav3860.VmBix$Connection.checkAllPatterns(VmBix.java:716)
Apr 13 11:57:17 cz01 vmbixd:    at net.dav3860.VmBix$Connection.run(VmBix.java:3219)
Apr 13 11:57:38 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 11:58:08 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 11:58:38 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 11:59:08 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 11:59:38 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 12:00:08 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.
Apr 13 12:00:38 cz01 vmsvc[14646]: [ warning] [guestinfo] Failed to get disk info.

Any ideas what is going on, the account that I use for monitoring has read-only access

@dav3860
Copy link
Owner

dav3860 commented Apr 15, 2016

I don't use VSANs so I haven't been able to test. I think that this kind of datastore is seen as a local datastore by the API. The following patch should fix it.

Starting at line 1654, you need to replace this :
if (d != null) { //Correction by Andrea for trap the NasDatastoreInfo if (d.getInfo() instanceof NasDatastoreInfo) { NasDatastoreInfo dsInfo = (NasDatastoreInfo) d.getInfo(); if ( dsInfo != null ) { HostNasVolume naaName = dsInfo.getNas(); JsonObject jObject = new JsonObject(); jObject.addProperty("{#DATASTORE}", d.getName()); //jObject.addProperty("{#UUID}", uuid); jObject.addProperty("{#UUID}", "N/A"); jObject.addProperty("{#CLUSTER}", d.getParent().getName()); jObject.addProperty("{#LOCAL}", !d.getSummary().multipleHostAccess); jObject.addProperty("{#NAA}", naaName.getName()); jArray.add(jObject); } } else { VmfsDatastoreInfo dsInfo = (VmfsDatastoreInfo) d.getInfo(); if ( dsInfo != null ) { HostScsiDiskPartition[] naaName = dsInfo.getVmfs().extent; JsonObject jObject = new JsonObject(); jObject.addProperty("{#DATASTORE}", d.getName()); //jObject.addProperty("{#UUID}", uuid); jObject.addProperty("{#UUID}", dsInfo.getVmfs().getUuid()); jObject.addProperty("{#CLUSTER}", d.getParent().getName()); jObject.addProperty("{#LOCAL}", !d.getSummary().multipleHostAccess); jObject.addProperty("{#NAA}", naaName[0].getDiskName()); jArray.add(jObject); } } }

by this:
if (d != null) { //Correction by Andrea for trap the NasDatastoreInfo if (d.getInfo() instanceof NasDatastoreInfo) { NasDatastoreInfo dsInfo = (NasDatastoreInfo) d.getInfo(); if ( dsInfo != null ) { HostNasVolume naaName = dsInfo.getNas(); JsonObject jObject = new JsonObject(); jObject.addProperty("{#DATASTORE}", d.getName()); //jObject.addProperty("{#UUID}", uuid); jObject.addProperty("{#UUID}", "N/A"); jObject.addProperty("{#CLUSTER}", d.getParent().getName()); jObject.addProperty("{#LOCAL}", !d.getSummary().multipleHostAccess); jObject.addProperty("{#NAA}", naaName.getName()); jArray.add(jObject); } } else if (d.getInfo() instanceof LocalDatastoreInfo) { LocalDatastoreInfo dsInfo = (LocalDatastoreInfo) d.getInfo(); if ( dsInfo != null ) { HostNasVolume naaName = dsInfo.getNas(); JsonObject jObject = new JsonObject(); jObject.addProperty("{#DATASTORE}", d.getName()); //jObject.addProperty("{#UUID}", uuid); jObject.addProperty("{#UUID}", "N/A"); jObject.addProperty("{#CLUSTER}", d.getParent().getName()); jObject.addProperty("{#LOCAL}", !d.getSummary().multipleHostAccess); jObject.addProperty("{#NAA}", naaName.getName()); jArray.add(jObject); } } else { VmfsDatastoreInfo dsInfo = (VmfsDatastoreInfo) d.getInfo(); if ( dsInfo != null ) { HostScsiDiskPartition[] naaName = dsInfo.getVmfs().extent; JsonObject jObject = new JsonObject(); jObject.addProperty("{#DATASTORE}", d.getName()); //jObject.addProperty("{#UUID}", uuid); jObject.addProperty("{#UUID}", dsInfo.getVmfs().getUuid()); jObject.addProperty("{#CLUSTER}", d.getParent().getName()); jObject.addProperty("{#LOCAL}", !d.getSummary().multipleHostAccess); jObject.addProperty("{#NAA}", naaName[0].getDiskName()); jArray.add(jObject); } } }

Let me know if it works. I'll add it to the next release.

@woutervb
Copy link
Author

woutervb commented Apr 17, 2016

Hi @dav3860,

I already had a look at the code and tried your suggestion yesterday. Unfortunately it did not workout as expected.
Finally I added instanceof clauses for all possible DatastoreInfo subclasses, but non matched. So I finally ended up adding an else clause that only works at the level of Datastoreinfo (and does not take any of the possible submembers into account). This dit work.
With that code I can sucesfully run a discover (from the commandline with zabbix_get) and get data about the datastore (again with zabbig_get, referencing the datastore by name).

I did not check the provided templates to see of the LLD rules work using the UUID of the datastore's, of the name. If the latter is the case, then, provided you are intrested. I can cleanup my code and prepare a pull request. The issue is that there is no uuid for a datastore available (as far as I can tell) at the level of Datastoreinfo.

@woutervb woutervb reopened this Apr 20, 2016
@IsamuD
Copy link

IsamuD commented Feb 22, 2017

This issue with VSAN datastores is still on-going in the most recent vmbix release. When running a discovery, vmbix errors out with:

[VmBix.java:554] Parsing this request : ZBXDdatastore.discovery[*]
[VmBix.java:2022] An error occurred : java.lang.ClassCastException: com.vmware.vim25.DatastoreInfo cannot be cast to com.vmware.vim25.VmfsDatastoreInfo

Furthermore, when running the vmbix-object-sync - it also errors out at the datastore section:

INFO - [vsphere_object_datastore] Importing objects of type [vsphere_object_datastore] into Zabbix
ERROR - [vsphere_object_datastore] Cannot decode VmBix response

Is there anything that I can do to help solve this?

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants