VMware - Skip VM templates
The vSphere Agent discovers VM templates and generates a warning service for each because templates are always powered off. VM templates should be skipped during discovery.
Similar to placeholder VMs and passive fault tolerance VMs, the vSphere Agent can also identify and skip VM templates by using the property "config.template". It already retrieves that value from vSphere API but does not use it.
Patch fetch_virtual_machines() to identify and completely skip templates, like so:
def fetch_virtual_machines(...):
...
for entry in elements:
...
if vm_data.get("config.template") == "true":
continue
...
With this, VM templates will not be discovered.
Comments: 7
-
22 May
Thomas Lippert AdminRingo, you might consider to provide a pull request, if you have the code already
-
20 Jul
Robin GierseThere is actually a use case, why you want to see templates in Checkmk: To ensure they are powered down.
With the rule set "ESX host and virtual machine states" you can tell Checkmk, that all templates (based on proper naming) should be powered off and that you want a warning, if someone powers them on.
Of course, making skipping the templates in the special agent optional can make sense. -
11 Aug
Ringo Hartmann@Robin No there is not. Templates cannot be powered on. vSphere does not allow you to. There is no Power button or menu. Hence, there is no need to monitor templates, not even optionally.
If you clone a VM and name the clone "template_Ubuntu2204" or something, that doesn't make it a template. Technically, it is still just a regular VM (that would not be affected by the code change posted above).
Implementing some naming convention and a Checkmk rule to disable the resulting services is a flawed approach. Two lines of code avoid this issue entirely.
@Thomas I don't have a Github account (and I'm not creating one just for this). -
14 Aug
Robin Gierse@Ringo: I am aware that templates cannot be powered on in vSphere. But they can be converted to a VM which in turn can be turned on. And as the name stays the same, the use case I outlined is valid. And I beg to differ that a proper naming scheme is a flawed approach. We can agree to disagree, but other use cases are just as valid as yours.
Apart from use cases and philosophies, I do not deny, that making the discovery of templates configurable is sensible. But that changes the scope of this feature request. Can we agree to change the scope, or do you want to stick to your initial request? -
15 Aug
Ringo Hartmann@Robin I think we have a little misunderstanding here. Two things come to mind:
First: You certainly may use a naming convention on your VMs (and a rule to ignore some of them in your monitoring, based on that convention). That is totally fine and I don't disagree on that. But that is for VMs (including VMs cloned from templates) only.
You said it would be a use case for templates as well, which I don't agree on.
Second: Naming conventions by itself are not a flawed approach. But they are just conventions and can easily be avoided. Using your Monitoring and a naming convention to enforce something like "Templates must be powered-off", that seems pretty flawed to me. I'd much rather convert them to templates so vSphere enforces that for me.
My issue is that Checkmk currently forces me to either manually modify the vSphere integration or use that flawed approach.
Your use case (ignore VMs based on naming convention) is covered, but mine (ignore templates) is not. -
15 Aug
Ringo HartmannSecond comment because character limit reached :)
For the sake of whatever other use cases people might come up with (inventory or whatever), I would be fine if Checkmk allows you to opt-in to monitoring templates. But default should certainly be to ignore them, and if you opt-in, the resulting checks should by default not be WARNINGs. -
16 Aug
Robin Gierse@Ringo: I think we are mostly on the same page here, although we could have an extensive chat on monitoring vSphere. :)
Regarding the request: I am on board with your request, but if it gets implemented, it will be an opt-out, rather than on opt-in, as the latter would break existing setups. So lets see, how popular this becomes, or if someone with a GitHub account picks it up, before we can.