Icinga / icingaweb2-module-vsphere

VMware vSphere import source for the Icinga Director
GNU General Public License v2.0
32 stars 8 forks source link

406 "NOT_ACCEPTABLE" when attempting to import hosts #11

Closed aedahl-zz closed 6 years ago

aedahl-zz commented 7 years ago

I receive the following error:

This Import Source failed when last checked at 2017-10-18 13:50:08: Got 406: '<?xml version="1.0" encoding="UTF-8"?> <Error xmlns="http://www.vmware.com/vcloud/v1.5" minorErrorCode="NOT_ACCEPTABLE" message="The request has invalid accept header. Supported API versions are: [1.5, 5.1, 5.5]" majorErrorCode="406" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://XX.X.XX.XX/api/v1.5/schema/master.xsd"></Error> '

when attempting to import my vCloud source through Icinga2 / the vsphere module.

source setup in the module is as follows:

image

I can pass a simple POST no problem (using the Chrome extension, Postman) with the Authorization (Basic) and Accept (application/*+xml;version=5.1) headers... I receive a 200 OK back

Here is the response XML:

<?xml version="1.0" encoding="UTF-8"?>
<Session xmlns="http://www.vmware.com/vcloud/v1.5" user="u-sernameforvcloud" org="ORG" type="application/vnd.vmware.vcloud.session+xml" href="https://XXXXXXX.XXXXXXXXXX.net/api/session/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://XX.X.XX.XX/api/v1.5/schema/master.xsd">
    <Link rel="down" type="application/vnd.vmware.vcloud.orgList+xml" href="https://XXXXXXX.XXXXXXXXXX.net/api/org/"/>
    <Link rel="remove" href="https://XXXXXXX.XXXXXXXXXX.net/api/session/"/>
    <Link rel="down" type="application/vnd.vmware.admin.vcloud+xml" href="https://XXXXXXX.XXXXXXXXXX.net/api/admin/"/>
    <Link rel="down" type="application/vnd.vmware.vcloud.org+xml" name="ORG" href="https://XXXXXXX.XXXXXXXXXX.net/api/org/6f312544-e588-4c13-857d-fca0b52785e7"/>
    <Link rel="down" type="application/vnd.vmware.vcloud.query.queryList+xml" href="https://XXXXXXX.XXXXXXXXXX.net/api/query"/>
    <Link rel="entityResolver" type="application/vnd.vmware.vcloud.entity+xml" href="https://XXXXXXX.XXXXXXXXXX.net/api/entity/"/>
    <Link rel="down:extensibility" type="application/vnd.vmware.vcloud.apiextensibility+xml" href="https://XXXXXXX.XXXXXXXXXX.net/api/extensibility"/>
</Session>
Thomas-Gelf commented 7 years ago

Hi @aedahl,

this module talks to the SOAP API of a vSphere/ESX(i) Host or (preferably) a vCenter. Seems you're pointing it to a vCloud Director. That's a completely different beast with a different API and different goals. When running a vCloud handling your vApps, there should also be at least one vCenter dealing with your infrastructure I guess. So, changing URL (and credentials) accordingly should fix this.

You can also import from multiple vCenters if you want. This module directly deals with the infrastructure part and imports Hosts and Virtual Machines. It doesn't know about vApps defined in your vCloud.

Cheers, Thomas

Thomas-Gelf commented 7 years ago

NB: In addition to this, we have more plans related to VMware. No concrete plans so far to support the vCloud API, but this shouldn't be that hard. It's API looks a lot simpler than the vSphere SOAP API. Just, until now we didn't meet much related interest, and the customers I've personally been working with so far were all dealing with classic and quite "static" clouds. Sure, thousands of VMs, lots of automation - but not driven by a vCloud Director.

In parallel we're working on a fork of this, a new module with a small dedicated DB. Please don't use it, it isn't finished yet - just wanted to let you know where we're heading to with all this.

That new module will provide a synchronized subset of the most important information related to your vCenter in a fast and efficient way. In it's first iteration we focused on Data Store visualization. It has/will have some nice features, like pointing out where over-provisioning is currently putting you at risk. If you want to see a screen-cast showing it in action please mail me, I can send you a link pointing to a video.

In the (hopefully near) future this should also track current and historic vMotions and provide a better visualization of CPU/Memory sharing and usage. It should provide a (roughly) aggregated insight into your performance data, especially disk and network I/O. Also here, the main goal will be trying to visualize current hot spots.

All this will then allow us to replace most of the (quite expensive) VMware-related check plugins with much, much lighter ones firing against this little DB. So, you can expect to run checks at higher frequency, while being able to show a lot more context-related information. We also have plans to feed some checks via passive check results on VM startup/shutdown or motion events to have an immediate visualization and/or notification in that case.

So:

Both talk to the vSphere SOAP API, as this allowed us to support a broad range of VMware versions and environments. No plans so far for dealing with vApps through vCloud, but we are of course interested in this. It would be nice to integrate it into our upcoming vspheredb schema, shouldn't be that hard. Any help (code contributions, access to a test platform, sponsorship) would be highly appreciated. Both modules, vsphere and vspheredb have been/are being realized as part of consultancy projects, remotely and on-site.