Has anyone used APOC to import VMware infrastructure?

Wondering the best way to go about this. vSphere webAPI/SDK? PowerCLI, or even go simple and import from RVTools output?

I don't want to re-invent the wheel if someone already has built something along these lines.


I think I remember reading about that somewhere.

In general if there is a REST API it should be possible to do.

I did figure out a simpler one when I was doing this for a Service-NOW instance, and it worked great!

WITH "https://admin:password@devinstance.service-now.com/api/now/table/sys_user" as url
CALL apoc.load.jsonParams(url,{Accept:"application/json"},null) yield value

But VMware has a little more complexity:

Part1 - get session token
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'vmware-use-header-authn: test' --header 'vmware-api-session-id: null' -u 'administrator@vsphere.local' -p 'Passw0rd!' '' --insecure

Part2 - use session token and then query data:
curl -sik -H 'Accept:application/json' -H "vmware-api-session-id:2b26afc12cd4b374d998e2d63b3b9573" -X GET

I'm not exactly sure the proper syntax to add multiple header, nor how to properly pass the -u and -p using apoc.load.params.

You can either do it on the client and pass as parameters.

Or you can call multiple apoc invocations and use results of the first ones in later ones as header params.

It appears to not like the name of the header property for the VMware API. Is there a way to escape or quote? I tried brackets, single, and double quotes, and all returned syntax errors:

Neo.ClientError.Statement.SyntaxError: Invalid input '-': expected an identifier character, whitespace, '}' or ':' (line 1, column 88 (offset: 87))
"CALL apoc.load.jsonParams("https://vcenter.mydomain.com/rest/vcenter/datastore",{vmware-api-session-id:"060207e88eedef581641035e808512cd"},null) yield value"

same as other variables, labels, rel-types and property-keys in cypher, if you have special characters, like your dash -, you need to escape them with backticks:

CALL apoc.load.jsonParams("https://vcenter.mydomain.com/rest/vcenter/datastore",
yield value

Is there a way to tell apoc to ignore certificate errors? I suspect the vcenter self-signed certificate is causing this error...

Neo.ClientError.Procedure.ProcedureCallFailed: Failed to invoke procedure apoc.load.jsonParams: Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Did you check to use the latest 1.8 JDK? They added some root CAs.

Can you check the certificate manually?

No, I know it's a self-signed, (out-of-the-box) so it will for sure fail. And many clients leave their vcenter environments with the self-signed certificates, so I thought it would make sense to verify I can properly query a vcenter that has a self-signed certificate.

So is it actually my jdk that is complaining about the certificate, and not neo4j? Sorry, I'm sure some of my questions are a bit basic. as you've probably gleaned from my questions I don't really have a developer background... (some scripting, vbs, powershell, vcli, tsql), but mostly automating infrastructure conf/monitoring/administration. In the short term I'm using excel output from RVTools, and using apoc.load.excel, but at some point I should do it the right way, directly from the web-api.

Yes, it's in the JVM layer, not sure how much we can do about that in APOC, have to investigate.
Can you raise an APOC github issue?

Ok - thought I should post a follow-up here. I never bothered trying to arm-wrestle with the vCenter WebAPI, but there's a really handy-dandy freeware utility that exports the entire vCenter environment into one large Excel file, so I just used that, and then used apoc.load.xls to do the rest.

It's a first draft, but I have tested with with a few different environments. It DOES require a vCenter (no standalone ESXi hosts).

Link to an example of the graphDB schema that will be created.

Link to step-by-step instructions if someone wants to take it for a spin.

This is intended to be run from a Windows (Powershell) environment, and has some powershell/n4jdotnet design aspects, but you could certainly just take the existing .cypher and run with it.

Appreciate any feedback.