Bug 842446 - CreateVDSCommand.InitData() incorrectly calculates the utc offset of a guest unless the offset is already set or a valid timezone is already set.
CreateVDSCommand.InitData() incorrectly calculates the utc offset of a guest ...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.0.5
All All
high Severity high
: ---
: ---
Assigned To: Roy Golan
Pavel Stehlik
virt
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-23 17:26 EDT by Lee Yarwood
Modified: 2012-08-20 08:31 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-09 09:43:44 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)

  None (edit)
Description Lee Yarwood 2012-07-23 17:26:33 EDT
Description of problem:

When starting a guest for the first time the initData() method within the CreateVDSCommand class fails to correctly set a guests utc_diff unless the guest already has a valid timezone set. The utc_diff will default to ~0 when a valid timezone is not already set. 

Within the method we can see that :

- Unless a timezone is set we always default to EST (TimeZoneInfo).
- With EST set as the timezone we always fail to lookup the javaZoneId as we use 
  the wrong array (WindowsJavaTimezoneMapping). We should use the windowsToJava 
  array or just use a local lookup.
- If previously set we do not attempt to calculate or confirm the utc diff.

Version-Release number of selected component (if applicable):
3.0.5

How reproducible:
Always

Steps to Reproduce:
1. Create any guest without setting a timezone.
2. Start the guest.
3. Review the utc_diff stored within vm_dynamic for this guest.
  
Actual results:
utc_diff defaults to 0 unless a valid timezone is set.

Expected results:
utc_diff is correctly calculated if a timezone is set _and_ if no timezone is set against the guest.

Additional info:
BZ#810225 contains some work to improve this upstream with gerrit change 5326 [1]. AFAICT this work aims to expose the timezone setting for _all_ guests. 

