Clock in clockvm is not udpated after resume

[marmarek]

Reported by joanna on 30 Jan 2012 15:42 UTC
It keeps showing the time delayed by the time delta = time_of_resume - time_of_suspend. This really sucks.

Migrated-From: https://wiki.qubes-os.org/ticket/435

[marmarek]

Comment by joanna on 31 Jan 2012 22:24 UTC
So, the problem is that all the VM's are paused before suspend, and (probably) as a result their clocks on resume are still showing the time from the moment of suspending them. Dom0 is the only exception to this rule -- its clock gets properly updated from RTC upon resume.

Now, if we try to update Dom0's clock using our clockvm, this will almost for sure result in the Dom0 clock being update with the wrong time, as the clockvm would likely still not resync its clock via ntp (and thus would be showing the time from the suspend moment). Later, we worsen the situation by further syncing all other VMs clock with the (now completely wrong) Dom0's clock.

The way to solve this is to:

1. sync all the VMs clock from Dom0's clock upon resume,
2. manually run ntpdate in clockvm from Dom0 and, only after we check the exit code, sync Dom0 clock, and resync other VMs too.

[marmarek]

Comment by joanna on 31 Jan 2012 22:24 UTC
So, the problem is that all the VM's are paused before suspend, and (probably) as a result their clocks on resume are still showing the time from the moment of suspending them. Dom0 is the only exception to this rule -- its clock gets properly updated from RTC upon resume.

Now, if we try to update Dom0's clock using our clockvm, this will almost for sure result in the Dom0 clock being update with the wrong time, as the clockvm would likely still not resync its clock via ntp (and thus would be showing the time from the suspend moment). Later, we worsen the situation by further syncing all other VMs clock with the (now completely wrong) Dom0's clock.

The way to solve this is to:

1. sync all the VMs clock from Dom0's clock upon resume,
2. manually run ntpdate in clockvm from Dom0 and, only after we check the exit code, sync Dom0 clock, and resync other VMs too.

[marmarek]

Comment by marmarek on 1 Feb 2012 16:49 UTC
After resume new qvm-sync-clock is called in background, which:

1. wait at most 30s for network in NetVM conneced with ClockVM (ClockVM can be separate VM...)
2. After that - sync clock using ntpdate and if succeed - sync dom0 and VMs clock based on it.

If above failed (eg because no network connection), VMs clock is synced based on dom0 clock. However this will happen after timeout - about 30s in total - so for this time period, VMs will have wrong time after resume.

http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=b87fff44c4373787bc9205e5df27b576a681ed31

[marmarek]

Comment by marmarek on 1 Feb 2012 16:49 UTC
After resume new qvm-sync-clock is called in background, which:

1. wait at most 30s for network in NetVM conneced with ClockVM (ClockVM can be separate VM...)
2. After that - sync clock using ntpdate and if succeed - sync dom0 and VMs clock based on it.

If above failed (eg because no network connection), VMs clock is synced based on dom0 clock. However this will happen after timeout - about 30s in total - so for this time period, VMs will have wrong time after resume.

http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=b87fff44c4373787bc9205e5df27b576a681ed31