This is a multi-part message in MIME format. --------------050309020507060308080404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/07/2014 10:26 AM, Markus Stockhausen wrote:
Hello,
you are right. Only Windows VMs show that behaviour. But for Linux the problem is even more strange: Have a look at my database for a specific Linux VM:
engine=# select a.vm_name,b.utc_diff from vm_static a, vm_dynamic b where a.vm_guid=b.vm_guid; vm_name | utc_diff ------------------+---------- colvm53 | -271973
Logging into the VM it shows the correct time but the hardware clock is far away according to utc_diff:
colvm53:~ # hwclock Tue Feb 4 12:49:21 2014 -0.173138 seconds colvm53:~ # date Fri Feb 7 16:20:42 CET 2014
Maybe because it reads the KVM/QEMU timing values another way than Windows.
Have you tried changing utc_diff for a Linux VM, to see if that has any effect? -Bob
Markus
------------------------------------------------------------------------ *Von:* Bob Doolittle [bob@doolittle.us.com] *Gesendet:* Freitag, 7. Februar 2014 16:18 *An:* Markus Stockhausen *Cc:* fromani@redhat.com; users; Martin Polednik; Dan Kenigsberg *Betreff:* Re: AW: [Users] Timezone Hypervisor/VM
Marcus,
Are all your VMs Windows? Because I have a mix and only Windows VMs are affected. Seems like changing utc_diff should only be done for Windows VMs (Linux happy to work with a hardware clock of GMT).
-Bob
On Feb 7, 2014 9:54 AM, "Markus Stockhausen" <stockhausen@collogia.de <mailto:stockhausen@collogia.de>> wrote:
> Von: Markus Stockhausen > Gesendet: Freitag, 7. Februar 2014 14:46 > An: Dan Kenigsberg; fromani@redhat.com <mailto:fromani@redhat.com> > Cc: Bob; Martin Polednik; ovirt-users > Betreff: AW: [Users] Timezone Hypervisor/VM > > > > > A detailed BZ report is worth its weight in gold ;-) > > > > Dan. > > Opened BZ 1062615 for that. > > Markus
Hi Dan,
just saw the bug update with target 3.4.1. Could you reproduce the bug and do you have some advice how to handle that setting until then? And what should I expect when daylight saving takes place in march?
From my understanding I would:
- pin all VMs to utc_diff=3600 (GMT+1) now - pin all VMs to utc_diff=7200 (GMT+2) after change of summertime
Markus
--------------050309020507060308080404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <br> <div class="moz-cite-prefix">On 02/07/2014 10:26 AM, Markus Stockhausen wrote:<br> </div> <blockquote cite="mid:12EF8D94C6F8734FB2FF37B9FBEDD173585EB188@EXCHANGE.collogia.de" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style> <div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hello,<br> <br> you are right. Only Windows VMs show that behaviour. But for Linux the <br> problem is even more strange: Have a look at my database for a specific<br> Linux VM:<br> <br> engine=# select a.vm_name,b.utc_diff from vm_static a, vm_dynamic b where a.vm_guid=b.vm_guid;<br> vm_name | utc_diff<br> ------------------+----------<br> colvm53 | -271973<br> <br> Logging into the VM it shows the correct time but the hardware clock is far away according to utc_diff:<br> <br> colvm53:~ # hwclock<br> Tue Feb 4 12:49:21 2014 -0.173138 seconds<br> colvm53:~ # date<br> Fri Feb 7 16:20:42 CET 2014<br> <br> Maybe because it reads the KVM/QEMU timing values another way than Windows.<br> </div> </blockquote> <br> Have you tried changing utc_diff for a Linux VM, to see if that has any effect?<br> <br> -Bob<br> <br> <blockquote cite="mid:12EF8D94C6F8734FB2FF37B9FBEDD173585EB188@EXCHANGE.collogia.de" type="cite"> <div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;"> <br> Markus<br> <br> <br> <div style="font-family: Times New Roman; color: #000000; font-size: 16px"> <hr tabindex="-1"> <div style="direction: ltr;" id="divRpF108373"><font color="#000000" face="Tahoma" size="2"><b>Von:</b> Bob Doolittle [<a class="moz-txt-link-abbreviated" href="mailto:bob@doolittle.us.com">bob@doolittle.us.com</a>]<br> <b>Gesendet:</b> Freitag, 7. Februar 2014 16:18<br> <b>An:</b> Markus Stockhausen<br> <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:fromani@redhat.com">fromani@redhat.com</a>; users; Martin Polednik; Dan Kenigsberg<br> <b>Betreff:</b> Re: AW: [Users] Timezone Hypervisor/VM<br> </font><br> </div> <div> <p dir="ltr">Marcus, </p> <p dir="ltr">Are all your VMs Windows? Because I have a mix and only Windows VMs are affected. Seems like changing utc_diff should only be done for Windows VMs (Linux happy to work with a hardware clock of GMT).</p> <p dir="ltr">-Bob</p> <div class="gmail_quote">On Feb 7, 2014 9:54 AM, "Markus Stockhausen" <<a moz-do-not-send="true" href="mailto:stockhausen@collogia.de" target="_blank">stockhausen@collogia.de</a>> wrote:<br type="attribution"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex"> > Von: Markus Stockhausen<br> > Gesendet: Freitag, 7. Februar 2014 14:46<br> > An: Dan Kenigsberg; <a moz-do-not-send="true" href="mailto:fromani@redhat.com" target="_blank">fromani@redhat.com</a><br> > Cc: Bob; Martin Polednik; ovirt-users<br> > Betreff: AW: [Users] Timezone Hypervisor/VM<br> ><br> > ><br> > > A detailed BZ report is worth its weight in gold ;-)<br> > ><br> > > Dan.<br> ><br> > Opened BZ 1062615 for that.<br> ><br> > Markus<br> <br> Hi Dan,<br> <br> just saw the bug update with target 3.4.1. Could you<br> reproduce the bug and do you have some advice how to<br> handle that setting until then? And what should I expect<br> when daylight saving takes place in march?<br> <br> From my understanding I would:<br> <br> - pin all VMs to utc_diff=3600 (GMT+1) now<br> - pin all VMs to utc_diff=7200 (GMT+2) after change of summertime<br> <br> Markus<br> <br> </blockquote> </div> </div> </div> </div> </blockquote> <br> </body> </html> --------------050309020507060308080404--