Chiradeep, As I think thought it, I don't think a documentation note will sufficient because the SSVM can be destroyed and respawned by CloudStack without intervention by a human. Therefore, we can get into a situation where an operator installs and configures NTP, and then at some point in the future, the SSVM gets respawned and clocks drift. The worst part about this scenario is that the failures for S3 sync become silent since we have no mechanism to surface the failure to a dashboard or monitoring system.
How much effort (i.e. hours/days) would it be to build a new image? Thanks, -John On May 15, 2013, at 4:59 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > Did some further digging around as to why > /proc/sys/xen/independent_wallclock is not there on the Debian system vm. > > TLDR; the kernel is PvOps (I.e., just a regular kernel that works like a > PV kernel, not a specialized paravirt kernel). To eliminate > special-casing, the independent_wallclock feature was dropped. However, > this means that the domU clock is NO LONGER synch'ed to dom0 and NTP is > required on ANY domU. So the clock on the domU is only sync'ed at domU > creation time. I suspect Citrix XenServer might have some workaround > > > http://www.gossamer-threads.com/lists/xen/users/234750 > > > What this means is that we *may* need to run ntp on system vms on Xen. > This is of course a non-trivial change involving updates to systemvms. > > I suspect that it does not matter much for virtual routers or console > proxy vms. > > We could have an advisory that for those users that care (e.g., those > using S3 sync) that they need to run ntp after the SSVM has been created. > I.e, login to the SSVM and run > apt-get update > apt-get install ntp > > -- > Chiradeep > > > > On 5/15/13 1:11 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: > >> For VMWare, the command >> vmware-toolbox-cmd timesync status returns 'Disabled'. I can submit a >> patch for /etc/init.d/cloud-early-config to enable it >> >> >> On 5/15/13 12:23 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> >> wrote: >> >>> I am not sure why it is missing, but I will refer to >>> Citrix XenServer 6.0 Virtual Machine Installation Guide >>> >>> http://s.apache.org/YGn >>> >>> And quote >>> "Time Handling in Linux VMs >>> By default, the clocks in a Linux VM are synchronized to the clock >>> running >>> on the control domain, and cannot be >>> independently changed. This mode is a convenient default, since only the >>> control domain needs to be running the >>> NTP service to keep accurate time across all VMs. Upon installation of a >>> new Linux VM, make sure you change the >>> time-zone from the default UTC to your local value (see the section >>> called >>> ³Release Notes² for specific distribution >>> instructions). >>> To set individual Linux VMs to maintain independent times >>> 1. From a root prompt on the VM, run the command: echo 1 > >>> /proc/sys/xen/independent_wallclock >>> 2. This can be persisted across reboots by changing the /etc/sysctl.conf >>> configuration file and adding: >>> # Set independent wall clock time >>> xen.independent_wallclock=1 >>> 3. As a third alternative, independent_wallclock=1 may also be passed as >>> a >>> boot parameter to the VM. >>> " >>> >>> >>> On 5/15/13 12:09 PM, "Chip Childers" <chip.child...@sungard.com> wrote: >>> >>>> On Wed, May 15, 2013 at 12:02:41PM -0700, Chiradeep Vittal wrote: >>>>> /proc/sys is not a regular filesystem and cannot be added to from the >>>>> shell. >>>>> Drivers need to add nodes into this filesystem. >>>> >>>> Backing up a bit... >>>> >>>> This is the current system VM image that the 4.1 software should be >>>> using on Xen: >>>> >>>> http://download.cloud.com/templates/acton/acton- >>>> systemvm-02062012.vhd.bz2 >>>> >>>> Does this system VM have the correct drives installed to set >>>> /proc/sys/xen to use the Dom0 time for sync? >>>> >>>> If so, then is this a devcloud only issue for Xen? If that's the case, >>>> then we shouldn't block a release to simply improve things. >>>> >>>> We do know that a patch for kvm was needed. >>>> >>>> We still don't have any >>>> answer or comments about the VMware system VM (specifically this >>>> template: http://download.cloud.com/templates/burbank/burbank- >>>> systemvm-08012012.ova >>>> >>> >> >
