For information on how op5 products help with monitoring vmware, visit this page.
Why does op5 recommend customers not to run op5 monitor or statistics on VMware?

1, When you configure monitoring to check your infrastructure, it should be a stand-alone and dependent on as few components as possible in order to, no matter what happens in the environment, log correct response times and send alerts about real problems including any virtual server environment problems.

2, VMware has known problems with its clock. This is because the individual virtual servers do not have internal clocks. Instead these are configured in VMware Tools and are not reliable enough for the types of measurements we carry out. When measuring response times in milliseconds, a difference of a couple of seconds can cause problems.

Here is an abstract from the nagios user forum that describes the problems to the point (thanks to Steve Shipway s.shipway@auckland.ac.nz)

Most of them come down to the inaccuracy of calculating rates when in a VM on a moderately loaded ESX server, due to the clock tick being irregular. Although NTP will keep your clock in synch at an hours-minutes level, when you get down to a seconds level it will have some seconds apparently longer than others. This is not a problem in many cases, but it IS a problem if you are calculating rates by taking a sample, waiting 10 seconds (or 30 seconds, or whatever), taking another sample, and dividing the difference by the time interval. The shorter your sample interval, the more that VMWare can affect things. This is a known issue to VMWare and they advise against running this sort of monitoring (I am afraid I cant find the reference, it was buried deep in documentation I read for the v2 of VMWare). The other issue is that, since Nagios is your central alerting system, it is good practice to keep it as independent of other hardware and infrastructure as possible. This means avoiding using virtualisation (we don’t even use the SAN, let alone VMWare). Fewer dependencies means less change that something can knock out your monitoring system. So, the conclusion we came to is that you can use vmware, but if you care about accuracy in per-second rate calculations (which you may well care about if you are thresholding on them), then do not.