Ticket #7785 (closed defect: fixed)
Guest clock drift under Solaris host
|Reported by:||joe42||Owned by:|
|Version:||VirtualBox 3.2.8||Keywords:||clock drift synchronization time|
I run a Solaris 10 x86 host (quad core, 32G memory) with currently 7 guest VMs, some single some dual processor, some Windows some Linux.
The host CPU is usually loaded between 50 and 70% CPU, only around 50% of the memory is used. The host CPU is only rarely maxed out.
All guests have up to date guest additions installed, activated and running. The guest clock timezones are set correctly and the VM option for clock UTC/local is also set correctly for each of the VMs. The guests do not run NTP or Windows Time Service.
All guests have significant problems with clock synchronization. Some of them run fine for days or even a week, then suddenly they are 15-20 minutes off. They probably drift over time, but I only notice when the clocks have drifted so far that Kerberos authentication stops working.
If I shut down the guest extensions and run 'VBoxService -fvvv', I see that clock sync seems to work just fine:
VBoxService: Host: 2010-12-03T12:04:31.456000000Z (MinAdjust: 200 ms) VBoxService: Guest: - 2010-12-03T12:05:38.195632000Z => -66 739 632 000 ns drift ... VBoxService: Host: 2010-12-03T12:04:51.467000000Z (MinAdjust: 200 ms) VBoxService: Guest: - 2010-12-03T12:05:58.196582000Z => -66 729 582 000 ns drift ...
If I let it run like this and go back to see the output when the clock has drifted too far, the output still looks completely reasonable, only the difference between Host and Guest clock is 15-20 minutes and adjustments are still computed correctly.
It looks to me like the guest clock is simply too unstable for the gradual adjustments to be able to keep it reasonably in sync. Since I see this with both Windows and Linux guests, I am assuming that this is a Solaris host problem.
Is there anything I can do to troubleshoot this further?
I know the VB is not completely up to date, but the changelogs say nothing about time synchronization that seems relevant to this issue.