[Users] Timezone Hypervisor/VM

[Bob Doolittle]

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 at doolittle.us.com]
> *Gesendet:* Freitag, 7. Februar 2014 16:18
> *An:* Markus Stockhausen
> *Cc:* fromani at 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 at collogia.de 
> <mailto:stockhausen at collogia.de>> wrote:
>
>     > Von: Markus Stockhausen
>     > Gesendet: Freitag, 7. Februar 2014 14:46
>     > An: Dan Kenigsberg; fromani at redhat.com <mailto:fromani at 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140207/56a33700/attachment-0001.html>