<div dir="ltr">We've got a couple of versions of libvirt and qemu installed across our boxes:<div><br></div><div><div>qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.6.x86_64<br></div><div>libvirt-0.10.2-18.el6_4.9.x86_64</div>
<div><br></div><div>qemu-kvm-0.12.1.2-2.355.0.1.el6_4.9.x86_64<br></div><div>libvirt-0.10.2-18.el6_4.14.x86_64</div><div><br></div><div>qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64</div><div>libvirt-0.10.2-18.el6_4.9.x86_64</div>
<div><br></div><div><br></div><div>I guess it probably is that bug. I'm guessing that once the doc is updated someone will have to fix libvirt so that it uses the offset it gets back from qemu to work out what the offset from utc it should store is.</div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 November 2013 15:40, Michal Skrivanek <span dir="ltr"><<a href="mailto:michal.skrivanek@redhat.com" target="_blank">michal.skrivanek@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Nov 19, 2013, at 23:20 , Dan Kenigsberg <<a href="mailto:danken@redhat.com">danken@redhat.com</a>> wrote:<br>
<br>
> On Tue, Nov 19, 2013 at 04:36:24PM +0000, Martin Goldstone wrote:<br>
>> Hi all,<br>
>><br>
>> We're currently experiencing an issue in our production oVirt 3.2.2<br>
>> environment (on CentOS 6.4) with time keeping on our Windows guests. It<br>
>> seems to have appeared around the time of the recent DST change. It's taken<br>
>> us a while to get to the bottom of this as some machines were created in<br>
>> the wrong timezone, which muddied the waters a bit.<br>
>><br>
>> It appears that when Windows automatically updated time in the VMs, this<br>
>> new offset from UTC was not stored correctly, and the next time the host<br>
>> was shutdown and started back up, the clock was set incorrectly. We<br>
>> eventually managed to get this to be consistently reproducible: Set the<br>
>> clock an hour ahead; power off VM; power it back on; set the clock an hour<br>
>> back (ie return it to the original time), power off and power back on;<br>
>> observe that the clock has now shifted to an hour before the original time.<br>
>> This can be observed in the vm_dynamic table on the database.<br>
>><br>
>> To be honest, I don't think that this an oVirt problem, as I've done some<br>
>> limited testing on another host using virt-manager/libvirt. If I edit the<br>
>> xml to set the clock offset to variable, using UTC as the basis and setting<br>
>> the adjustment to 3600 (mimicking how it would have been before the DST<br>
>> change), when I change the time in the VM back by an hour (as Windows would<br>
>> do automatically at DST change), the xml shows a new offset of -3600, so it<br>
>> seems when the clock is changed the offset it's putting in the XML is the<br>
>> offset based on the time from when the VM was started, not the offset from<br>
>> UTC.<br>
><br>
> I believe that you are seeing "Bug 956741 - When RHEL VMs are powered<br>
> off/on time is off by as much as 3 hrs when system comes back up".<br>
><br>
> <a href="http://libvirt.org/html/libvirt-libvirt.html#virConnectDomainEventRTCChangeCallback" target="_blank">http://libvirt.org/html/libvirt-libvirt.html#virConnectDomainEventRTCChangeCallback</a><br>
> says that utcoffset is relative to UTC. If it's not so, it's a bug<br>
> (either in the doc or in the code) so I'm copying libvir-list.<br>
<br>
</div></div>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...<br>
<br>
[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=964177" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=964177</a><br>
<div class="im"><br>
><br>
> Which libvirt and qemu versions do you have?<br>
><br>
><br>
>><br>
>> Does anyone have any suggestions? At the moment, the only things I can<br>
>> think of doing are either a) shutting down each VM and setting their offset<br>
>> to 0 in the vm_dynamic table before starting the back up again or b)<br>
>> setting the time forward and back an appropriate amount of time so that the<br>
>> offset becomes 0, shutting the VM down and powering it back on again.<br>
</div>> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div style="text-align:left">Martin Goldstone</div><div style="text-align:left">IT Systems Administrator - Finance & IT</div><div style="text-align:left">
Keele University, Keele, Staffordshire, United Kingdom, ST5 5BG</div><div style="text-align:left">Telephone: +44 1782 734457</div><div style="text-align:left">G+: <a href="http://google.com/+MartinGoldstoneKeele" target="_blank">http://google.com/+MartinGoldstoneKeele</a></div>
</div>
</div>