Zabbix Server on VMWare

[Yello]

Hi,
Can I ask what the recommendations are for running the zabbix server and frontend on vmware? I've noticed some issue with response times on some checks and suspect this might be due to vmware's slicing and dicing of server resources.

I'd appreciate some input on the validity of running zabbix server on a virtual platform and would also be interested if any moves have been made to certify zabbix on vmware?

Regards,
David

[bcarpio]

VMware

I've run all my zabbix deployments on VMware.

Currently monitoring 6662 items, 1049 triggers on a VM with 2 vCPUs and 4G RAM.

[Yello]

Hi,
Well, I'm seeing that timing/latency checks can be inaccurate and gaps can appear in data. Based on my investigations these behaviours correlate with:

1. V-Motion
2. VM backups/snapshotting
3. The generally etheral nature of resource availability in a virtual environment.

This has led me to the view that while it is ok to virtualize the frontend, the zabbix server processes should not be staged on a virtual platform.

What I want to understand whether others agree with that sentiment and whether Zabbix has done any work with vmware et.al. to mitigate the impact of the virtual domain on zabbix server processes.


Regards,
David

[KimmoJ]

I haven't seen any of those issues when running it in VMware myself. Might be you're just not giving it enough resources to work with. If you have issues with Zabbix in your virtual environment, chances are you'll have issues with everything else too.

Have you tried reserving resources in VMware to give Zabbix a guaranteed amount of cpu/memory/disk access?

If you're squeezing every last shred of CPU and memory out of your virtual environment, maybe you've reached the point where you're starving your VM's?

[Yello]

Hi,
The VM we run zabbix on is reasonably well resourced, particularly with Memory (8GB) so we don't see performance bottlenecks at the OS level. It could be that it is lack of overall resource on the ESX hosts is the issue here. I'll look into that.

However, I've also come to the view that if you have items timing responses from a series of servers, and those timings are important, moving the zabbix VM between hosts to balance resources in VM-land must have an impact on the timings being returned from the network. VMotion is not seemless from the point of view of delay sensitive server processes...

Please note, that this isn't something that necessarily jumps out at you from the graphs. It took a particular set of circumstances to highlight an issue that turned out to point to the virtual platform.

Regards,
David

[AndrewSummer]

Just to add my 2 cents:

I have Zabbix running on VMware ESXi 6.5 on a medium Sized Cluster of 13 Hosts.

Zabbix Monitors
~500 Hosts
~21000 Items
~8000 Triggers
~900 NVPs

Zabbix DB is on an extra beefy VM. I use serveral Proxies to monitor IPMI and VMware and so on.

I start to see strange behaviours. First and foremost:
Massdropping Pings at certain times.
And I start to suspect that the DRS VMotion migration of the Zabbix VM could be the culprit.

So... I will start by making the VM Sticky to one host in the hope that this will stop making false alarms. Thanks for your Input. Even if it is from 7 years ago...

Cheers!

[AndrewSummer]

Making the Zabbix Server sticky to one ESX host really solved the problem with the "Ping Droppings" and other strange behaviour.

VMware VMotion and 100% seamless... Good joke.


But we are still getting real hardware for Zabbix, cause a monitoring system should be independend from other services....