DNA supports VMware
environments with certain limitations. Follow
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.
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
Alternatively, you can install the
directly on a guest machine. However, the additional processing performed by the machine may cause
the virtual timing problem to be more pronounced.
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
These timing problems affect only the network
trace capture phase. For trace analysis performed in the
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
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.
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.