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:
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.
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?
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.
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
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
- cloud init should provide this for linux guests as well - cloud init may allow to change it post reboot greg?
(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.)
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.
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
no response, I consider this fixed. Moving to ON_QA to get it tested properly
Verified - https://tcms.engineering.redhat.com/run/163764/
covered by regular doc which describes how to change TZ
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
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days