Bug 996183 - Incorrect DefaultWindowsTimeZone causes to pass 'clock adjustment="0"' to qemu-kvm for Windows VM
Incorrect DefaultWindowsTimeZone causes to pass 'clock adjustment="0"' to qem...
Status: CLOSED DUPLICATE of bug 988259
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-12 11:19 EDT by Jiri Belka
Modified: 2013-08-13 06:57 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-13 06:57:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine.log, vdsm.log (303.99 KB, application/x-gzip)
2013-08-12 11:19 EDT, Jiri Belka
no flags Details

  None (edit)
Description Jiri Belka 2013-08-12 11:19:10 EDT
Created attachment 785754 [details]
engine.log, vdsm.log

Incorrect DefaultWindowsTimeZone causes to pass 'clock adjustment="0"' to qemu-kvm for Windows VM but it should fall back to 'GMT Standard Time'.

By default DefaultWindowsTimeZone is 'GMT Standard Time', which is right now 3600 seconds plus from UTC.

When you do:

rhevm-config -s DefaultWindowsTimeZone=foobar

the VMs are started with '<clock adjustment="0" offset="variable">', thus it is UTC.

This is strange.

Version-Release number of selected component (if applicable):
is9.1

Steps to Reproduce: 
1. use default DefaultWindowsTimeZone as it is after rhevm installation
2. create and start a windows VM
3. check qemu-kvm for 'base' option
4. override 'DefaultWindowsTimeZone' to some nonsense value, ie. 'foobar'
   (rhevm-config -s DefaultWindowsTimeZone=foobar ; service ovirt-engine restart)
5. create and start a windows VM
6. check qemu-kvm for 'base' option

Actual results: 
fallback TZ for windows is different, default is 'GMT Standard Time' but when there is incorrectly defined DefaultWindowsTimeZone, the fallback is to UTC.

Expected results:
even with incorrect DefaultWindowsTimeZone the fallback should be to 'GMT Standard Time' respecting DST

Additional info:
* default TZ for Windows
        <name>desktop-windows</name>
        <clock adjustment="3600" offset="variable">
        <name>server-windows</name>
        <clock adjustment="3600" offset="variable">

* vms with incorrect DefaultWindowsTimeZone
        <name>foobar</name>
        <clock adjustment="0" offset="variable">
        <name>foobar2</name>
        <clock adjustment="0" offset="variable">
Comment 1 Michal Skrivanek 2013-08-13 06:57:36 EDT
this is being addressed as part of bug 988259 - patch http://gerrit.ovirt.org/#/c/17524/

*** This bug has been marked as a duplicate of bug 988259 ***

Note You need to log in before you can comment on or make changes to this bug.