Vmware monitoring, duplicate with agent, can't update host

[doum]

Hi,

I have added one of our VCenter in Zabbix.
It has discovered all VM.

after this I deploy the agent on one of the VM.

I have two problem :
- it create as new host, no link with the VM, I think it's normal but this behavior is...underperforming
- more problematic, the auto registration of the agent has working, but now I can't edit the host (to add template and host group for example)
I've got a message : Cannot update host. Host with the same visible name "test server" already exists.

How do you manage your virtual environment in zabbix ?

[doum]

no one encounters the same situation?

[zekaleka]

yes, still facing the same in 7.4.10.

I guess VM discovery should be disabled to not encounter this issue. can't think of better solution.

[jtnfoley]

I've long used VMware integration, VM discovery created all the "Host" entries in Zabbix.
I, too, am now moving to agent-based and have decided to disable discovery... specifically, disabling "Discover VMware VMs FQDN" in both "VMware FQDN" and "VMware" templates.)
My entire environment is static IPs and my logging is IP based, not hostname, so I clone the discovered VM "Host" object and remove the VMWare templates from the clone, add the Linux by Zabbix Agent template, delete the original discovered VM Host object, then save the clone under the same name.
Agent config on the Host native OS is set correctly.

I briefly considered disabling the old Host object and implementing a hostname suffix (in Zabbix, and in the agent config, call the host <hostname>a" eg "dbserver01" becomes "dbserver01a" in Zabbix only!) Being static IPs and not relying on DNS at all, this was definitely an option.
I don't need to keep the VMWare guest performance history for these Hosts, so I can safely use the "delete original and keep the clone under the same name" model.

[mosconi.trt1]

We changed the VM template to prefix each VM with the cluster name

[Rudlafik]

I have Zabbix since version 3... This was my first problem too. LLD VMs are found thanks to the VMWare API. Metrics for VMWare VM states apply to them, not OS (win/lin). I can add a template to the host found in this way, but I cannot change the interface, the guest group. So this is insufficient for me. So I have VM machines discovered in the environment. They are there for vmware administrator states and metrics. Then I make a duplicate machine with the same name and the ZBX suffix and I freely edit it in the host group and add interfaces as I need.

Do I have a duplicate infrastructure? No. One layer is VM monitoring and the second layer is OS monitoring. Next, I check whether I always have a guest with the ZBX suffix for the found VM host. Everything is separate and remarkably clear.

(virtual machines xxxxxVMS, their versions for OS xxxxxZBX and physical machines xxxxxSRV)

[irontmp]

I've long used VMware integration, VM discovery created all the "Host" entries in Zabbix.
I, too, am now moving to agent-based and have decided to disable discovery... specifically, disabling "Discover VMware VMs FQDN" in both "VMware FQDN" and "VMware" templates.)
My entire environment is static IPs and my logging is IP based, not hostname, so I clone the discovered VM "Host" object and remove the VMWare templates from the clone, add the Linux by Zabbix Agent template, delete the original discovered VM Host object, then save the clone under the same name.
Agent config on the Host native OS is set correctly.

I briefly considered disabling the old Host object and implementing a hostname suffix. Dodge Wheels discussions often remind me how important consistent naming is for keeping everything organized. In Zabbix and in the agent config, I'd call the host "dbserver01a" instead of "dbserver01" in Zabbix only. Being static IPs and not relying on DNS at all, this was definitely an option.
I don't need to keep the VMWare guest performance history for these Hosts, so I can safely use the "delete original and keep the clone under the same name" model.

That's a pretty common issue. The vCenter-discovered VM and the agent-registered host are treated as separate hosts, which is why you're seeing the duplicate name conflict. I usually stick with the vCenter-discovered hosts and add the agent interface to those instead of relying on auto registration. It keeps everything tied to the same host and avoids duplicate entries.