cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: [ACS41] System VMs not syncing time - does this block the release?
Date Wed, 15 May 2013 16:39:14 GMT
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.


On Wed, May 15, 2013 at 9:08 AM, Chip Childers
<> 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 <> 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

View raw message