Andreas Grabner About the Author

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

The problem with SLA monitoring in virtualized environments

Because virtual machines work by time-sharing host physical hardware, a virtual machine cannot exactly duplicate the timing behaviour of a physical machine. This leads to the timekeeping problems explained in the VMWare White Paper about Timekeeping in Virtual Machines that results in inaccurate time measurements within the virtual machine. This affects ALL performance metrics that rely on the operating system clock time to keep track of time which includes system counters like CPU or I/O Utilization. Performance Management solutions therefore run into the problem that the monitored metrics are inaccurate and can lead to incorrect enforcement of SLAs or wrong assumptions about application performance.

This blog explains the time keeping problem, how it impacts Application Performance Management in virtualized environments and what can be done to solve this problem.

Time keeping problem explained

Operating Systems that use a Tick Counting approach to keep track of time use hardware interrupts to count how many ticks have occurred since the system started. In a virtualized environment these interrupts are consumed by the virtualization infrastructure which keeps track of what we call the “Real Time”. The interrupts are then forwarded to the hosted virtual machines which itself keep track of the time that we call “Apparent Time“. In the best case scenario Real Time and Apparent Time are the same:

Timekeeping - Phase 1 - Real and Apparent Time are the same

Timekeeping – Phase 1 – Real and Apparent Time are the same

A virtual machine is not “always on” as it gets descheduled by the virtual server because of time-sharing with other virtual machines. In that time the hardware interrupts cannot be handled by the virtual machine and are therefore put into a queue for later consumption.

Timekeeping - Phase 2 - Virtual Machine is descheduled

Timekeeping – Phase 2 – Virtual Machine is descheduled

At the time the Virtual Machine gets scheduled again the operating system’s Apparent Time is still the time it was before it got descheduled as it has not yet received the timer interrupts that happened in the meantime. In that case the Apparent Time has drifted from the Real Time. Impact: Any performance metric taken at this time only shows the time that the Virtual Machine believes had passed which is not the time that really passed.

Over time the Virtual Machine catches up with the interrupts it missed while descheduled.

Timekeeping - Phase 3 - Catching up with Time
Timekeeping – Phase 3 – Catching up with Time

There are several other techniques that virtualization environments use to bring the Apparent Time back to Real Time as fast as possible. For more details have a look at the VMWare White Paper as mentioned on the top of this blog.

Impacts of the Time Keeping Problem

Any time based metrics captured from within the Virtual Machine are subject to the timekeeping problem including CPU Utilization, Memory Allocations per time interval, I/O access per time interval,…  and any custom time tracking that can be used for e.g.: response time or transaction time monitoring. Operating system counters like % CPU per process also runs into another interesting problem where individual processes might get charged incorrectly with time that they never consumed. After a Virtual Machine is resumed the queued timer interrupts are processed. These interrupts come in a faster rate than normal. The currently active processes are charged with all these timing events although they have not done any work in that time because they were actually descheduled.

You can see that the timekeeping issue can really mess up your performance counters. The more load you have on a virtual server, the more virtual machines there are to schedule and de-schedule – the higher the impact on accurate timing will be. Other side effects like over-provisioning of CPU or Memory have an impact as well.

Using performance metrics from within the Virtual Machine for application performance management and enforcement of Service Level Agreements is therefore very questionable as the results are not accurate and not predictable.

Accurate Time Keeping with Pseudo Performance Counters

VMWare is aware of this problem and explains in great detail the reasons and the effects in their White Paper. As a solution for performance management solutions VMWare provides a way to query the actual Real Time at any time from within the Virtual Machine. Pseudo Performance Counters are made available via virtual processor registers that can be accessed from any application within the Virtual Machine.

dynaTrace is using these new counters for accurate time measurement when Managing Application Performance in virtualized VMWare environments. This allows accurate SLA enforcement and application performance management down to individual transactions or even methods. The following illustration shows a single captured transaction with accurate timings. dynaTrace captures the Real and the Apparent Time on method and transaction level:

Accurate Timing on Transaction and Method Level
Accurate Timing on Transaction and Method Level

Capturing the Real Time values and also showing the Apparent Time Drift enables Application Performance Management with accurate timing values. Accurate timings are the basics for accurate SLA Enforcement in Production as well as Application Performance Monitoring.

Is timekeeping a real issue in your environment?

The timekeeping problem is well known within the VMWare community and brings challenges to accurate application performance management in virtualized environments. I am interested in your experience with this problem. Have you been aware of it? Do you live with the inaccuracy or do you have other approaches for accurate measuring? Please share your thoughts on this topic.


  1. Great article. I especially like the first three figures, which explain the time keeping issues in a very understandable way. This visualization can be used to explain matters to management without becoming too technical.

  2. When you say…

    “Pseudo Performance Counters are made available via virtual processor registers that can be accessed from any application within the Virtual Machine.”

    …do you mean the Windows Perfmon counters that are under the “VMware” performance object?


  3. @Stuart
    I am talking about the Pseudo Performance Counters that are referenced in the VMWare White Paper. This feature can be enabled in the VM Configuration for a virtual machine. Once enabled you have additional process registers that you can read from your application code. It has nothing to do with Windows Performance Counters.
    For more details check out the White Paper and search for Pseudo Performance Counters.

  4. John Strumila says:

    Yep, exactly the same issues as documented by ibm 30 years ago under lpars. Of course type 30_v were still much more accurate.

  5. Alois Reitbauer Alois Reitbauer says:


    and what is the IBM answer to that problem. Did they consider the problem in their monitoring solutions?

  6. Tomasz Szreder says:

    the VMware’s Pseudo Performance Counters you mention seem to be a good solution to the timekeeping issue I am experiencing with VMware virtual machines (collected timestamps are inaccurate beyond acceptable levels). The problem is, I have followed the instructions from the VMware whitepaper on timekeeping but I can’t seem to get it work using a simple assembly code, as I explain here: . Do you think you could spare a minute and point me in the right direction?
    Tomasz Szreder


  1. [...] The problem with SLA monitoring in virtualized environments … [...]

  2. [...] The problem with SLA monitoring in virtualized environments … [...]

  3. [...] The problem with SLA monitoring in virtualized environments Performance, Scalability and Architectur… (tags: performance virtualization monitoring sla) [...]

  4. [...] problem with timekeeping is well known in the VMWare community. There is a very good VMWare whitepaper that explains this in [...]



9 − = four