Hello Eric,
On Thursday 09 February 2012 23:01:38 Eric Blake wrote:
> > Questions:
> > 1. Handling of legacy XML domain configurations
> > I'm reluctant to define LIBVIRT_XEND_CLOCK_STRICT, since this would
> > probably break many existing XML configuration files, since they would be
> > rejected libvirt now for still using clock/@offset='utc'/'localtime'.
> > Luckily for us libvirt doesn't support snapshots with xen, because then
> > this XML configuration would be stored in the snapshot meta data,
> > rendering them all invalid.
>
> We absolutely cannot reject existing older xml files; but must load them
> with the semantics that make sense.
>
> If I understand correctly, the situation is that old clients had:
>
> <clock offset='localtime'/>
>
> whereas the semantics are more correctly listed as your proposed:
>
> <clock offset='variable' adjustment='nnn' basis='localtime'/>
>
> and you are worried that if you rewrite the former into the latter, you
> are preserving the semantics that make the most sense as a default, but
> you are making it impossible to implement alternate semantics that are
> also possible with xen and which are documented as the current behavior.
More or less: With current libvirt-0.9.9 you don't get what you request. The
user requests "localtime" or "utc" (think about a PC in kiosk-mode, where you
want the RTC to be reset), but you get "variable", where the previous offset
is preserved and thus the state is not fully reset.
What makes it worse is that xen changed its behaviour, but libvirt didn't
notice it.
> 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.
> When writing XML back out via dumpxml, libvirt would generate either the
> offset='utc' adjustment='reset', or the offset='variable'
> adjustment='nnn' basis='utc'; and would not generate offset='utc'
> adjustment='nnn', even though that is a valid input form.
This is the only point I (slightly) dislike, since then there would be two
ways to archive the same configuration, but I think this is worth paying for
the price of backward compatibility.
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