Hi all,
I'm having issue with my Centos 5.1 /Xen installation. I'm having 2 dom0 running 2.6.18-53.1.4.el5xen (x86_64). These two dom0 are connected to a SAN. These two dom0 hosts multiple domU like Centos 4.5 (2.6.9-55.0.9.ELxenU) and Centos 5.1 (2.6.18-53.1.4.el5xen). These two dom0 run ntpd to synchronize dom0 time. When i start a virtual machine on the first dom0 all seems good, the domU time is like the dom0 time. The problem appears when i migrate the domU to another dom0. After the migration, the time in domU on the new dom0 is totally false (we can have more than one day of desynchronisation) and the time on the domU seems to be blocked (the clock indicates always the same time ). In the xend Logs we can't see any error message with the debug mode.
The solution for this moment is to restart the domU in the new dom0 to be synchronized again. We manage a lot of authentications services like CAS or Shibboleth which uses timestamp for security validation and this problem is very annoying for us.
Anyone has encountered this problem ? Any idea how to solve it ?
Thanks for your help.
Regards
Fred
On Jan 14, 2008 1:40 PM, Frederic SOULIER frederic.soulier@univ-tlse1.fr wrote:
I'm having issue with my Centos 5.1 /Xen installation. I'm having 2 dom0 running 2.6.18-53.1.4.el5xen (x86_64). These two dom0 are connected to a SAN. These two dom0 hosts multiple domU like Centos 4.5 (2.6.9-55.0.9.ELxenU) and Centos 5.1 (2.6.18-53.1.4.el5xen). These two dom0 run ntpd to synchronize dom0 time. When i start a virtual machine on the first dom0 all seems good, the domU time is like the dom0 time. The problem appears when i migrate the domU to another dom0. After the migration, the time in domU on the new dom0 is totally false (we can have more than one day of desynchronisation) and the time on the domU seems to be blocked (the clock indicates always the same time ). In the xend Logs we can't see any error message with the debug mode.
The solution for this moment is to restart the domU in the new dom0 to be synchronized again. We manage a lot of authentications services like CAS or Shibboleth which uses timestamp for security validation and this problem is very annoying for us.
Anyone has encountered this problem ? Any idea how to solve it ?
Hi Frederic,
I've also seen this issue (CentOS 5.1, 64bit in Intel Xeons using PVM). I've also found a solution to it.
Put this in /etc/sysctl.conf :
xen.independent_wallclock = 1
and then execute sysctl.
What happens then is that the domU will do it's own timekeeping and no longer follow the dom0. Now this also means that you need to run a ntpd inside the domU to make sure it's clock keeps syncronised.
That solved it for me. After migrations the clock kept running and remained in sync.
Regards, Tim
Tim Verhoeven a écrit :
On Jan 14, 2008 1:40 PM, Frederic SOULIER frederic.soulier@univ-tlse1.fr wrote:
I'm having issue with my Centos 5.1 /Xen installation. I'm having 2 dom0 running 2.6.18-53.1.4.el5xen (x86_64). These two dom0 are connected to a SAN. These two dom0 hosts multiple domU like Centos 4.5 (2.6.9-55.0.9.ELxenU) and Centos 5.1 (2.6.18-53.1.4.el5xen). These two dom0 run ntpd to synchronize dom0 time. When i start a virtual machine on the first dom0 all seems good, the domU time is like the dom0 time. The problem appears when i migrate the domU to another dom0. After the migration, the time in domU on the new dom0 is totally false (we can have more than one day of desynchronisation) and the time on the domU seems to be blocked (the clock indicates always the same time ). In the xend Logs we can't see any error message with the debug mode.
The solution for this moment is to restart the domU in the new dom0 to be synchronized again. We manage a lot of authentications services like CAS or Shibboleth which uses timestamp for security validation and this problem is very annoying for us.
Anyone has encountered this problem ? Any idea how to solve it ?
Hi Frederic,
I've also seen this issue (CentOS 5.1, 64bit in Intel Xeons using PVM). I've also found a solution to it.
Put this in /etc/sysctl.conf :
xen.independent_wallclock = 1
and then execute sysctl.
What happens then is that the domU will do it's own timekeeping and no longer follow the dom0. Now this also means that you need to run a ntpd inside the domU to make sure it's clock keeps syncronised.
That solved it for me. After migrations the clock kept running and remained in sync.
Regards, Tim
Hi Tim,
Thanks for your response. Using ntp directly in my domU seems to solve my problems :-)
My last question is about the source problem. Before we used Centos 5.0 with Xen in the same configuration and all was ok. The problem appears after the Centos 5.1 upgrade ( Xen was also upgraded from 3.0 to 3.1 in this release). Anyone known if this problem is local to my configuration or if it could be a bug in the new release ?
Regards
Fred
-
Frederic SOULIER -
Tim Verhoeven