savestate/resuming a VBox does'nt set the time correctly on linux guests

[bauer40]

When suspending a VBox and waking it up later, the time on Linux guests is no longer correct. The time on a windows guest is set correctly

Example:

VBoxManage controlvm testdebian savestate

then wait 10 minutes, and wake up the guest again

VBoxHeadless -s testdebian

The guest will now have a 10 minute time lag, and it will not close up to the correct time. Even restarting the guest additions does not help, you have to reboot the Linux guest.

Doing the same with a windows guest seems to work - a few minutes after starting the guest, the time is set correctly.

[Frank Mehnert]

There is a trigger of currently 20 minutes. Time differences between host and guest up to 20 minutes are corrected in a smooth way. See the VBox 3.1.6 user manual section 9.10.3.

[Frank Mehnert]

Actually this is a duplicate of #4018.

[bauer40]

No, it's not a duplicate.

I paused a Debian server on VBox 3.2.8 with the latest guest additions for 10 minutes, and even 20 minutes after restarting the server the time lag is still 10 minutes.

So I can clearly state that the time difference which occures on savestate/resume is not catched up.

[Frank Mehnert]

Which VBox version are you currently using and which guest additions are installed? Please attach a VBox.log of such a session. The time adaption after pause/resume might be slow but it should work nevertheless.

You could debug this issue by doing the following:

1. Stop the VBoxService daemon in the Linux guest

   /etc/init.d/vboxadd-service stop
   

2. Start the VBoxService daemon manually in the foreground from a terminal:

   sudo -s
   /usr/sbin/VBoxService -fvvv
   

Now you can check if the daemon tries to catch up the time lag. Do savestate/restorestate and check the messages to see if the lag decreases or not.

[bauer40]

I will uplad the VBox.log in a few minutes.

Here is the output of VBoxService -fvvv before a 10 second suspend/resume

VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:52:44.291000000Z    (MinAdjust: 200 ms)
VBoxService: Guest: - 2010-09-29T06:52:44.304665000Z => -13 665 000 ns drift
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:52:54.291000000Z    (MinAdjust: 200 ms)
VBoxService: Guest: - 2010-09-29T06:52:54.304779000Z => -13 779 000 ns drift
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:53:04.291000000Z    (MinAdjust: 200 ms)
VBoxService: Guest: - 2010-09-29T06:53:04.305161000Z => -14 161 000 ns drift
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:53:14.300000000Z    (MinAdjust: 200 ms)
VBoxService: Guest: - 2010-09-29T06:53:14.314765000Z => -14 765 000 ns drift
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:53:24.301000000Z    (MinAdjust: 200 ms)
VBoxService: Guest: - 2010-09-29T06:53:24.315674000Z => -14 674 000 ns drift
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"

and after a 10 second suspend:

VBoxService: Host:    2010-09-29T06:54:44.427000000Z    (MinAdjust: 100 ms)
VBoxService: Guest: - 2010-09-29T06:54:34.365176000Z => 10 061 824 000 ns drift
VBoxService: adjtime by 10 061 824 000 ns
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:54:54.427000000Z    (MinAdjust: 100 ms)
VBoxService: Guest: - 2010-09-29T06:54:44.369431000Z => 10 057 569 000 ns drift
VBoxService: adjtime by 10 057 569 000 ns
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:55:04.427000000Z    (MinAdjust: 100 ms)
VBoxService: Guest: - 2010-09-29T06:54:54.374287000Z => 10 052 713 000 ns drift
VBoxService: adjtime by 10 052 713 000 ns
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:55:14.424000000Z    (MinAdjust: 100 ms)
VBoxService: Guest: - 2010-09-29T06:55:04.376881000Z => 10 047 119 000 ns drift
VBoxService: adjtime by 10 047 119 000 ns
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"

As you see, there is an decreasing adjtime line, but the absolute Host and Guest time do not narrow - there is still a 10 second gap.

While writing this, the ajdtime line decreases over and over again, but the absolute time does not:

VBoxService: Host:    2010-09-29T06:58:34.412000000Z    (MinAdjust: 100 ms)
VBoxService: Guest: - 2010-09-29T06:58:24.463663000Z => 9 948 337 000 ns drift
VBoxService: adjtime by 9 948 337 000 ns
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"
VBoxService: Host:    2010-09-29T06:58:44.412000000Z    (MinAdjust: 100 ms)
VBoxService: Guest: - 2010-09-29T06:58:34.467940000Z => 9 944 060 000 ns drift
VBoxService: adjtime by 9 944 060 000 ns
VBoxService: Writing guest property "/VirtualBox/GuestInfo/Net/Count" = "2"

[bauer40]

Log file of a fresh start of the VM, a suspend and a resume after 10 seconds

[Frank Mehnert]

Note the decreasing drift. The drift is the difference between guest and host. I admit that the drift decreases quite slowly but this correction factor is the default behavior of adjtime (a Linux syscall). The adjustment is only a few milliseconds per interval. Adjusting the time slowly is usually what the user wants because adjusting the time too quickly can confuse guest applications. So the slow adjustment works as designed.

Did you have a look at the user manual section ​9.12.3? Especially at the --timesync-set-threshold parameter. If you decrease this parameter to say 1000, the guest time will be synchronized by setting the absolute time if the drift is greater than 1 second.

Note that the guest additions of the next maintenance release will hard set the guest time after a savestate/resume (but not after pause/resume).

[bauer40]

OK, I took a closer look at the time difference, and I confirm that the time correction seems to be at a rate of 4ms per 10 second interval. I took this as "(close to) nothing", because it will take 250 10-second-cycles (which is 41 minutes) to close up 1 second. No wonder I did not see this. 10 seconds time lag will be cought up in about 7 hours...

OK, please close this ticket, as the problem reported does not exist.

I understand that smoothly closing a time lag is not an easy task and the clock drift might confuse applications, so I have to set the --timesync-set-threshold to match my requirement (as my applications dont care about a clock jump).

Thank you for your explainations and your patience, and sorry for the confusion I produced.