Timekeeping in VMware Virtual Machines

More documents

Recommendations

Info

Timekeeping in VMware Virtual Machines /sbin/hwclock program to set the CMOS clock directly. Alternatively, as most Linux distributions are configured to copy the system time into the CMOS TOD clock during system shutdown, you can simply set the system time and shut down the guest system before restarting it again. Guest Clock Synchronization With Non-VMware Software If you must run non-VMware clock synchronization software (such as the Windows time service W32Time) in a virtual machine, the built-in clock catchup that the virtual machine performs can confuse the non-VMware clock synchronization software. This confusion may cause time in the guest to get ahead of real time and generally may cause the clock synchronization software to have difficulty in tracking real time closely. Also, if VMware Tools time synchronization is enabled, both VMware Tools and the non-VMware clock synchronization software you are running will try to correct the clock without knowledge of each other, causing similar problems. Some customers have a requirement to use a virtual machine as a primary domain controller for a Windows network. The primary domain controller must run W32Time as a time server, to provide time to secondary domain controllers and other hosts on the network. However, the domain controller does not need to use W32Time's client functionality to receive time from another source and synchronize the virtual machine's own clock. So, you can use VMware Tools to synchronize the virtual machine's clock while still running W32Time in a server-only mode. For instructions on setting up W32Time this way, refer to Microsoft documentation on the Windows Time Service; specifically, the NoSync registry option. If this approach is not applicable to your situation and you must synchronize a virtual machine's clock using W32Time or other non-VMware software, you can take the following actions to minimize problems: 1. Completely disable VMware Tools time synchronization, as described in Keeping a Fictitious Time In a Guest System on page 15. 2. In addition, if you still observe the virtual machine getting ahead of real time, you can try limiting the built-in clock catchup. Normally, the built-in catchup is active whenever the guest is between 50 milliseconds and 60 seconds behind real time, and the guest clock attempts to run 200% faster than normal speed while catching up. You can modify this behavior by setting the following options in the virtual machine's .vmx configuration file. timeTracker.catchupPercentage = 200 timeTracker.catchupIfBehindByUsec = 50 timeTracker.giveupIfBehindByUsec = 60000000 Note: The option settings shown in the example are the default values. Reducing the giveupIfBehindByUsec option value may help in limiting the built-in catchup operation. Setting this option to a lower value makes the catchup give up more quickly if the virtual machine gets significantly behind real time, thereby letting the non-VMware clock synchronization software you are running take care of synchronizing the clock. It is probably not a good idea to completely disable the built-in catchup, however, since the virtual machine may then lose time faster than your operating system or application software expects to be possible in a real machine. 16
Timekeeping in VMware Virtual Machines Time Measurements Within a Virtual Machine Customers often ask how to measure the system CPU load from within a virtual machine, or are puzzled about seeing anomalous readings from CPU usage measurement tools running within a virtual machine. This is a difficult issue for two reasons. First, CPU load and usage measurement tools running within a virtual machine can observe activity only within the virtual machine. But the virtual machine itself is a set of processes that are scheduled by the host operating system and receive only a varying fraction of the host CPU. Moreover, CPU load and usage measurement algorithms generally depend on precise time measurements, enough so that the distortion of time that takes place in a virtual machine can have a sizable effect. Second and more fundamentally, it is not even clear what it should mean to measure CPU load and usage within a single virtual machine. As a simple example, suppose a virtual machine is running just one process that repeatedly computes for one second, then sleeps for one second. While the process is sleeping, the guest operating system has nothing to do (other than field timer interrupts) and spends almost all of its time in a halted state. If this were a real machine, the process's CPU usage, as well as the total CPU load, obviously would be 50%. However, a virtual machine deschedules itself whenever the guest operating system halts and does not receive any physical CPU time until the halt state ends. Thus, the process receives 100% of the physical CPU time that is actually allocated to the virtual machine, though still only 50% of the time that could potentially have been allocated to it. The situation becomes more complicated if the host machine is heavily loaded. In that case the process may receive far less than 50% of a physical CPU. Because of these issues, CPU load or idle time measured from within a virtual machine currently is not a very meaningful number. If you are running software in a virtual machine that measures and adapts to system load, you should experiment to find out how the software behaves, and you may find that you need to modify the software's measurement and adaptation algorithms. Experiments have shown that the relative CPU usage of different processes running within a virtual machine (as measured by the guest operating system) is usually approximately correct. However, these measurements can be biased if a particular process frequently causes the virtual machine to be descheduled and thus require timer interrupt catchup when the virtual machine runs again. This bias arises because guest operating systems often use statistical sampling to determine CPU usage, with samples collected from the timer interrupt handler. Similarly, because time in a virtual machine may frequently fall behind and catch up, measuring short time intervals within a virtual machine tends to produce inaccurate results. See Virtual TSC on page 8 for information on how to access the real TSC from within a virtual machine. If possible, use host CPU (and other resource) usage statistics instead of statistics measured inside a guest. For VMware ESX Server, see Knowledge Base article 1078. Statistics are also available from VMware Virtual Center. 17
Page 1 and 2: VMWARE WHITE PAPER VMware Timekeepi
Page 3 and 4: Timekeeping in VMware Virtual Machi
Page 15: Timekeeping in VMware Virtual Machi
Page 25: Timekeeping in VMware Virtual Machi

Timekeeping in VMware Virtual Machines

Create successful ePaper yourself

Delete template?

Save as template?