I am having great difficulty to maintain guest OS time. Here is my environment. Hardware: Intel Woodcrest processor. Xen: 3.0.3 Xen OS: Red Hat Enterprise 4 Update 3, x86_64 version Guest OS: configuration is pretty standard. Please see the end of email. Guest OS: Red Hat Enterprise 4 Update 3, x86_64, with everything installed, ntpd not running. /proc/sys/xen/independent_wallclock = 0 /proc/sys/xen/permitted_clock_jitter = 10000000 In just 2 days 19 hours, the clock is off by more than 10 hours (faster). So, the time has completely gone crazy. In the dmesg, there is one line is telling me the time source is not reliable. Maybe the time emulation on Xen is not reliable at all.>>>Your time source seems to be instable or some driver is hogginginterupts I have tried to change independent_wallclock to 1 and started ntpd and it did not help. The ntpd seems refused to synchronize with a reliable time source. I am not really good at debugging ntpd. But, the ntpq/association is telling me either the client itself is rejecting the time source or the time source is rejecting the client. I think it is the first one. [root@scnbemux050 ~]# ntpq ntpq> associations ind assID status conf reach auth condition last_event cnt ========================================================== 1 52908 9014 yes yes none reject reachable 1 2 52909 9014 yes yes none reject reachable 1 3 52910 9014 yes yes none reject reachable 1 I installed RH EL4 update 3, x86 version of OS on the same Xen machine and I did NOT see the problem, at least ntpd worked, even thought frequent (large) time adjustment is needed. Does anyone have encountered this problem? If you do, how did you solve the problem? Thanks Sam # -*- mode: python; -*- #========================================================================== # Python configuration setup for ''xm create''. # This script sets the parameters used when a domain is created using ''xm create''. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. #========================================================================== import os, re arch = os.uname()[4] if re.search(''64'', arch): arch_libdir = ''lib64'' else: arch_libdir = ''lib'' #----------------------------------------------------------------------- ----- # Kernel image file. kernel = "/usr/lib/xen/boot/hvmloader" # The domain build function. HVM domain uses ''hvm''. builder=''hvm'' # Initial memory allocation (in megabytes) for the new domain. # # WARNING: Creating a domain with insufficient memory may cause out of # memory errors. The domain needs enough memory to boot kernel # and modules. Allocating less than 32MBs is not recommended. memory = 4096 # Shadow pagetable memory for the domain, in MB. # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. shadow_memory = 64 # A name for your domain. All domains must have different names. name = "el4u3_64" # 128-bit UUID for the domain. The default behavior is to generate a new UUID # on each call to ''xm create''. #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9" #----------------------------------------------------------------------- ------ # the number of cpus guest platform has, default=1 vcpus=4 # enable/disable HVM guest PAE, default=0 (disabled) pae=1 # enable/disable HVM guest ACPI, default=0 (disabled) acpi=1 # enable/disable HVM guest APIC, default=0 (disabled) apic=1 # List of which CPUS this domain is allowed to use, default Xen picks #cpus = "" # leave to Xen to pick #cpus = "0" # all vcpus run on CPU0 #cpus = "0-3,5,^1" # run on cpus 0,2,3,5 # Optionally define mac and/or bridge for the network interfaces. # Random MACs are assigned if not given. #vif = [ ''type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=ne2k_pci'' ] # type=ioemu specify the NIC is an ioemu device not netfront vif = [ ''type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=pcnet'' ] #----------------------------------------------------------------------- ----- # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. disk = [ ''phy:/dev/sdb1,ioemu:hda,w'', '',hdc:cdrom,r'' ] #----------------------------------------------------------------------- ----- # Configure the behaviour when a domain exits. There are three ''reasons'' # for a domain to stop: poweroff, reboot, and crash. For each of these you # may specify: # # "destroy", meaning that the domain is cleaned up as normal; # "restart", meaning that a new domain is started in place of the old # one; # "preserve", meaning that no clean-up is done until the domain is # manually destroyed (using xm destroy, for example); or # "rename-restart", meaning that the old domain is not cleaned up, but is # renamed and a new domain started in its place. # # The default is # # on_poweroff = ''destroy'' # on_reboot = ''restart'' # on_crash = ''restart'' # # For backwards compatibility we also support the deprecated option restart # # restart = ''onreboot'' means on_poweroff = ''destroy'' # on_reboot = ''restart'' # on_crash = ''destroy'' # # restart = ''always'' means on_poweroff = ''restart'' # on_reboot = ''restart'' # on_crash = ''restart'' # # restart = ''never'' means on_poweroff = ''destroy'' # on_reboot = ''destroy'' # on_crash = ''destroy'' #on_poweroff = ''destroy'' #on_reboot = ''restart'' #on_crash = ''restart'' on_crash = ''preserve'' #========================================================================== # New stuff device_model = ''/usr/'' + arch_libdir + ''/xen/bin/qemu-dm'' #----------------------------------------------------------------------- ------ # boot on floppy (a), hard disk (c) or CD-ROM (d) # default: hard disk, cd-rom, floppy boot="dac" #----------------------------------------------------------------------- ------ # write to temporary files instead of disk image files #snapshot=1 #----------------------------------------------------------------------- ----- # enable SDL library for graphics, default = 0 sdl=0 #----------------------------------------------------------------------- ----- # enable VNC library for graphics, default = 1 vnc=1 #----------------------------------------------------------------------- ----- # address that should be listened on for the VNC server if vnc is set. # default is to use ''vnc-listen'' setting from /etc/xen/xend-config.sxp #vnclisten="127.0.0.1" #----------------------------------------------------------------------- ----- # set VNC display number, default = domid #vncdisplay=1 #----------------------------------------------------------------------- ----- # try to find an unused port for the VNC server, default = 1 #vncunused=1 #----------------------------------------------------------------------- ----- # enable spawning vncviewer for domain''s console # (only valid when vnc=1), default = 0 vncconsole=1 #----------------------------------------------------------------------- ----- # no graphics, use serial port #nographic=0 #----------------------------------------------------------------------- ----- # enable stdvga, default = 0 (use cirrus logic device model) stdvga=0 #----------------------------------------------------------------------- ------ # serial port re-direct to pty deivce, /dev/pts/n # then xm console or minicom can connect serial=''pty'' #----------------------------------------------------------------------- ------ # enable sound card support, [sb16|es1370|all|..,..], default none #soundhw=''sb16'' #----------------------------------------------------------------------- ------ # set the real time clock to local time [default=0 i.e. set to utc] #localtime=1 #----------------------------------------------------------------------- ------ # start in full screen #full-screen=1 #----------------------------------------------------------------------- ------ # Enable USB support (specific devices specified at runtime through the # monitor window) #usb=1 # Enable USB mouse support (only enable one of the following, `mouse'' for # PS/2 protocol relative mouse, `tablet'' for # absolute mouse) #usbdevice=''mouse'' #usbdevice=''tablet'' _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Ulrich Windl
2006-Dec-11 07:54 UTC
Re: [Xen-users] Help: Guest OS time synchronization problem
On 10 Dec 2006 at 22:42, Chu, Sam wrote:> I am having great difficulty to maintain guest OS time. Here is my > environment. >[...]> /proc/sys/xen/independent_wallclock = 0Toggling that to 1 made time OK here for a four CPU Opteron machine (SLES10 x86_64): remote refid st t when poll reach delay offset jitter =============================================================================*rkdvmso1.dvm.kl 132.199.176.97 2 u 778 1024 377 0.208 0.025 0.789 +rksapas01.dvm.k 192.168.0.61 3 u 116 1024 377 0.133 0.033 0.767 +rksapas02.dvm.k 192.168.0.61 3 u 846 1024 377 0.100 0.051 0.781 +rksapas03.dvm.k 192.168.0.62 3 u 781 1024 377 0.311 -0.044 0.835 +rksapas04.dvm.k 192.168.0.62 3 u 843 1024 377 0.306 0.033 0.767 +rksapas05.dvm.k 192.168.0.63 3 u 808 1024 377 0.320 -0.097 0.826 +rksapas06.dvm.k 192.168.0.42 4 u 805 1024 377 0.205 -0.013 0.789 +rksapas08.dvm.k 192.168.0.64 3 u 833 1024 377 0.320 -0.014 0.908 Regards, Ulrich _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nico Kadel-Garcia
2006-Dec-11 14:50 UTC
Re: [Xen-users] Help: Guest OS time synchronization problem
Chu, Sam wrote:> > I am having great difficulty to maintain guest OS time. Here is my > environment. > > Hardware: Intel Woodcrest processor. > > Xen: 3.0.3 > > Xen OS: Red Hat Enterprise 4 Update 3, x86_64 version > > Guest OS: configuration is pretty standard. Please see the end of email. > > Guest OS: Red Hat Enterprise 4 Update 3, x86_64, with everything > installed, ntpd not running. > > /proc/sys/xen/independent_wallclock = 0 > > /proc/sys/xen/permitted_clock_jitter = 10000000 > > >NTP should run out of Dom0: that seems to correctly set NTP for all DomU''s. Do not run independent, local hardware clocks, if you can reasonably avoid it. Seriously: I''m afraid the kind of time drift you''re seeing is typical for overclocked, overheated, low quality motherboards with clock chips purchased at an "OEM discount" from the back of somebody''s bicycle in Taiwan. Unfortunately, I''ve seen too much of that kind of hardware in use for Beowulf clusters. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users