vSphereDB import source host variable


[Icinga2 2.11.4, Director 1.10.2]

I was trying create a vspheredb command check with a target Vm .
I want to attach a host with a command like

‘/usr/bin/icingacli’ ‘vspheredb’ ‘check’ ‘vm’ ‘–name’


In summary, I want to enable icinga2 to query the vm object from the vSphereDB module.

Someone have already provided an answer to this problem,
however I don’t think I could find this variable:

as suggested from this post when he tries to import a “DirectorOverrideTemplate”

you dont need this specific variable.
that’s from dominiks specific serviceset apply rule

if you use icinga director ignore the config files for a second.

do you have a check command for vspheredb in icinga director?
do you have a servicetemplate for vsheredb in icinga director?


I have both a check command

and a service template in icinga Director

Thank you guys


This is the mapping for the monitoring integration(Vmware)

My resource Name in Configuration->Application is “vspheredb”.
In addition, I’ve this import source from the Director only

Any suggestion?
Thank you for helping me

your check commands looks weird. what’s in the argument section?
take any other check command as reference.
the command is the binary / script /whatever.
all arguments go to the argument section with an argument and a value.
the value can be something like $host.name$, or $check_blabla_value$
these values can be added to the field section of the check.


I tried to take any other command as reference.
The command is in the first snapshot, the arguments and values in the third one.
The field section is the second snapshot.

There is also the Service template attached.
My aim is to trigger my notifications that I also attached to the service and host objects.

first screenshot shows arguments in the command line and some strange ${host
second screenshot shows fields
third screenshot shows 2 arguments with the corresponding fields, which looks ok
I lost track, but there is a screenshot with check type = $host.name$ and object name = vm, which looks weird too

This is how I configured the check:

the preview with the argument details:

object CheckCommand "116-cmd-check-icingacli-vspheredb" {
    import "plugin-check-command"
    command = [ "/usr/bin/icingacli", "vspheredb", "check" ]
    arguments += {
        "--name" = {
            description = "name of object to check - only needed if check_type is singular"
            order = 1
            required = false
            value = "$116_check_icingacli_vspheredb_name$"
        check_type = {
            description = "Type of check to perform"
            order = 0
            required = true
            skip_key = true
            value = "$116_check_icingacli_vspheredb_type$"

To bind the imported hosts together with the check, a service is used:

template Service "116-tpl-service-vspheredb-vm" {
    import "tpl-service-generic"

    check_command = "116-cmd-check-icingacli-vspheredb"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 15s
    command_endpoint = null
    vars["116_check_icingacli_vspheredb_name"] = "$host.name$"
    vars["116_check_icingacli_vspheredb_type"] = "vm"

 * Service Set: 116 vSphereDB VM
 * assign where host.vars.custom_values.icinga_director_teams || "vspheredb-vm" in host.vars.custom_tags

apply Service "Icingacli vSphereDB - VM Status" {
    import "116-tpl-service-vspheredb-vm"

    assign where host.vars.custom_values.icinga_director_teams || "vspheredb-vm" in host.vars.custom_tags
    zone = "master"

    import DirectorOverrideTemplate

icinga_director_teams is a custom attribute on the VM in the vCenter that I set via the import so it’s certain to be a VM as no other hosts have this and the vspheredb-vm is used to manually declare the host a VM in my setup.

@rivad @moreamazingnick thank you for your reply.
I’m trying to solve this.

Here’s how it is configured

object CheckCommand "vm-status" {
    import "plugin-check-command"
    command = [ "/usr/bin/icingacli", "vspheredb", "check" ]
    arguments += {
        "--name" = {
            description = "name of the object to check"
            order = 1
            required = true
            value = "$check_icingacli_vspheredb_name$"
        check_type = {
            description = "Type of check to execute"
            order = 0
            required = true
            skip_key = true
            value = "$check_icingacli_vspheredb_type$"

Where I went wrong? As you can see I can’t do anything from the “drop down command” menu (like you did in your first picture @rivad ). No Datastore available for me.

This is the service template

template Service "vSphere DB" {
    check_command = "vm-status"
    command_endpoint = null
    vars.check_icingacli_vspheredb_name = "vm"
    vars.check_icingacli_vspheredb_type = "$host.name$"

From the image above, I suppose that vm is going to be the vm name.
In addition, is “$host.name$” recognized from the host that uses the service or not? (Do I have to add as a data field in the Icinga Director?)

I’d like to check the VM status from the Icinga dashboard as the final result.

I have no Property Modifiers defined in my Datastore (Icinga Director-> automation-> modifiers) if this might help.

These are the data fields defined inside the Icinga Director:

Have a look at this section on the main director page:
here you can define lists for your fields to make the drop down but be aware, that this is optional and just writing out the valid type also works.

Thank you @rivad

Which host should I attach the service to?
Is it advisable to create custom attributes on the vCenter?
If you can provide an anonymized screenshot I believe it can be easier.

Thanks again

I attached the service that is checking the virtual machine status to the hosts that are VMs.

Maybe it would make sense to have a host for the vCenter and attach check of a global type, like the datastore type, there.

Only you and your vCenter admin can figure out if it makes sense in your environment to put custom attributes on the vCenter to have them available in the import and what to do with them.

A screenshot of what? The custom tags and attributes? Here a screenshot of a old test server of mine, as seen by the Icingaweb2 vSphereDB module:


Sorry Dominik,
I was looking for a manual for attaching checks on a vCenter host

Your service template still looks strange as host.name doesn’t belong into vspheredb_type:

vars.check_icingacli_vspheredb_name = "vm"
vars.check_icingacli_vspheredb_type = "$host.name$"

should be:

vars.check_icingacli_vspheredb_name = "$host.name$"
vars.check_icingacli_vspheredb_type = "vm"

so the other way around.

Ok, got it and corrected it