Hello Eric,
On Monday 13 February 2012 08:51:41 Philipp Hahn wrote:
> On Thursday 09 February 2012 23:01:38 Eric Blake wrote:
...
> > But a better idea is to represent the XML in a way where the default
> > conversion makes sense, but where a user can explicitly change the XML
> > to get what they want. I'm thinking:
> >
> > If offset is 'utc' or 'localtime', we add a new attribute 'adjustment'
> > ...
>
> I'll give your approch a try, since I think this solves the problem with my
> STRICT.
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@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:
signature.asc
Description: This is a digitally signed message part.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list