On Nov 19, 2013, at 23:20 , Dan Kenigsberg <danken@redhat.com> 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#virConnectDomainEventRTCChangeCallback
> 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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users