Bug 996183

Summary: Incorrect DefaultWindowsTimeZone causes to pass 'clock adjustment="0"' to qemu-kvm for Windows VM
Product: Red Hat Enterprise Virtualization Manager Reporter: Jiri Belka <jbelka>
Component: ovirt-engineAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.3.0CC: acathrow, iheim, lpeer, michal.skrivanek, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-13 10:57:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine.log, vdsm.log none

Description Jiri Belka 2013-08-12 15:19:10 UTC 
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 10:57:36 UTC 
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 ***