https://bugzilla.novell.com/show_bug.cgi?id=745603 https://bugzilla.novell.com/show_bug.cgi?id=745603#c Charles Arnold changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carnold@suse.com, | |jbeulich@suse.com AssignedTo|jdouglas@suse.com |carnold@suse.com QAContact|qa@suse.de |jdouglas@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=745603 https://bugzilla.novell.com/show_bug.cgi?id=745603#c2 Wolfgang Rosenauer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|wolfgang@rosenauer.org | --- Comment #2 from Wolfgang Rosenauer 2012-02-13 19:51:37 UTC --- (In reply to comment #1)

For fully virtualized guests, each one needs to point at a common NTP server in order to stay in sync. Para-virtualized guests get their time from dom0 unless someone has set /proc/sys/xen/independent_wallclock within the guest.

Sorry, I didn't mention that. I only use para-virtualized openSUSE guests and had independent_wallclock set to 0 (disabled / default). In exactly that setup the time was off around 7 minutes in every guest compared to the Dom0.

If the fully virtualized guests still have a problem even pointing at an NTP server, then trying the following may solve the problem.

I've setup NTP on every guest now because I needed a correct time. Does your following description only apply to full virtualization?

1. Edit the guests menu.lst file and on the kernel line add: notsc divider=10 Reboot the guest after making the change.

2. The openSUSE 11.4 dom0 uses Xen 4.0.x which has a new guest configuration file option called tsc_mode. This can be used on a per domain basis and allows for the following values. The non-default choices for tsc_mode are: - tsc_mode=1 (always emulate). All rdtsc instructions are emulated; - tsc_mode=2 (never emulate). This is the same as prior to Xen 4.0. - tsc_mode=3 (PVRDTSCP). High-TSC-frequency apps may be paravirtualized (modified) to obtain both correctness and highest performance. If tsc_mode is left unspecified (or set to tsc_mode=0), a hybrid algorithm is utilized to ensure correctness while providing the best performance possible.

Please report your results.

As written above I only have para-virtualized guests so should I try anything with the tsc_modes at all? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=745603 https://bugzilla.novell.com/show_bug.cgi?id=745603#c4 Jan Beulich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |wolfgang@rosenauer.org --- Comment #4 from Jan Beulich 2012-02-14 10:53:23 UTC --- Is the host perhaps having its RTC off by a couple of minutes (which gets corrected eventually be NTP when the daemon starts)? If so, this ought to be fixed in 12.1 (and double checking there would be a good idea anyway). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=745603 https://bugzilla.novell.com/show_bug.cgi?id=745603#c6 Jan Beulich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |wolfgang@rosenauer.org --- Comment #6 from Jan Beulich 2012-02-14 11:59:03 UTC --- Hmm, showing a single time stamp (obtained via a utility that one would first have to look at the source code to determine whether this really returns what is stored in the RTC) doesn't tell anything to me. What I'd want to know is whether - in BIOS setup, the clock is correct compared to whatever "real" clock you normally compare to (7 minutes being large enough) - during boot, no adjustment is being made to the host clock (a number of wall clock time stamps are written to /var/log/boot.msg) - at run time, Dom0 and DomU clocks are different. Playing with the RTC clock in BIOS setup (i.e. setting it off a few more minutes) may also help understand where the problem originates from - after all it being consistently 7 minutes (which no-one else observes) suggests that this is something specific to your system or setup. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=745603 https://bugzilla.novell.com/show_bug.cgi?id=745603#c8 Charles Arnold changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |INVALID --- Comment #8 from Charles Arnold 2012-02-15 15:58:50 UTC --- (In reply to comment #7)

I cannot deliver the information in that case as I have no hardware access to the system as it's a rented Rootserver at some hosting provider. I also cannot shutdown several production machines to reboot the host. As I could solve the issue by running NTP on every guest and you say I'm the only one where it happens apparently there's nothing I can do here.

Without hardware access I think we've done all we can. Thanks for your help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.