Feature Request Overview (mandatory - Complete while in New status)

The primary problem is that Windows instances launched on Red Hat Openstack Services on Openshift (RHOSO) 18.0 environments in Japan timezone exhibit a 9-hour time discrepancy immediately upon boot when the Data Plane (EDPM) nodes are configured to UTC.

This discrepancy occurs because:

• As a current implementation[1],  Linux OS (RTC) defaults to UTC, but Windows OS (RTC) defaults to the OS time zone (local time).
• Nova's existing behavior sets the guest clock based on the host's timezone, assuming the guest uses the same timezone. When the host (EDPM node) is UTC, and the Windows guest is set to a local time zone (e.g., JST/UTC+9:00), the clock is set incorrectly.

Based on  the https://issues.redhat.com/browse/OSPRH-20465 [2],   Engineering determined to handle this issue as an RFE.

The Goal of the this EFE is  Windows instances to correctly set their real-time clock (RTC) offset (e.g., JST) from boot, independent of the compute node's time zone.

[1] https://github.com/openstack/nova/blob/17f1f0ad49a51bfcc5900808f7345965525a45b5/nova/virt/libvirt/driver.py#L6579-L6589
[2] https://issues.redhat.com/browse/OSPRH-20465?focusedId=28312726&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-28312726

Business justification (mandatory - Complete while in New status)

This feature is crucial for customers running large-scale OpenStack environments, especially those migrating from previous RHOSP versions (like 16.2) where non-UTC timezones were easier to manage across all nodes. but on the RHOSO, at least in OCP environment, only UCP is supported. So this issue is likely to appear in RHOSO.

Key benefits and necessity:

• Mitigation of High Business Risk:  
  As a Original Issue of OSPRH-20465, In Japan local timezone( The 9-hour time) discrepancy upon startup introduces system risk. In complex, multi-VM systems like Active Directory, the presence of VMs with uncorrected time discrepancies could, in the worst case, result in user data corruption.

• Scalability and Migration Support: 
  For example, If The customer manages an infrastructure serving approximately large number of the tenants (thousands) and anticipates migrating nearly all existing tenants to the new RHOSO18 environment. They also estimate having large number of the Windows VMs. The existing workarounds (e.g., manually setting the RealTimeIsUniversal registry key in Windows https://mskb.pkisolutions.com/kb/2687252 ) are non-realistic/impractical given this scale.

Functional requirements (mandatory - Complete while in New status)

The implementation should allow Nova to read local time zone information provided by the user  and configure the guest clock offset in libvirt/QEMU accordingly.

Describe the customer impact

IMPORTANT: Do not include customer names.

Related Jira is https://issues.redhat.com/browse/OSPRH-20465

The lack of this feature forces the customer to met this undesirable issue.
Non-scalable Workarounds: Relying on manual or guest-side image configuration changes (e.g., RealTimeIsUniversal), which is infeasible for 1,000 tenants and over 30,000 migrating VMs.