Feature: Adds plugin for VMM state monitoring

[LordHepipud]

Adds new plugin to check host states from Virtual Machine Manager (VMM) view

Fixes #40

[K0nne]

We have finally tested the plugin. Another big sorry for our delay!!! The plugin can detect the state of the managed VMs, but I think there's a bug in the detection of unwanted states (-VMMState). 'NeedsAttention' should lead to 'CRITICAL'. We have tested the PR with the framework version 1.8.0.

icinga> Invoke-IcingaCheckHyperVVMM -Hostname 'CLUSTERFQDN' -verbosity 2 -VmmState 'OK'
[OK] VMM Overview: 15 Ok
\_ [OK] HOSTNAME0001: status is NeedsAttention
\_ [OK] HOSTNAME0002: status is NeedsAttention
\_ [OK] HOSTNAME0003: status is NeedsAttention
\_ [OK] HOSTNAME0004: status is NeedsAttention
\_ [OK] ANOTHERHOSTNAME001: status is OK
\_ [OK] ANOTHERHOSTNAME002: status is OK
\_ [OK] ANOTHERHOSTNAME003: status is OK
\_ [OK] ANOTHERHOSTNAME004: status is OK
\_ [OK] ANOTHERHOSTNAME005: status is NeedsAttention
\_ [OK] STILLANOTHERHOSTNAME001: status is OK
\_ [OK] STILLANOTHERHOSTNAME002: status is NeedsAttention
\_ [OK] STILLANOTHERHOSTNAME003: status is OK
\_ [OK] STILLANOTHERHOSTNAME004: status is OK
\_ [OK] STILLANOTHERHOSTNAME005: status is OK
\_ [OK] STILLANOTHERHOSTNAME006: status is OK

[LordHepipud]

Thank you very much. I just updated the PR. Could you please test again? You would simply require to replace the Invoke-IcingaCheckHyperVVMM.psm1 file.

[K0nne]

Will do hopefully tomorrow.

[K0nne]

We have tested the PR and it looks good 👍 .. on the commandline (with an admin-powershell) ^^

When we execute the check via Icinga-Agent - which is running as local system - we get the following error message:

[UNKNOWN]: Icinga Custom Error was thrown: Custom Exception: VMM fetch error
Custom exception occured:

You cannot contact the VMM management server. The credentials provided have insufficient privileges on <cluster-fqdn>.

Ensure that your account has access to the VMM management server <cluster-fqdn>, and then try the operation again.

Here is our apply-rule:

apply Service "VMM State" {
  check_command         = "Invoke-IcingaCheckHyperVVMM"
  check_interval        = 5m
  command_endpoint      = host.name

  vars.IcingaCheckHyperVVMM_String_Hostname     = "$host.vars.hyperv_cluster$"
  vars.IcingaCheckHyperVVMM_Object_Verbosity    = 2
  vars.IcingaCheckHyperVVMM_Array_VMMState      = [ "OK" ]

  enable_notifications = false

  assign where regex("<HOSTNAMES>", host.name) && host.vars.agent == "icinga2"
}

We already restarted the service but didn't help.

[LordHepipud]

It seems that this is a permission problem, because the error message is directly thrown from VMM. Is changing the users permissions for accessing VMM resolving the issue? Is this used in JEA context or just as LocalSystem

[aheinhold]

Hi @LordHepipud the Icinga-Agent is running in LocalSystem context. JEA is not in use.

Is changing the users permissions for accessing VMM resolving the issue?

Which permissions should we add?

[K0nne]

We found some interesting behaviour:

Our VMM is running on 2 machines, one of them is holding the cluster ip. The check is only working on the machine, which currently doesn't hold the cluster ip. On the other one, the permission error is shown. If the cluster ip switches to the other machine, the behaviour also flips.

Does this makes sense somehow?

[aheinhold]

It seems that this is a permission problem, because the error message is directly thrown from VMM. Is changing the users permissions for accessing VMM resolving the issue? Is this used in JEA context or just as LocalSystem

Hi @LordHepipud it was a permission problem.
The icinga agent was not running in the local system context.

When can you take a look at the problem @K0nne reported?

[K0nne]

Hello @LordHepipud,

we found a solution. It was a permission problem on our side. VMM has its own rights management, which operates only on active directory users. When we switched to such a user, the check started to work on both sides of the VMM cluster.

You can merge it!