Re: [Users] Time keeping in Windows VM

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.

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