[libvirt] [PATCH] Xen: Fix <clock> handling

[Philipp Hahn]

Hello Daniel,

On Tuesday 17 January 2012 22:24:11 Daniel P. Berrange wrote:
> On Tue, Jan 17, 2012 at 05:02:14PM +0100, Philipp Hahn wrote:
> > For PV, Xen implements the <clock offset='utc'> and <clock
> > offset='localtime'> behaviour, while for HV it implements <clock
> > offset='variable'>.
> > This difference is important for domUs, which switch daylight saving on
> > there own, since the state is kept inside the VM and must be in sync
> > with the RTC provided by Xen.
>
> What versions of Xen is that true for ?  I didn't think that old
> versions behaved this way for HVM. The libvirt Xen driver is still
> intended to support the RHEL5 vintage Xen code (which is based on
> 3.0.3)

To me it looks like CentOS5 (since I don't have RHEL5) has the Xen-3.0.3 
user-land XenD (rpm -q xen → xen-3.0.3-132.el5) but the Xen-3.1.2 hypervisor 
(xm info → 3.1.2-.2-274.el5). Relevant for this change seems only the version 
of XenD, which returns xendConfigVersion=2.

This is a version without "managed domain" support, which was added in the 
3.1.x branch <http://xenbits.xen.org/hg/xen-3.1-testing.hg/rev/7e431ea834a8>.
The generation bump to xendConfig_version=3 happend in 3.0.4 for "Live Cycle" 
support <http://xenbits.xen.org/hg/xen-3.0.4-testing.hg/rev/1c51c580dc05>. 
The bump to 4 was in the 3.0.5 → 3.1.0 transition 
<http://xenbits.xen.org/hg/xen-3.1-testing.hg/rev/887fa548f650>

So for XenD version _ its _:
- < 3.1: "utc" or "localtime" (because there is no XenD keeping track of the 
modified rtc_timeoffset)
- >= 3.1: managed HV domains: "variable" (XenD keeps track)
- >= 3.1: managed PV domains: "utc" or "localtime" (they don't have a RTC but 
can access a PV-clock, which gets initialized to either "utc" or "localtime". 
As far as I know the offset can't be changed by the domU and is not visible 
in any tool, only the "is_utc/localtime" flag is visible)
- >= 3.1: "xm" domains: same as with "managed domains". The "variable" offset 
is tracked by XenD and survives a "reboot", but as with other transient 
domains, the information is lost after "destroy".

Patch will (hopefully) follow soon.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn at univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120131/63c77fc8/attachment-0001.sig>