[1] http://gerrit.ovirt.org/#/c/5326/
Comment 2 Barak 2012-07-25 04:37:50 EDT
How was the VM created? UI ? or API ?
Comment 3 Lee Yarwood 2012-07-25 04:44:19 EDT
(In reply to comment #2)
> How was the VM created? UI ? or API ?

via the wpf UI.
Comment 4 Roy Golan 2012-08-01 08:03:50 EDT
(In reply to comment #0)
> Description of problem:
> 
> When starting a guest for the first time the initData() method within the
> CreateVDSCommand class fails to correctly set a guests utc_diff unless the
> guest already has a valid timezone set. The utc_diff will default to ~0 when
> a valid timezone is not already set. 
> 
> Within the method we can see that :
> 
> - Unless a timezone is set we always default to EST (TimeZoneInfo).
> - With EST set as the timezone we always fail to lookup the javaZoneId as we
> use 
>   the wrong array (WindowsJavaTimezoneMapping). We should use the
> windowsToJava 
>   array or just use a local lookup.
> - If previously set we do not attempt to calculate or confirm the utc diff.
> 
> Version-Release number of selected component (if applicable):
> 3.0.5
> 
> How reproducible:
> Always
> 
> Steps to Reproduce:
> 1. Create any guest without setting a timezone.
> 2. Start the guest.
> 3. Review the utc_diff stored within vm_dynamic for this guest.
>   
> Actual results:
> utc_diff defaults to 0 unless a valid timezone is set.
> 
> Expected results:
> utc_diff is correctly calculated if a timezone is set _and_ if no timezone
> is set against the guest.
> 
> Additional info:
> BZ#810225 contains some work to improve this upstream with gerrit change
> 5326 [1]. AFAICT this work aims to expose the timezone setting for _all_
> guests. 
> 
> [1] http://gerrit.ovirt.org/#/c/5326/

when the OS starts and syncs with NTP or some other clock change than libvirt raises an event (VIR_DOMAIN_EVENT_ID_RTC_CHANGE) with the offset from the timezone so its reasonable to find small skews there.
Comment 5 Lee Yarwood 2012-08-06 05:47:46 EDT
(In reply to comment #4)
> (In reply to comment #0)
> > Description of problem:
> > 
> > When starting a guest for the first time the initData() method within the
> > CreateVDSCommand class fails to correctly set a guests utc_diff unless the
> > guest already has a valid timezone set. The utc_diff will default to ~0 when
> > a valid timezone is not already set. 
> > 
> > Within the method we can see that :
> > 
> > - Unless a timezone is set we always default to EST (TimeZoneInfo).
> > - With EST set as the timezone we always fail to lookup the javaZoneId as we
> > use 
> >   the wrong array (WindowsJavaTimezoneMapping). We should use the
> > windowsToJava 
> >   array or just use a local lookup.
> > - If previously set we do not attempt to calculate or confirm the utc diff.
> > 
> > Version-Release number of selected component (if applicable):
> > 3.0.5
> > 
> > How reproducible:
> > Always
> > 
> > Steps to Reproduce:
> > 1. Create any guest without setting a timezone.
> > 2. Start the guest.
> > 3. Review the utc_diff stored within vm_dynamic for this guest.
> >   
> > Actual results:
> > utc_diff defaults to 0 unless a valid timezone is set.
> > 
> > Expected results:
> > utc_diff is correctly calculated if a timezone is set _and_ if no timezone
> > is set against the guest.
> > 
> > Additional info:
> > BZ#810225 contains some work to improve this upstream with gerrit change
> > 5326 [1]. AFAICT this work aims to expose the timezone setting for _all_
> > guests. 
> > 
> > [1] http://gerrit.ovirt.org/#/c/5326/
> 
> when the OS starts and syncs with NTP or some other clock change than
> libvirt raises an event (VIR_DOMAIN_EVENT_ID_RTC_CHANGE) with the offset
> from the timezone so its reasonable to find small skews there.

*If* the guest syncs with NTP, AFAIK we don't quote it as a requirement for use within RHEV hosted guests.

Without this the skews can actually be rather large, in the case attached to this bug the skew is ~4 hours (EST).
Comment 6 Roy Golan 2012-08-09 02:35:59 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #0)
> > > Description of problem:
> > > 
> > > When starting a guest for the first time the initData() method within the
> > > CreateVDSCommand class fails to correctly set a guests utc_diff unless the
> > > guest already has a valid timezone set. The utc_diff will default to ~0 when
> > > a valid timezone is not already set. 
> > > 
> > > Within the method we can see that :
> > > 
> > > - Unless a timezone is set we always default to EST (TimeZoneInfo).
> > > - With EST set as the timezone we always fail to lookup the javaZoneId as we
> > > use 
> > >   the wrong array (WindowsJavaTimezoneMapping). We should use the
> > > windowsToJava 
> > >   array or just use a local lookup.
> > > - If previously set we do not attempt to calculate or confirm the utc diff.
> > > 
> > > Version-Release number of selected component (if applicable):
> > > 3.0.5
> > > 
> > > How reproducible:
> > > Always
> > > 
> > > Steps to Reproduce:
> > > 1. Create any guest without setting a timezone.
> > > 2. Start the guest.
> > > 3. Review the utc_diff stored within vm_dynamic for this guest.
> > >   
> > > Actual results:
> > > utc_diff defaults to 0 unless a valid timezone is set.
> > > 
> > > Expected results:
> > > utc_diff is correctly calculated if a timezone is set _and_ if no timezone
> > > is set against the guest.
> > > 
> > > Additional info:
> > > BZ#810225 contains some work to improve this upstream with gerrit change
> > > 5326 [1]. AFAICT this work aims to expose the timezone setting for _all_
> > > guests. 
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/5326/
> > 
> > when the OS starts and syncs with NTP or some other clock change than
> > libvirt raises an event (VIR_DOMAIN_EVENT_ID_RTC_CHANGE) with the offset
> > from the timezone so its reasonable to find small skews there.
> 
> *If* the guest syncs with NTP, AFAIK we don't quote it as a requirement for
> use within RHEV hosted guests.
> 
> Without this the skews can actually be rather large, in the case attached to
> this bug the skew is ~4 hours (EST).

which still works as expected. If the VM time has changed this is what we get. next time we start the VM this offset will be in use to set the VM hardware clock and the guest OS time will continue to work fine. or am I missing something here?
Comment 7 Lee Yarwood 2012-08-09 09:43:44 EDT
(In reply to comment #6)
> which still works as expected. If the VM time has changed this is what we
> get. next time we start the VM this offset will be in use to set the VM
> hardware clock and the guest OS time will continue to work fine. or am I
> missing something here?

Ah my apologies, I didn't understand the VIR_DOMAIN_EVENT_ID_RTC_CHANGE events correctly. I've tested this again and can see that at shutdown VDSM will update the offset to that used within the guest, thus starting with an offset of 0 is not an issue.

Closing this out as NOTABUG.  

Thanks,

Lee

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