Bug 1927851

I checked what the guest agent reports and it matches what one would expect that timezone -- +10:00 normal offset and +11:00 with DST.



For current date it reports offset +11:00:

    [root@ovirt-host1 ~]# vdsm-client Host getAllVmStats | jq '.[]|.guestTimezone'
    {
      "offset": 660,
      "zone": "AUS Eastern Daylight Time"
    }

    [root@ovirt-host1 ~]# virsh qemu-agent-command Windows-10 '{"execute":"guest-get-timezone"}' | jq
    {
      "return": {
        "zone": "AUS Eastern Daylight Time",
        "offset": 39600
      }
    }
    [root@ovirt-host1 ~]# 


For date in May it reports +10:00


    [root@ovirt-host1 ~]# vdsm-client Host getAllVmStats | jq '.[]|.guestTimezone'
    {
      "offset": 600,
      "zone": "AUS Eastern Standard Time"
    }

    [root@ovirt-host1 ~]# virsh qemu-agent-command Windows-10 '{"execute":"guest-get-timezone"}' | jq
    {
      "return": {
        "zone": "AUS Eastern Standard Time",
        "offset": 36000
      }
    }


I don't see any issue here. Let's compare it with what Engine thinks the offset should be.

OK, that explains what didn't work for me..

virsh qemu-agent-command arik-win10 '{"execute":"guest-get-timezone"}'
returned:
error: Guest agent is not responding: QEMU guest agent is not connected

although I had guest information shown (FQDN, IP).
apparently I had ovirt-guest-agent installed..

OK, so if we get offset +11 then that explains it all - 
we use Australia/Brisbane for E. Australia Standard Time which doesn't have daylight saving.

So this requires us to add timezone AUS Eastern Standard Time that is mapped to Australia/Sydney

Verified on RHV 4.4.5-9. All looks good to me.

Env:
  - Engine instance with RHV 4.4.5-9 (ovirt-engine-4.4.5.9-0.1.el8ev) and RHEL 8.3 installed.
  - 3 hosts with RHV 4.4.5-9 and RHEL 8.3, vdsm-4.40.50.8-1.el8ev

Steps:
1. Create a 4.5 data center and a 4.5 cluster.
2. Install the hosts and create a new NFS storage domain.
3. Import an ISO domain with Windows 10 x64 ISO.
4. Create a VM with operating system set as Windows 10 x64, add a 20GB SATA disk, Select the NIC, Enter memory size a minimum of 3GB and attach the Windows ISO.
5. Run the VM.
6. Install the Windows with 'UTC+10 Canberra, Melbourne, Sydney' timezone.
7. Replace the disk in the cd-rom with virtio-win.iso.
8. Restart the VM.
9. Install the Windows drivers + Ovirt guest agent.
10. Set Hardware Clock Offset of VM to 'GMT+10:00 E. Australia Standard Time' in RHV-M
11. Restart the VM.
12. Check that the VM doesn't have a ! indicating Actual timezone in guest differs from the configuration.

Results (As Expected):
Actual results:
1. The data center and the cluster were created.
2. The host was installed and the storage domain and NIC were created.
3. The ISO domain was imported.
4. The VM was created.
5. The VM is running.
6. Windows has been installed with the correct timezone.
7. The disk in the cd-rom was replaced.
8. The VM is up again.
9. The Windows drivers and the Ovirt guest agent are installed.
10. Hardware Clock Offset of VM is set to 'GMT+10:00 E. Australia Standard Time' in RHV-M
11. The VM is up again (After it was down)
12. The VM doesn't have a ! indicating Actual timezone in guest differs from the configuration.

Tamir, something doesn't sound right in comment 6 -
Sydney time now due to daylight saving is GMT+11 while in Brisbane it's GMT+10.
When selecting "E. Australia Standard Time" we set the offset according to Brisbane so we should have got a different sign.
Could it be that you didn't set the type of the operating system in RHV to Windows?
The mismatch in the timezone should disappear when selecting "AUS Eastern Standard Time"

Sorry for the confusion. I copied the "GMT+10:00 E. Australia Standard Time" from the description into step 10.

Instead of the current step 10:

Steps:
10. Set Hardware Clock Offset of VM to '(GMT+10:00) AUS Eastern Standard Time' in RHV-M

Actual results (As Expected):
10. Hardware Clock Offset of VM is set to '(GMT+10:00) AUS Eastern Standard Time' in RHV-M

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 (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), 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/RHSA-2021:1169

Due to QE capacity, we are not going to cover this issue in our automation