Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 902298 - PRD35 - [RFE] Change Time Zone after the initial-run [NEEDINFO]
PRD35 - [RFE] Change Time Zone after the initial-run
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
3.1.0
All All
low Severity low
: ---
: 3.5.0
Assigned To: Michal Skrivanek
meital avital
virt
: FutureFeature
Depends On: 1014326
Blocks: rhev3.5beta 1156165
  Show dependency treegraph
 
Reported: 2013-01-21 05:30 EST by Daniele
Modified: 2015-02-11 12:51 EST (History)
10 users (show)

See Also:
Fixed In Version: ovirt-3.5.0-alpha1
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-11 12:51:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
michal.skrivanek: needinfo? (anande)
sherold: Triaged+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 17:38:50 EST

  None (edit)
Description Daniele 2013-01-21 05:30:22 EST
Description of problem:
The Time Zone property can not be changed after the initial run.

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


How reproducible:
100%

Steps to Reproduce:
1. created my "golden image" VM as normal. I set the timezone within the VM, and did not touch this "initial run" timezone.
2. created a template from the golden image. Did not touch the "initial run" timezone.
3. created a VM pool from the template. Did not touch the "initial run" timezone.

  
Actual results:
All my VM pool machines take this "initial run" timezone as their default. I can't change that anymore, and I would have to change each pool VM's timezone separately.

Expected results:
Be able to change the time zone of the template, the golden image etc. even after the initial run

Additional info:
Comment 1 Itamar Heim 2013-01-21 06:01:53 EST
timezone is passed as part of sysprep process.
if your pool runs the sysprep each time (you didn't take snapshots on the pool vm's post creation), then changing the timezone of the VMs should work for next boot.
Comment 2 Daniele 2013-01-21 07:33:54 EST
Does this apply to Linux guests as well?
What if the snapshot has been taken? Is there any possibility to change the timezone property from the RHEVM UI once it has been taken?
Comment 3 Michal Skrivanek 2013-01-22 08:24:12 EST
it's only windows sysprep. It's not there for Linux at all.
For Windows once you  finish the Windows installation/setup the value no longer taken into account, even if you change it. It doesn't correspond to the actual time zone in guest

But isn't this about something else? Is he trying to say that instead of using the configured(in guest) TZ in the VM it is forcefully overwriting it for pooled vms every time a new one is deployed?
IIUC he only has Linux guests and we do not do anything with the timezone there.
Comment 4 Daniele 2013-02-24 09:57:10 EST
Transforming this into an RFE to avoid duplication:

1. Proposed title of this feature request
Change timezone property after the initial run

2. Who is the customer behind the request?
Account name: Finnet-Iiitto
Customer segment: 
TAM/SRM customer: no/no
Strategic Customer yes/no: yes


3. What is the nature and description of the request?
To be able to edit the timezone entry in the database for VM's that already passed the initial run and template images.

4. Why does the customer need this? (List the business requirements here)
No specific business requirements. It's a nice function that should be there.

5. How would the customer like to achieve this? (List the functional
requirements here)
To be able to edit the timezone entry in the database for VM's that already passed the initial run and template images.

6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
User installs a VM, runs the sysprep, boots into the system and realizes the timezone settings is wrong and wants to rerun the sysprep with right Time Zone settings.

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
This can maybe get "transformed" into RFE?
https://bugzilla.redhat.com/show_bug.cgi?id=902298

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
no

9. Is the sales team involved in this request and do they have any additional input?
no

10. List any affected packages or components.
rhevm

11. Would the customer be able to assist in testing this functionality if
implemented?
yes
Comment 5 Michal Skrivanek 2013-03-06 09:04:29 EST
makes sense - adding flags.
in any case it needs a tooltip this applies to sysprep and it's not about setting the time zone in guest OS on the fly
Comment 6 Itamar Heim 2013-04-23 02:07:27 EDT
- cloud init should provide this for linux guests as well
- cloud init may allow to change it post reboot
greg?
Comment 7 Greg Padgett 2013-04-23 10:16:42 EDT
(In reply to comment #6)
> - cloud init should provide this for linux guests as well
> - cloud init may allow to change it post reboot
> greg?

Cloud-init will allow guest timezones to be set from rhevm, but only when the guest boots.  For VMs in a pool, this would occur at each boot.  (Of course note that the first phase of cloud-init is via the "Run Once" dialog, so it's more of a manual configuration for VMs in a pool until we support persisting the cloud-init data.)
Comment 8 Roman Hodain 2013-05-24 04:12:48 EDT
I want to just pint out that the time zone does not impact only the Windows system, but also the Linux systems.

The guest is started with the clock adjustment which is calculated based on the timezone.

<clock adjustment="-36000" offset="variable">
                <timer name="rtc" tickpolicy="catchup"/>
</clock>

The result is that the HW clock on the guest is shifted according to the timezone.
Comment 11 Michal Skrivanek 2014-04-22 08:54:42 EDT
Anand, can you please check this is addressed by a fix for bug 1014326. To me it sounds like it should be what this bug asks for
Comment 12 Michal Skrivanek 2014-05-23 09:20:27 EDT
no response, I consider this fixed. Moving to ON_QA to get it tested properly
Comment 13 meital avital 2014-10-27 03:51:17 EDT
Verified - https://tcms.engineering.redhat.com/run/163764/
Comment 14 Michal Skrivanek 2014-12-04 08:59:29 EST
covered by regular doc which describes how to change TZ
Comment 16 errata-xmlrpc 2015-02-11 12:51:37 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0158.html

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