Comment 17 for bug 1297218

In the production setup, we have two KVM servers. According to NTP, their clock corrections are:
server-a: -147.2 ppm
server-b: -142.1 ppm

NTP is running on the guest as well, and it's drift-rate matches whichever server the guest is running on, after NTP has had time to adjust.

The length of time that the guest freezes is exactly the time since the last migration, times the NTP rate of the server it is on.

I did two migrations, one at 11h30, and another at 14h10, so 9600 seconds between migrations.
The freeze after the second migration was 1.369s (as reported by "ntpdate -q server-a", right after the migration).
This 9600 seconds, times the 142.1 ppm of the server it was on, would predict a freeze of 1.364 s.

I will set up a pair of machines with the qemu PPA later this week.