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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]