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 [b...@doolittle.us.com]
*Gesendet:* Freitag, 7. Februar 2014 16:18
*An:* Markus Stockhausen
*Cc:* from...@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" <stockhau...@collogia.de <mailto:stockhau...@collogia.de>> wrote:

    > Von: Markus Stockhausen
    > Gesendet: Freitag, 7. Februar 2014 14:46
    > An: Dan Kenigsberg; from...@redhat.com <mailto:from...@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


_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to