Bug 1664490

As a workaround, you can change the Cluster from the System Menu instead from first General Menu.
From there you can also change the "Hardware Clock Time Offset" to correct settings.

~~~
RHV-M GUI -> Compute -> Virtual Machine => {VM-Name}
Edit VM -> System > 
> Change the Cluster
> Change "Hardware Clock Time Offset" to correct settings
Click OK
~~~

Moving back to ASSIGNED while waiting for the needinfo so it isn't FailedQA if it doesn't work

Did not reproduce by the steps given.
Tested on:
ovirt-engine-4.2.8.2-0.1.el7ev.noarch
ovirt-engine-4.3.0-0.8.rc2.el7.noarch

Bimal, this isn't reproducible by engineering or QE on 4.2.8 or 4.3. Can you try on one of those, or provide exact steps to a reproducer?

Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

Hi,

During the demo of the problem to Steven, we noticed this problem also happens if you just change the "Operating System".

~~~
RHV-M UI -> Virtual Machine -> Edit VM -> System tab.
~~~

The "Hardware Clock Time Offset" will change to "default GMT Standard Timezone" as well.

Thanks
Bimal.

(In reply to Bimal Chollera from comment #13)
> During the demo of the problem to Steven, we noticed this problem also
> happens if you just change the "Operating System".

yes, because the set of TZs is different. But that's not the point of this bug, is it?
Here in this bug it is just that it shouldn't be reset on a Cluster change

(In reply to Michal Skrivanek from comment #14)
> (In reply to Bimal Chollera from comment #13)
> > During the demo of the problem to Steven, we noticed this problem also
> > happens if you just change the "Operating System".
> 
> yes, because the set of TZs is different. But that's not the point of this
> bug, is it?
> Here in this bug it is just that it shouldn't be reset on a Cluster change


Yes, this correct, when the BZ was added the problem was reproducible with Cluster Change.
But during the demo to Steven, we noticed the TZ also changes when changing the "Operating System".
Regardless, Cluster change or OS change - the TZ shouldn't change.

Verified on:
ovirt-engine-4.3.3.1-0.1.el7.noarch

Steps:
1. Data Center with 2 Clusters and 2 hosts.
2. Running VM configured with correct time and US EST TZ.
~~~
RHV-M GUI -> Compute -> Virtual Machine => {VM-Name}

Hardware Clock Time Offset:  US Eastern Standard Time (Indiana)
~~~
3. From the RHV-M DB.
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -x -c "SELECT time_zone FROM vm_static WHERE vm_name = '{VM-Name}';"
-[ RECORD 1 ]-------------------
time_zone | America/Indianapolis

# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -x -c "SELECT utc_diff, guest_timezone_offset, guest_timezone_name FROM vm_dynamic WHERE vm_guid = (SELECT vm_guid FROM vm_static WHERE vm_name ='{VM-Name}');"
-[ RECORD 1 ]---------+---------------------------
utc_diff              | 0
guest_timezone_offset | -240
guest_timezone_name   | EDT

4. Check timezone inside the guest VM:
# timedatectl
                Time zone: America/New_York (EDT, -0400)


4. Shutdown the VM
5. Change the Cluster of the VM (Try to do so when looking in the VM->System tab)
6. See that changing the cluster didn't change the time zone.
7. Check engine's DB again:
# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -x -c "SELECT time_zone FROM vm_static WHERE vm_name = '{VM-Name}';"
-[ RECORD 1 ]-------------------
time_zone | America/Indianapolis

# /usr/share/ovirt-engine/dbscripts/engine-psql.sh -x -c "SELECT utc_diff, guest_timezone_offset, guest_timezone_name FROM vm_dynamic WHERE vm_guid = (SELECT vm_guid FROM vm_static WHERE vm_name ='{VM-Name}');"
-[ RECORD 1 ]---------+---------------------------
utc_diff              | 0
guest_timezone_offset | -240
guest_timezone_name   | EDT

8. Start the VM
9. Check VM timezone:
# timedatectl
                Time zone: America/New_York (EDT, -0400)

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://access.redhat.com/errata/RHEA-2019:1085

sync2jira

sync2jira