CentoOS 6

I agree - it would be great to be able to define host interface, because now Host prototype is useful for VMware integration only.

It would be great to be able to change some other properties for the hosts created by an LLD rule also (e.g. host group, IPMI, inventory, etc).

Would be brilliant to be able to easily set up a heterogenous group of monitored VMs without manually entering each machine’s host information or having to Clone the prototype-created host.

I'd go so far as to argue that if this feature is only useful with VMware monitoring, that it should be renamed.

I was attempting to sync hosts from one zabbix server to another, wrote a small script that generates data like this for use with an LLD:

{

    "data": [{
        "#HOST": "EXAMPLEHOST",
        "#IPADDRESS": "12.34.56.78",
        "#GROUP": "LLD Host Group",
        "#NAME": "Host Display Name"
    },

    {

        ...

    }]

}

With the idea that the LLD could then handle adding and removing the hosts dynamically.  Unfortunately, this can't work, because I'm not able to set the interface in the host prototype.  Perhaps this would be better named "guest prototype" or "VM prototype"?

we would also like this feature as having 2 hosts one a prototype and one just for the IPMI is just a waste

Creating full featured hosts (especially having their own IP/IPMI/SNMP/... adresses) via LLD would be awesome!

I'm running a Warewulf/Slurm HPC cluster with >100 nodes in different partitions for development and production (with slightly different requirements for monitoring - office hours vs. 24x7). Sometimes nodes are moved between those two - it would be really really nice to just fetch the node list from WW and create/update/remove hosts automatically.

It's not strictly useful for VMWare. For example, I've used host prototypes to use LLDs to define hosts for APs and WiFi clients hanging off of wifi controllers, monitoring wifi performance and reliability on a per-client basis, although I wasn't able to automatically correlate that data with my Zabbix agents that were already on some of these clients. 

That said, if I had the ability to automatically and programmatically define additional agents for host prototypes, I might be able to extend that to monitoring the SNMP or Zabbix-agent interface on a device discovered hanging off a wifi controller, or off a switch's ARP table, or off a DHCP server's client list, etc.

Though it may be that using normal discovery (not LLD) would work better for these cases, I don't know. Disadvantage of using normal discovery for these purposes is that I can't export the discovery rules and behaviors as a template for sharing with others.

@Michael Mol
Normal discovery would work if the host has just one interface. But how would normal discovery get e.g. different adresses for Agent, IPMI, ... and bind them to one host? With LLD there already is a mechanism to provide that information.

Are we allowed to see the specs, once they are finished, so we can give feedback?

Related issue: ZBXNEXT-6121

Implemented in development branch feature/ZBXNEXT-2072-5.1

Implemented in:

• 5.2.0beta1 (master) 9b28d29

vmurzins I have a question regarding this feature:

This sounds like the solution to the issue, that currently the combination of native Zabbix VMware monitoring via LLD Host Prototypes and classic Zabbix agent based monitoring, results in each VM being monitored twice. This is a "problem" that Zabbix has since 2.2 afaik -> ZBXNEXT-2088

I took a look at the 5.2 docs,and understand, that I have to perform an (JSON-) LLD that retrieve:

• The Hostname -> Zabbix-VMware-LLD already does that
• and additionally the DNS-Name -> Zabbix-VMware-LLD could do that, if the VM-name quals the FQDN
• OR even better IHMO the primary IP-address -> Zabbix-VMware-LLD can't do that afaik -> https://www.zabbix.com/documentation/5.2/manual/vm_monitoring/discovery_fields

That would mean, if I understand that correctly, that this feature here could potentiality solve the "double Hosts" problem with VMware & Agent monitoring, but the native Zabbix-VMware-LLD won't retrieve the interface parameters for me.

So I might have to drop the native Zabbix-VMware-LLD and might for example use VMware PowerCLI to retrieves the VMs incl. their interface IPs.

Please share you opinion. Thank you!

In general, this cannot be solved. We have vcenter api limitations and the information available to us depends on the behavior of the guest VM. This means that we cannot guarantee that the IP address will always be present in "vmware.vm.discovery", but we can try to get it.

Additional question: which fields from the "guest information" are more valuable for you, besides the ip address

Hi Michael,

As i well remember one of the most blocking issue for monitoring (Zabbix Active Agent) the VM was the VM.UUID because Zabbix used that as a Hostname on the hostprototype.

With the new implementation we still need the VM.UUID as a Hostname?

Thanks so much

Updated documentation:

• What's new in 5.2.0
• Virtual machine monitoring
• Low-level discovery macros
• User macros supported by location

Updated API documentation:

• Host prototype Object
• hostprototype.get
• hostprototype.create
• hostprototype.update

I hope ZBXNEXT-6269 will solve some of the problems voiced.