--timesync-set-on-restore syncs time up to 10 seconds after snapshot restore

[insecure]

I have a Linux guest(additions 4.0.16) and a Windows host(vbox 4.0.16). The guest service is started via:

/usr/sbin/vboxguest-service -f -vvvvv --disable-vminfo --disable-cpuhotplug --disable-vmstats --disable-automount --disable-memballoon --timesync-set-threshold 1000 --timesync-set-on-restore 1

If I restore a snapshot of this machine, even one that is 7 days old, the time is not synced on restore. ~10 seconds (timesync-interval?) after resuming the VM, the vboxguest-service outputs "The VM session ID changed, forcing resync." and time is actually synced.

This causes trouble when working with certificates that are generated after taking the snapshot, so for some use cases this is really annoying.

[Frank Mehnert]

So which bug are you actually reporting? That it takes up to 10 seconds until the time is synched? Actually it can take from 0 ... 10 seconds because it depends on the application start when the VM was suspended. If this interval is too long for you then you should decrease the time sync interval, see the user manual how this could be done.

And no, there is no signaling mechanism, the interface is kept simple and the guest R3 application has to poll if the session state changed and has to re-synchronize the time then.

[insecure]

Replying to frank:

So which bug are you actually reporting? That it takes up to 10 seconds until the time is synched? Actually it can take from 0 ... 10 seconds because it depends on the application start when the VM was suspended. If this interval is too long for you then you should decrease the time sync interval, see the user manual how this could be done.

Actually, yes, I think it is false behaviour that the guest time is not synced directly after restoring the VM snapshot. For me, the name "--timesync-set-on-restore" indicates that the guest time is set to the host time after restoring from a snapshot. What else does "--timesync-set-on-restore" signify?

Setting the time sync interval to e.g. 1 second would mean, that the time is always synced after 1 second, correct? I think this is unnecessary waste of resources, as time drift is usually not that bad.

[Frank Mehnert]

As I said, this is an implementation detail. And as I explained, the time actually 'is' synchronized after the guest was restored from a snapshot. We might have a different expectation what 'on-restore' means but in comparison with the long runtime of a VM, 10 seconds (maximum) is not a long time.
If you really need that 1 second interval, I don't think this would induce a lot of overhead.

[insecure]

Replying to frank:

As I said, this is an implementation detail. And as I explained, the time actually 'is' synchronized after the guest was restored from a snapshot. We might have a different expectation what 'on-restore' means but in comparison with the long runtime of a VM, 10 seconds (maximum) is not a long time.
If you really need that 1 second interval, I don't think this would induce a lot of overhead.

OK, that's correct, the time is synced after restore. That would mean to me, that no timesync is done after restore if I set "--timesync-set-on-restore 0", i.e. the timesync service does only work when this value is set to 1. If that is so, I wonder what was the intention behind implementing this feature.

[Frank Mehnert]

I you would mind looking at the user manual then you would find how it works. With timesync-set-on-restore 0, the synchronization is done smoothly, that is, at every polling interval the service tries to get the guest timer closer to the host time but always only bit little steps. Otherwise (timesync-set-on-restore 1), the value is adapted smoothly if the difference between host and guest is below a certain limit and immediately set if the difference is above that difference.

[insecure]

Replying to frank:

I you would mind looking at the user manual then you would find how it works. With timesync-set-on-restore 0, the synchronization is done smoothly, that is, at every polling interval the service tries to get the guest timer closer to the host time but always only bit little steps. Otherwise (timesync-set-on-restore 1), the value is adapted smoothly if the difference between host and guest is below a certain limit and immediately set if the difference is above that difference.

Yes, I know, I read the manual. And this is the behaviour I expect to be influenced by "--timesync-set-threshold". So if the behaviour for "timesync-set-on-restore" described in the manual is really expected, then this ticket should be rejected.

[Frank Mehnert]

The behavior is expected and it works as designed. The timesync-set-threshold parameter defines only the guest/host difference when the time is adapted not smoothly but by setting the time directly.

for (;;)
{
   diff = time_guest() - time_host();
   if (abs(diff) > threshold)
     set_time(time_host);
   else
     adapt_time_smoothly_one_step(time_guest, time_host);
   wait_for_some_time_usually_10_seconds();
}

But I will leave that ticket open as I understand your intention. Though I don't think it is important enough do justify a complete redesign of the time adaption mechanism.