On Nov 19, 2013, at 23:20 , Dan Kenigsberg <danken(a)redhat.com&gt; wrote: > On Tue, Nov 19, 2013 at 04:36:24PM +0000, Martin Goldstone wrote: >> Hi all, >> >> We're currently experiencing an issue in our production oVirt 3.2.2 >> environment (on CentOS 6.4) with time keeping on our Windows guests. It >> seems to have appeared around the time of the recent DST change. It's taken >> us a while to get to the bottom of this as some machines were created in >> the wrong timezone, which muddied the waters a bit. >> >> It appears that when Windows automatically updated time in the VMs, this >> new offset from UTC was not stored correctly, and the next time the host >> was shutdown and started back up, the clock was set incorrectly. We >> eventually managed to get this to be consistently reproducible: Set the >> clock an hour ahead; power off VM; power it back on; set the clock an hour >> back (ie return it to the original time), power off and power back on; >> observe that the clock has now shifted to an hour before the original time. >> This can be observed in the vm_dynamic table on the database. >> >> To be honest, I don't think that this an oVirt problem, as I've done some >> limited testing on another host using virt-manager/libvirt. If I edit the >> xml to set the clock offset to variable, using UTC as the basis and setting >> the adjustment to 3600 (mimicking how it would have been before the DST >> change), when I change the time in the VM back by an hour (as Windows would >> do automatically at DST change), the xml shows a new offset of -3600, so it >> seems when the clock is changed the offset it's putting in the XML is the >> offset based on the time from when the VM was started, not the offset from >> UTC. > > I believe that you are seeing "Bug 956741 - When RHEL VMs are powered > off/on time is off by as much as 3 hrs when system comes back up". > > http://libvirt.org/html/libvirt-libvirt.html#virConnectDomainEventRTCChan... > says that utcoffset is relative to UTC. If it's not so, it's a bug > (either in the doc or in the code) so I'm copying libvir-list. it is this [1] bug. AFAIK the intention is to fix doc and not the behavior because it's with us for really long time... [1] https://bugzilla.redhat.com/show_bug.cgi?id=964177 > > Which libvirt and qemu versions do you have? > > >> >> Does anyone have any suggestions? At the moment, the only things I can >> think of doing are either a) shutting down each VM and setting their offset >> to 0 in the vm_dynamic table before starting the back up again or b) >> setting the time forward and back an appropriate amount of time so that the >> offset becomes 0, shutting the VM down and powering it back on again. > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users