Re: [libvirt] [PATCHv2 0/3] Xen: Fix <clock> handling

Hello Eric, On Monday 13 February 2012 08:51:41 Philipp Hahn wrote: ... I encountered some problems while thinking more about your suggestions: 1. The problem here is that the libvirt XML parser (virDomainDefParseString()) is more or less driver agnostic and thus does not know, which variants of clock/@offset are supported by the driver: For example since for qemu the XML is used as the native format, some values are only checked when you run the domain, that is when the XML in converted to command-line arguments to kvm. So your extra @reset and @adjustment attributes need to be pased into "struct _virDomainClockDef". I see no canonical location to then convert <clock offset='utc' adjustment='42'/> to <clock offset='variable' adjustment='42' basis='utc'/> for everything but Xen-HV≥3.1, so the check / conversion has to be done for every single driver. 2. Instead of implementing a second variant of offset='variable' it would be enough to just add an attribute reset='true' (or this_is_not_from_a_buggy_libvirt_and_I_really_need_the_reset='true') to dumpxml, when a driver really implements the reset semantics. As long as it's missing, libvirt can convert it to reset='false' in the Xen≥3.1 case. With an explicit reset='true' libvirt would return an error for Xen-HV≥3.1. A more general solution would be to add a libvirt-version attribute to the XML data, which libvirt could use to implement a bug-compatibility-mode: If we're reading an old XML, treat offset='utc' as offset='variable', but if it's an XML from ≥0.9.10, return an error. (how to treat XML without an explicit version?) Yes, I know that the libvirt XML is supposed to be backward compatible, but errors happen. Sincerely Philipp Hahn -- 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/