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

> 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.

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' ...

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.