What happens when you sync your hardware clock in a VM?

Question

This thought occured to me and while not an actual problem I'm curious to know. When a virtual machine syncs it's clock with the hardware clock does that sync the hardware clock of the host? Change to software clock of the host? Does the time difference between the host and software get stored in a VM's file? Does nothing at all happen?

I know this is a random and seemingly meaningless question but I like to understand what goes on under the hood of all my systems. The direct use case for me is NTPD's SYNC_HWCLOCK in a linux Xen VM but I'm curious about other virtualization platforms as well since they all operate differently.

Answer 1

In VMWare at least the hardware clock that the VM's OS sees is no more accurate than its own software clock as that clock is based on counting interrupts and ticks and such from the virtual hardware so is susceptible to skew when the VM or its host are under load.

The VMWare tools clock-sync does not sync against the hardware clock as presented as the clock in the virtual hardware - it talks over the VM/host boundary to the host parts of VMWare (which sync it with the OS clock on the host, not the hardware clock).

Other virtualisation solutions will work differently, of course. I have not used Xen enough to know specifically how it behaves in this area. Some VM solutions (including user-mode schemes like UML and arrangements that partition the existing kernel rather than actually virtualising the hardware) will use the host OS clock as the VM's clock directly so all you need to do is keep the host clock in sync.

In general, even on physical hardware, I would not have NTP use the hardware clock as a reference.

Also, if you are using NTP inside a VM make sure you have "tinker panic 0" at the top of your ntp.conf so that the ntp daemon doesn't give up and stop trying to slide the clock back to the right place when it sees a large clock skew caused by a recent glut of load on the VM/host.

Edit: missed a bit... Also, if using Linux in your VMs make sure you use a modern "tickless" kernel - these are said to be far less susceptible to clock skew problems. Most modern Linux releases use this kernel option by default anyway, as it can reduce CPU power consumption.

Answer 2

No, it does not sync the hardware or the software clock of the host. A VM's hardware clock is virtual and is synced (at least with ESX) with the host during boot. After that, the VM maintains it's own time. For VMware it is best to run ntpd in a VM, for Xen I do not know, but I assume it's the same.

Answer 3

I think it's the "hardware" clock of the VM; it'll get simulated along with the rest of the motherboard. There's a separate option in VMWare tools to sync the VM's hardware clocks with that of their host, which I'd recommend you use, as well as getting the hosts to sync with an external NTP server, as that'll save the need to configure NTP on all your VMs. I don't know if it's just us, but we didn't do this when we implemented our VMWare environment, and suffered all sorts of time-related problems and general weirdnesses before we got it sorted out.

Answer 4

When trying to think logically you may find:

• When there are multiple VMs running and each one updating the host clock, wouldn't that be an overkill (independent from the fact that each VM may have a slightly different time, causing "micro time jitter" on the host)?

• What should happen when two VMs try to set the host's clock, and one VM has a completely wrong time (maybe even for attacking purposes)?

• When a VM would be allowed to set the host's clock, wouldn't that break fundamental security assumptions like host being protected from VM, and one VM being protected from another VM? So should there be an API in the VM to set the host's hardware or software clock?

• With no API being available to set the host's clock, should a VM be allowed to access the hardware of the host (so set the clock chip directly)? I guess: No, for security reasons.