Perhaps this is a problem with DevCloud? http://nerdboys.com/2011/03/15/how-to-fix-virtualbox-time-synchonization-pr oblems/
On 5/15/13 10:17 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: >According to our resident Xen expert, any PV kernel automatically syncs to >the hardware clock on dom0. > >On 5/15/13 9:50 AM, "John Burwell" <jburw...@basho.com> wrote: > >>Marcus, >> >>Agreed. I think we need to add a set of hypervisor agnostic time >>keeping guidelines to the documentation. I just wanted to make sure >>there wasn't anything KVM specific that should be added as well. >> >>Thanks, >>-John >> >>On May 15, 2013, at 12:48 PM, Marcus Sorensen <shadow...@gmail.com> >>wrote: >> >>> Just the general one that system vms sync their time to the >>> hypervisor, thus admins need to keep the hypervisor time correct. It >>> sounds like that will be the case for all three, if we can manage it. >>> >>> On Wed, May 15, 2013 at 10:44 AM, John Burwell <jburw...@basho.com> >>>wrote: >>>> Marcus, >>>> >>>> Excellent. So, it looks like we have KVM resolved. We just need to >>>>address Xen and VMWare now. Do you think we need to any guidance to >>>>the documentation regarding KVM time keeping (e.g. environmental >>>>prerequisites)? >>>> >>>> Thanks, >>>> -John >>>> >>>> >>>> >>>> On May 15, 2013, at 12:39 PM, Marcus Sorensen <shadow...@gmail.com> >>>>wrote: >>>> >>>>> KVM LibvirtComputingResource has been patched in master. Tested on >>>>> master, 4.1, and both the acton and current system vm templates. This >>>>> patch makes system vms use 'kvmclock' for their timer, which is a vm >>>>> driver that gets it's time from the hypervisor. No change to the >>>>> system vm template itself. >>>>> >>>>> bfc5887a1bf6b41e88dd7a8f9987fcee8d3d9175 >>>>> >>>>> On Wed, May 15, 2013 at 9:08 AM, Chip Childers >>>>> <chip.child...@sungard.com> wrote: >>>>>> On Wed, May 15, 2013 at 11:03:16AM -0400, John Burwell wrote: >>>>>>> Chip, >>>>>>> >>>>>>> One other item I neglected to mention was that clock sync, at least >>>>>>>for Xen system VMs, wasn't an issue in the Jan-Feb timeframe. >>>>>>>Previously when I encountered these issues, syncing the host's clock >>>>>>>and rebuilding the system VMs addressed the issue. I assumed, but >>>>>>>never verified, that the SSVM was syncing back against the host's >>>>>>>clock through hypervisor. During my testing yesterday, aside from >>>>>>>hard setting the clock, I was unable to force clock sync on the >>>>>>>SSVM. >>>>>>> >>>>>>> Thanks, >>>>>>> -John >>>>>> >>>>>> I think that's our issue right now... answering the question: Why >>>>>>is >>>>>> this only an issue now? Did we just get lucky up to this point? >>>>>>Since >>>>>> the SSVMs are the same template as the timeframe you mention, I tend >>>>>>to >>>>>> believe that you / we were just lucky. >>>>>> >>>>>> Anyone else have thoughts? >>>>>> >>>>>>> >>>>>>> On May 15, 2013, at 10:18 AM, Chip Childers >>>>>>><chip.child...@sungard.com> wrote: >>>>>>> >>>>>>>> Starting a thread on this specific issue. >>>>>>>> >>>>>>>> CLOUDSTACK-2492 was opened, which is basically the fact that the >>>>>>>>System >>>>>>>> VMs aren't syncing time to the host or to an NTP server. The S3 >>>>>>>> integration is broken because of this problem, and therefore could >>>>>>>>not >>>>>>>> be considered a function available in 4.1 if we release as is. >>>>>>>> >>>>>>>> We need input from people that know about the current system VMs >>>>>>>>(the >>>>>>>> 3.x VMs), as well as the possibility of using the newer ones that >>>>>>>>we >>>>>>>> have been considering experimental for 4.1.0. >>>>>>>> >>>>>>>> What should we do? >>>>>>>> >>>>>>>> -chip >>>>>>> >>>>>>> >>>> >> >
