similar to: guest clock

Hi everybody! I know this is an ultraknown issue, but in my case i think it is going beyond. As you may guess my domUs clocks go faster or slower They come with the same OS (Centos 5 2.6.18-92.1.18.el5 ) but each of them have a different clock speed. Why? Dom0 does not syncronize domUs : So i watched out looking for any solution.... First attempt: /proc/sys/xen/independent_wallclock = 0

Hello, On a xenserver with several (39) domUs, we experience problems with the system clock of the domUs. The clock seems to drift away several seconds up to two minutes from the dom0 clock. We do have set independent_wallclock=0. According to the docs (i.e. http://wiki.xensource.com/xenwiki/InstallationNotes) that way domUs should use the dom0 clock, but apparently that''s not the case.

This must be documented somewhare but I checked the Xen 3.0 manual and the word "clock" doesn''t even exist in it. I checked the FAQ as well. I am running Xen 3.0.1 and an AMD64 CPU. I found that DOMUs time clock drifts ahead. I installed ntpdate and it reports to change the time but it does not. David _______________________________________________ Xen-users mailing list

Hello to all, I''ve noticed a value of 10000000 in /proc/sys/xen/permitted_clock_jitter. I''m assuming thats only checked if independent_wallclock has a value greater than 0. Does anyone know what unit the 10000000 represents? Thanks in advance Tim _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com

Hi list, one and hopefully last strange thing I figured out ist the systime of my guests. Dom0 uses ntp for time syncronisation. I set the time on my guests manually but after reboot any machine (Windows server, XP, Freebsd, even PV Machines like ubuntu) all run local time - 2 hours. /proc/sys/xen/independent_wallclock is set to 0 so actually the time should be set by dom0...(?) Any

The time appears to be perfect inside dom0, however all the domU''s tend to have a slightly faster date which gets further out of sync every day. I''m currently using Xen 3.0.3 with Gentoo Linux, under 3.0.2 I had no problems with domU clocks. Are there any known issues which could cause this? I''d strongly prefer not to run ntpd in every domU, having all domU clocks in

While in the upstream kernel I''m unable to find any use of XENPF_settime (and the DOM0_SETTIME alias of it) at all, in the 2.6.18 tree (and the forward ports of it) the function gets used only when ntp_synced() returns true (and - that''s minor - when independent_wallclock is not set). It would however seem to me that this doesn''t cover the case where the host clock gets

Hello ! Just a quick question about time synchronization between xen dom0 and domUs... We''re running Xen 3.1 64-bit, with 32 and 64 bits linux guests. It''s up since 89 days and the domU''s time is around 5 minutes behind the dom0, which is updated via ntpdate... Any idea why it doesn''t sync the guests even that /proc/sys/xen/independent_wallclock is 0 ?

I don''t want my dom0 to update the clock in my HVM domU. I''ve already disabled network-based time synchronization inside the HVM. I''ve tried setting /proc/sys/xen/independent_wallclock=1 and then restarting xend, but the guest still gets the correct time. Any ideas on how to accomplish this? Steve Brueckner, ATC-NY _______________________________________________

Hello All, Consider a CentOS-5.1 Xen server (2.6.18-53.1.4.el5xen) hosting two domains running CentOS-5.1 (2.6.18-53.1.4.el5). One domain has a fairly accurate clock, the other domain has a clock that gains ungodly amounts of time, roughly one minute every two or three minutes. For a fix, one suggestion is to run this command in DomU: echo 1 > /proc/sys/xen/independent_wallclock This

My dom0 systems all run ntpd to keep their clock synchronized, and I just noticed my domU systems all have a little different clock, and that happens right after boot. IE, right after xm create domU, I did a quick''n''dirty check this way: luca@dom0 ~ $ ssh domU "uptime; date"; date Password: 16:11:31 up 0 min, 0 users, load average: 0.43, 0.12, 0.04 Thu Dec 8

libxl__domain_build_info_setdefault may be called several times, so rtc_timeoffset can''t be setted in it. Move rtc_timeoffset setting logic to libxl__build_pre. Reported-by: Teck Choon Giam <giamteckchoon@gmail.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn> --- tools/libxl/libxl_create.c | 9 ---------

Implement "rtc_timeoffset" and "localtime" options compatible as xm. rtc_timeoffset is the offset between host time and guest time. localtime means to specify whether the emulted RTC appears as UTC or is offset by the host. Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Lin Ming <mlin@ss.pku.edu.cn> --- docs/man/xl.cfg.pod.5 | 8 ++++++++

Hi Thomas, >----Messaggio originale---- >Da: thomas@kupper.org >Data: 22/01/2010 10.48 >A: "Leszek Ciesielski"<skolima@gmail.com> >Cc: "linux-btrfs"<linux-btrfs@vger.kernel.org> >Ogg: Re: mount command not honoring rootflags passed > > >On 22 Jan 2010, at 10:40, Leszek Ciesielski wrote: > >> On Fri, Jan 22, 2010 at 10:30 AM,

Hey, I have rather new installation of xen, dom0 is running ntpd and is perfectly in time. All domU''s are ~23s in future. Running ntpd on the domU''s seem to have no effect, /proc/sys/xen/independent_wallclock appears to have no effect. I''m running xen-unstable and 2.6.16-rc4 in AMD64 box. Any tip would be appricated. Thanks, -- ++ytti

Package: xen-utils-common Version: 4.4.0-5 Severity: important Tags: patch Hello, xen-init-list fails to parse output of xen list -l when using XM toolstack. Therefore, /etc/init.d/xendomains stop fails to shutdown any guests still running on shutdown. xen-init-list fails with the following message: /usr/lib/xen-common/bin/xen-init-list Traceback (most recent call last): File

Hello everyone! I been observing some peculiar time drift on my Xen domains (dom0 and domUs). The time (as returned by timeofday) on my domains drifts at an almost steady rate from the real time ( as read from the time stamp counter ). The drift is so constant that it makes me think there should be some simple explanation for it in the way Xen keeps time. Some info about my set up: guest OS:

On 02/16/2018 08:37 AM, Volo M. wrote: > Hello techs, > > We used XL toolkit for Xen hypervisor for starting Windows hvm VMs and the > option rtc_timeoffset worked perfectly with XL. It helped us to set correct > Timezone time/offset for Windows HVM VMs from inside virtual_machine xen config. > > For example: > Below option WORKS perfectly with XL toolkit. >

Jim, Thanks a lot for your confirmation. Could you also please explain if the issue can be ever fixed, if it's possible to make some patch to fix it? Is it libvirt-specific bug or Libvirt development team rely on some other developers of libxl code...etc? I'm asking because XL tools works fine and I wonder if XL uses the same libxl libraries , doesn't it? Lastly is the issue is going

Package: xen Severity: important Version: 4.0.1-1 The Xen documentation and Xen Debian wiki describes using independent_wallclock to sync domU clocks against the dom0 clock http://docs.vmd.citrix.com/XenServer/4.0.1/guest/ch04s06.html http://wiki.debian.org/Xen#Possible_problems_and_bugs-1 This sysctl appears to have gone away with squeeze, but the documentation is not updated Time drift is