11:06 a.m.
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(a)doolittle.us.com]
*Gesendet:* Freitag, 7. Februar 2014 16:18
*An:* Markus Stockhausen
*Cc:* fromani(a)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(a)collogia.de
<mailto:stockhausen@collogia.de>> wrote:
> Von: Markus Stockhausen
> Gesendet: Freitag, 7. Februar 2014 14:46
> An: Dan Kenigsberg; fromani(a)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(a)collogia.de</a>&gt;
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(a)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--