[Xen-devel] [BUG, PATCH-RFC] libvirt localtime and rtc_timeoffset handling in xen-sexpr/sxpr/sxp

[Philipp Hahn <hahn@xxxxxxxxxxxxx>]

Hello,

I'm currently tracking a problem in libvirt regarding Xens handling of 
localtime and rtc_timeoffset. My current understanding (Xen-3.4.3 and 
Xen-4.1.2 under Linux) of Xend (the depcrecated Python one still used by 
libvirt) is as this:
- for HV domains, the RTC gets setup to either UTC or localtime depending 
on "/domain/image/hvm/localtime" Â "/domain/image/hvm/rtc_offset".
- if the OS of a domU changes its RTC, the rtc_offset gets adjusted and is 
saved in XenStore as "/vm/$UUID/rtc/timeoffset".
- if the dom0 accesses its RTC, is accesses the real HW-RTC.
- the Xen-Hypervisor initially read the HW-RTC to setup its Wallclock once, 
which is than used to simulate the domU RTCs. (The HW-RTC is otherwise only 
accessed on (ACPI-)Suspend and Resume, and with NTP-drift-correction from 
dom0).
- on shut-down the rtc_offset is stored by Xend in 
the "/var/lib/xend/domains/$uuid/config.sxp" file 
in "/domain/image/hvm/rtc_timeoffset", from where it is loaded again on next 
start.
- since PV domains don't have a RTC, they somehow(?) get either initialized to 
the localtime or UTC time depending on "/domain/image/linux/localtime".

@xen:
Did I figure out that correct?

@xen:
Is there some documentation on the Xen-sxp domain configuration? For the 
Python based xen-xm format, I found (and updated) 
<http://wiki.xen.org/wiki/XenConfigurationFileOptions>, but for Xen-sxp I so 
far found no documentation, especially on what changed between xen-1, xen-2, 
xen-3.x, xen-4.x.

@libvirt:
Comparing Xend handling to <http://libvirt.org/formatdomain.html#elementsTime> 
the current translation done by libvirt looks wrong; I think is mandates back 
to the time when Xen supported only PV-domUs:
libvirt translates the Xen configuration to "localtime" and "utc" ignoring 
the "rtc_offset", which exists for HV domains. For localtime=0 this 
translates to libvirts offset="variable"-case, but for localtime=1 there is 
no matching mapping in libvirt.
Since for PV domains no rtc_timeoffset is tracked, there the mapping to "utc" 
and "localtime" looks right.


For libvirt there was a patch 
<http://www.redhat.com/archives/libvir-list/2009-January/msg00757.html> which 
added some special handling for "localtime" to be either placed 
in "/domain/localtime" or "/domain/image/{hvm,linux}/localtime". Xend from 
3.4.3 und 4.1.2 seems to accept either one, but /domain/image/hvm/localtime 
is preferred and overwrites the first one. When reading back the 
configuration the setting is always returned 
as /domain/image/{hvm,linux}/localtime.

@John:
Is there a case, where /domain/localtime is returned or is that key 
always translated to /domain/linux/{hvm,linux}/localtime? As you had a 
sun.com email address, was this some special case when using Xen with 
Solaris?

@libvirt:
The attached patch (for 0.8.7) would change the implementation to match the 
following:
1. For Xen-PV-domUs, use clock/@offset='utc' and clock/@offset='localtime'.
2. For Xen-HV-domUs, use clock/@offset='variable'.
3. For backward compatibility with old libvirt-XML-files convert 
clock/@offset='utc' â (localtime 0)(rtc_timeoffset 0) and 
clock/@offset='localtime' â (localtime 1)(rtc_timeosset 0). On readback that 
will be returned as clock/@offset='variable'!
4. For Xen-HV-domUs with (localtime=1)(rtc_timeoffsetâ0) print a warning that 
there is no mapping to libvirts XML.
5. Always put the (localtime)(rtc_offset)-SEXPRs in "(image ({linux,hvm})", 
since this is where Xend-3.4 and Xend-4.1 return them.
I also checked Xen-3.2, where this is okay, but the I don't have any older 
versions of Xen available (and running), the I can't verify that it still 
works there.

Which leads me to a another question: Which versions of Xen are still 
supported by libvirt (and must be checked for regressions)? I don't want so 
actively remove the code for old Xen versions, but it gets harder and harder 
to maintain all those versions. So a statement like "Xen-3.x and Xen-4.y are 
actively supported by libvirt-0.a.b; older versions might still work (by 
accident ;-)"

Before I forward-port that change to 0.9.10 I'd like to get some comments. 
Thanks in advance.

Sincerely
Philipp Hahn
-- 
Philipp Hahn           Open Source Software Engineer      hahn@xxxxxxxxxxxxx
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/

Attachment: localtime.diff
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel