Re: [libvirt] [PATCHv2 0/3] Xen: Fix <clock> handling
Hello Eric,
On Monday 13 February 2012 18:43:21 Eric Blake wrote:
> 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.
Once we add a new attribute, we can document that domain XML that omits
the attribute will default to hypervisor-specific choices (xen < 3.1 can
default one way, xen >= 3.1 can default another way, and qemu can
default in a particular way as well). If the user provides the
attribute, then they are requesting the specific behavior that they need.
v3 implements this as following:
adjustment='reset' forced the old behaviour with xen; xen-3.1 will reject
those HV-domains.
adjustment='$timeDelta' gets directly converted to offset='variable'.
No. We _don't_ want a libvirt version attribute. What we want
is a new
attribute that, if present, determines the behavior according to the
user, and if absent, provides sane upgrade semantics when parsing older
XML into newer libvirt.
Okay. Thank you for your explanation; makes sense.
You still haven't managed to convince me that we cannot solve
this by
adding new attributes.
I still find it a little bit strange to add an attribute to force the parser
to the old behaviour of utc/localtime, which was perfectly clear. But if it
improves compatibility, I'm fine with this solution.
Thank you for your feedback so far.
BYtE
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/
Attachments:
- signature.asc (application/pgp-signature — 197 bytes)