Dynatrace Network Analyzer Documentation

Skip to end of metadata
Go to start of metadata

DNA supports VMware environments with certain limitations. Follow Dynatrace guidelines to minimize the effects of running DNA in a VMware virtual environment.

Use hardware-based timing when possible

Virtual machine operations do not necessarily run in real time. For example, if a virtual machine is competing with other virtual machines for resources on a single piece of real hardware, an operation that would run in 1.0 seconds on a real (physical) machine might take 1.3 seconds of real time (time on the wall clock) to execute. The virtual machine might then attempt to make up for such a delay by executing another operation in less time than it would take to execute in real time.

In most cases, such minor adjustments go unnoticed, but they could make a difference in an application such as DNA in a virtual environment with a virtual clock. For example, a packet captured in the 11th real second since the (real) computer was turned on might be recorded as if it had arrived in the 8th second if the packet capture driver (running on a virtual machine) was not kept consistent with the underlying real time. Views that are affected to a degree dependent on the severity of the virtual timer are those that measure or allocate delay. These include CNS breakdown, Performance Overview, Node Processing and Node Sending tables, Transaction Expert reports, and auto-adjustment (heuristic). For more information, see http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf.

With DNA (console, agent, and Simple Capture) running on VMware ESX(i) 3.5 (or later) or VMware Workstation 6.5 (or later), you can now configure the driver to read the current time from the underlying host machine instead of depending on the (virtualized) operating system's time, which may be unsynchronized with real time.

For more information, see Enabling hardware-based timekeeping in VMware virtual machines.

Use a separate VMware guest machine when possible

The preferred method for capturing network traffic in a VMware environment is to use a separate VMware guest machine dedicated to the DNA agent.

  • Make sure that this guest machine runs with high priority.

  • Use the port spanning functionality available through the VMware vNetwork Standard Switch (vSS) or VMware vNetwork Distributed Switch (vDS). This configuration will allow the network traffic between VMware guest machines to be visible to the Agent machine. To learn more about vSS and vDS, see (external link) http://www.vmware.com/files/pdf/vsphere-vnetwork-ds-migration-configuration-wp.pdf

Alternatively, you can install the DNA agent directly on a guest machine. However, the additional processing performed by the machine may cause the virtual timing problem to be more pronounced.

Note:

Icon
Some of the possible timing problems described below may be mitigated or negated if you can use the hardware-based timing method. For more information, see Use hardware-based timing when possible.

VMware virtualization timing considerations affect some of DNA's performance analysis. Specifically, VMware's timer virtualization technique (called “apparent time”) allows a virtual timer to fall behind real time and then to catch up as needed. This time lag between the virtual machine and real time may reach a level greater than a millisecond. Such delays will be recorded in the time stamps in DNA traces.

These timing problems affect only the network trace capture phase. For trace analysis performed in the DNA console, it does not matter whether DNA runs in a VMware environment. It is accuracy of time stamps in the traces that matters.

For analyzing single trace files within DNA—without merging or adjusting to examine network delays—the following holds true:

  • The inaccuracies resulting from using virtual time stamps will usually not be noticeable, and should have a negligible effect on most analyses. In these cases, views and functionality that offer byte/packet statistics, as well as protocol decodes, will not be affected beyond the loss of time stamp precision. These include the Packet trace, Conversation map, Thread Analysis, Error analysis, and Payload vs. Overhead views.

  • Views that are affected to a degree dependent on the severity of the virtual timer are those that measure or allocate delay. These include CNS breakdown, Performance overview, Node Processing and Node Sending tables, Transaction Expert reports, and auto-adjustment (heuristic).

If the analysis will require merging or adjusting traces within DNA, extra caution may be required, especially if the network separating the capture points is low-latency. (High-latency WAN links easily mask most virtual time stamp inaccuracies.) For this reason, we do not recommend merging trace files across low-latency links (< 20 milliseconds round-trip) where one of the trace files must come from a virtual machine. However, you may be able to use hardware-based timing on your virtual machine to mitigate this problem. For more information, see Use hardware-based timing when possible.

 

  • No labels