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

Hello Daniel, On Tuesday 17 January 2012 22:24:11 Daniel P. Berrange wrote: 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(a)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/