Red Hat Bugzilla – Bug 484665
THe <clock offset='localtime'/> is not honoured for RHEL-5 Xen
Last modified: 2009-12-14 16:23:32 EST
Description of problem:
Create a guest config with /etc/xen/demo with 'localtime=1', this translated to the XML <clock offset='localtime'/>
If you start this guest with 'xm create', the guest's BIOS clock is synced to localtime. If you start the guest with 'virsh start' the guest's BIOS clock is still synced to UTC
This is a regression which appears to have been related to the rebase of QEMU in RHEL-5.1 xen.
Previously the XenD SEXPR wanted '(localtime 1)' inside the image/hvm part of the SEXPR. THis is still allowed, but the QEMU code for using this is stubbed out to a no-op, and QEMU actually initializes its BIOS clock via a hypercall.
The hypervisor is setup with an RTC offset based off the '(localtime 1)' setting at the top level of the SEXPR.
libvirt needs to be updated to set '(localtime 1)' at both the top level, and within the image/hvm section. It should also do it for PV and HVM, not just HVM.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure host with BIOS in UTC, and timezone set to EST
2. Boot guest with virsh start, with localtime=1 in /etc/xen/demo
3. Login to guest and run 'date -u'
The BIOS clock is still UTC
The BIOS clock is synced to EST
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being proposed as a blocker for this release.
Please resolve ASAP.
Just spent an hour chasing this one around, please fix.
Created attachment 337305 [details]
Set localtime at top level of SEXPR
That patch was actually included as part of the 0.6.3 rebase, so the fix
is in the current build,
Configure host with BIOS in UTC, and timezone set to EST.
# virsh list --all
Id Name State
0 Domain-0 running
2 demo shut off
- foo1 shut off
# virsh edit demo
Domain demo XML configuration not changed.
# virsh start demo
Domain demo started
Sun Jun 7 18:16:32 EST 2009
# date -u
Sun Jun 7 18:16:57 UTC 2009
This bug was fixed, verified with libvirt 0.6.3-6 on RHEL-5.4
Experiencing the same problem with libvirt on RHEL-5.3 it seems (using Xen HVM for running Windows). Assuming that the patch might fix the problem at hand here as well, could this be integrated for 5.3 as a backport? I assume nobody yet used "localtime" on 5.3 or he suffered the same problems we see - so I don't really see this a "compatibility-break" but a badly needed fix.
(In reply to comment #10)
> Experiencing the same problem with libvirt on RHEL-5.3 it seems (using Xen HVM
> for running Windows). Assuming that the patch might fix the problem at hand
> here as well, could this be integrated for 5.3 as a backport? I assume nobody
> yet used "localtime" on 5.3 or he suffered the same problems we see - so I
> don't really see this a "compatibility-break" but a badly needed fix.
If you go through your normal RedHat support channels, you can request a fix for the older RHEL releases.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
Could it be that errata-link is wrong? Returns a 404.