This bug has been copied from bug #521025 and has been proposed to be backported to 5.4 z-stream (EUS).
Hi Gleb The time drift after Live migration still exist. it is not so serious though Is it acceptable in the patch ? Intel Host Window 2k8 standard (64bits) +--------+--------------------+--------------------+--------------------+ | | 105.el5_4.2 | 105.el5_4.3 (1) | 105.el5_4.3 (2) | +--------+--------------------+--------------------+--------------------+ | boot | - | - | - | +--------+--------------------+--------------------+--------------------+ | 10 mins| 1.242648 | 0.073379 | - | +--------+--------------------+--------------------+--------------------+ | 20 mins| 2.631598 | 0.142490 | - | +--------+--------------------+--------------------+--------------------+ | 30 mins| 6.893323 | 0.160291 | - | +--------+--------------------+--------------------+--------------------+ | reboot | -0.363271 | -0.448923 | 1.060342 | +--------+--------------------+--------------------+--------------------+ | 10 mins|1.947018(after5min) | -0.357876 | 1.015323 | +--------+--------------------+--------------------+--------------------+ | 20 mins| - | -0.463631 | 0.986450 | +--------+--------------------+--------------------+--------------------+ | 30 mins| - | -0.373732 | 1.103563 | +--------+--------------------+--------------------+--------------------+ |migrate | 19.764600 | 1.487834 | 9.449639 | +--------+--------------------+--------------------+--------------------+ | 10 mins| - | 1.527333 | 9.441567 | +--------+--------------------+--------------------+--------------------+ | 20 mins| - | 1.615365 | 9.414171 | +--------+--------------------+--------------------+--------------------+ | 30 mins| - | 1.638770 | 9.560496 | +--------+--------------------+--------------------+--------------------+ AMD host Window XP +--------+--------------------+--------------------+ | | 105.el5_4.2 | 105.el5_4.3(1) | +--------+--------------------+--------------------+ | boot | 0.540955 | - | +--------+--------------------+--------------------+ | 10 mins|2.077061 (after5min)| 0.073379 | +--------+--------------------+--------------------+ | 20 mins| - | 0.142490 | +--------+--------------------+--------------------+ | 30 mins| - | 0.160291 | +--------+--------------------+--------------------+ | reboot | 5.455597 | 0.826407 | +--------+--------------------+--------------------+ | 10 mins| 12.740380 | 0.765594 | +--------+--------------------+--------------------+ | 20 mins| - | 0.873515 | +--------+--------------------+--------------------+ | 30 mins| - | 0.791465 | +--------+--------------------+--------------------+ |migrate | 23.421626 | 10.750137 | +--------+--------------------+--------------------+ | 10 mins| 27.744350 | 10.654840 | +--------+--------------------+--------------------+ | 20 mins| - | 10.639801 | +--------+--------------------+--------------------+ | 30 mins| - | 10.949871 | +--------+--------------------+--------------------+
This patch has nothing to do with migration. Migration is different issue that has (or should have) different BZ. Don't test this patch with migration.
(In reply to comment #6) > Hi Gleb > The time drift after Live migration still exist. it is not so serious though > Is it acceptable in the patch ? > > Intel Host > Window 2k8 standard (64bits) [root@dhcp-66-70-46 ~]# grep "model name" /proc/cpuinfo model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz [root@dhcp-66-70-46 ~]# free -m total used free shared buffers cached Mem: 7727 7681 46 0 71 239 -/+ buffers/cache: 7369 357 Swap: 7959 2472 5487 Host is loaded. for cpu in `seq 0 3`; do taskset -c $cpu yes >/dev/null & ; done CLI : /usr/libexec/qemu-kvm -smp 2 -m 4G -drive file=/data/images/win2008-64-virtio.raw,if=ide -net nic,macaddr=00:15:00:62:AF:02,model=virtio -net tap -vnc :12 -name t77 -monitor stdio -rtc-td-hack -startdate now -usbdevice tablet > > AMD host > Window XP [root@dhcp-66-70-48 ~]# grep "model name" /proc/cpuinfo model name : AMD Phenom(tm) 9600B Quad-Core Processor model name : AMD Phenom(tm) 9600B Quad-Core Processor model name : AMD Phenom(tm) 9600B Quad-Core Processor model name : AMD Phenom(tm) 9600B Quad-Core Processor [root@dhcp-66-70-48 ~]# free -m total used free shared buffers cached Mem: 7590 4993 2596 0 59 658 -/+ buffers/cache: 4275 3315 Swap: 7891 41 7850 Host is loaded. for cpu in `seq 0 3`; do taskset -c $cpu yes >/dev/null & ; done CLI :/usr/libexec/qemu-kvm -smp 2 -m 4G -cpu qemu64,+sse2 -startdate now -drive file=/mnt/winXP-32-virtio-back.raw,media=disk,if=ide -name host2guest -usbdevice tablet -net nic,vlan=0,macaddr=00:55:18:02:B2:fe,model=virtio -net tap,vlan=0,script=/etc/qemu-ifup -vnc :2 -monitor stdio -notify all -rtc-td-hack ========= steps: A : 1 start vm 2 synchronize guest's time with host ( ntpdate.exe -b $HOST ) 3 have the guest ran 30mins. query the offset. ( ntpdate.exe -q $HOST ) B : 1 synchronize guest's time with host ( ntpdate.exe -b $HOST ) 2 restart guest. 3 have the guest ran 30mins. query the offset. ( ntpdate.exe -q $HOST ) C : 1 synchronize guest's time with host ( ntpdate.exe -b $HOST ) 2 implement migration ( src and dst are the same host ) 3 have the guest ran 30mins. query the offset. ( ntpdate.exe -q $HOST )
(In reply to comment #7) > This patch has nothing to do with migration. Migration is different issue that > has (or should have) different BZ. Don't test this patch with migration. New bug about migration is reported : https://bugzilla.redhat.com/show_bug.cgi?id=523457
Created attachment 362296 [details] 521794 result Test more guest on AMD and Intel Host . Attached is the result . and the more information can be found from : http://focus.bne.redhat.com/~lihuang/521974/
compared with the result in result in comment#6. the rtc-td-hack take effect in kvm-83-105.el5_4.4
Hi gleb. I noticed sometimes window guest's time is 1.5~2 seconds later the host's after starting It is acceptable ?
Is this acceptable I don't know. PM should decide. But this is known problem. During boot windows keeps rtc interrupt masked, so it miss many interrupts since we don't redeliver interrupt that was issued while irq was masked by a guest.
Yes . have a bug for rhel guest.(523478) but don't if we have a workaround for window guest . so in this bz. we concern about if rtc-td-hack take effect or not . right ?
yes.(In reply to comment #15) > Yes . have a bug for rhel guest.(523478) > but don't if we have a workaround for window guest . > > so in this bz. we concern about if rtc-td-hack take effect or not . right ? yes
Created attachment 362851 [details] result in kvm-83-105.el5_4.7
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1465.html