Note that this means system vms are required to be linux, as 'kvmclock' doesn't work on other OSes. I haven't seen anyone proposing Windows or BSD system vms, so this seemed safe, but perhaps something to keep in mind.
On Wed, May 15, 2013 at 10:39 AM, 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 >>> >>>
