Re: [libvirt] [PATCHv4 0/3] Xen: Fix clock handling
Hello, On Tuesday 28 February 2012 13:42:05 Philipp Hahn wrote: On Tuesday 14 February 2012 19:07:21 Philipp Hahn wrote: Before version 3.1 xen only implemented clock/@offset='utc' and 'localtime'. With the introduction of managed domains in 3.1 xend keeps track of the rtc_timeoffset, even over reboots. This translates to libvirts clock/@offset='variable' variant. Be advised that only HV domains have a RTC. In addition xen also supports a variant where the offset is tracked to 'localtime', which is currently not supported by libvirt. To make matters worse, this was somehow broken in some versions of xen and was finally fixed with version xen-3.4. The following patch set ... * adds support for handling variable offsets relative to localtime, * fixes libvirt to use clock/@offset='variable' for newer xen versions, * adapts the test suit accordingly I've tested this on CenOS5 (xend-3.0.3 + 3.1.2 hypervisor?), UCS-2.3 (xen-3.2.1), UCS-2.4 (xen-3.4.3) and UCS-3.0 (xen-4.1.2). Ping? Ping^2? It would help me if I would get feedback from anyone ... currently I don't know if everbody has no time, if the patch still has issues, or if I collected some bad karma. Sincerely Philipp -- Philipp Hahn Open Source Software Engineer h...@univention.de Univention GmbHbe open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ signature.asc Description: This is a digitally signed message part. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Xen: Fix clock handling
On Wed, Mar 21, 2012 at 09:42:42AM +0100, Philipp Hahn wrote: Hello, On Tuesday 28 February 2012 13:42:05 Philipp Hahn wrote: On Tuesday 14 February 2012 19:07:21 Philipp Hahn wrote: Before version 3.1 xen only implemented clock/@offset='utc' and 'localtime'. With the introduction of managed domains in 3.1 xend keeps track of the rtc_timeoffset, even over reboots. This translates to libvirts clock/@offset='variable' variant. Be advised that only HV domains have a RTC. In addition xen also supports a variant where the offset is tracked to 'localtime', which is currently not supported by libvirt. To make matters worse, this was somehow broken in some versions of xen and was finally fixed with version xen-3.4. The following patch set ... * adds support for handling variable offsets relative to localtime, * fixes libvirt to use clock/@offset='variable' for newer xen versions, * adapts the test suit accordingly I've tested this on CenOS5 (xend-3.0.3 + 3.1.2 hypervisor?), UCS-2.3 (xen-3.2.1), UCS-2.4 (xen-3.4.3) and UCS-3.0 (xen-4.1.2). Ping? Ping^2? It would help me if I would get feedback from anyone ... currently I don't know if everbody has no time, if the patch still has issues, or if I collected some bad karma. Sorry about the delay; I think everybody is just really busy. AFAIK, nobody hates you. :) One thing that keeps me from reviewing it is that I don't have a Xen system handy to test it on. If there are folks with access to apropriate systems and willing to review, please speak up. Dave Sincerely Philipp -- Philipp Hahn Open Source Software Engineer h...@univention.de Univention GmbHbe open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 0/3] Xen: Fix clock handling
Hello, On Tuesday 14 February 2012 19:07:21 Philipp Hahn wrote: Before version 3.1 xen only implemented clock/@offset='utc' and 'localtime'. With the introduction of managed domains in 3.1 xend keeps track of the rtc_timeoffset, even over reboots. This translates to libvirts clock/@offset='variable' variant. Be advised that only HV domains have a RTC. In addition xen also supports a variant where the offset is tracked to 'localtime', which is currently not supported by libvirt. To make matters worse, this was somehow broken in some versions of xen and was finally fixed with version xen-3.4. The following patch set ... * adds support for handling variable offsets relative to localtime, * fixes libvirt to use clock/@offset='variable' for newer xen versions, * adapts the test suit accordingly I've tested this on CenOS5 (xend-3.0.3 + 3.1.2 hypervisor?), UCS-2.3 (xen-3.2.1), UCS-2.4 (xen-3.4.3) and UCS-3.0 (xen-4.1.2). Ping? Since v1: + fix handling of direct-PV-domains + added handling of localtime=1 + rtc_timeoffset + fixed test suite Since v2: (on feedback by Eric) + add the adjustment='reset' attribute to force the old behaviour + handle adjustment='$timeDelta' as a short-cut for the conversion to variable. + simplify error path handling + update version numbers to 0.9.11 Since v3: + Add missing offset=VARIALE for adjustment='$timeDelta' conversion. Philipp Hahn (3): Support clock=variable relative to localtime Xen: Fix clock handling Xen: Adapt clock tests @Eric: If I understood your proposal right, v4 should implement your transition path for xen. In our local tests it worked okay. Sincerely Philipp -- Philipp Hahn Open Source Software Engineer h...@univention.de Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ signature.asc Description: This is a digitally signed message part. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv4 0/3] Xen: Fix clock handling
Before version 3.1 xen only implemented clock/@offset='utc' and 'localtime'. With the introduction of managed domains in 3.1 xend keeps track of the rtc_timeoffset, even over reboots. This translates to libvirts clock/@offset='variable' variant. Be advised that only HV domains have a RTC. In addition xen also supports a variant where the offset is tracked to 'localtime', which is currently not supported by libvirt. To make matters worse, this was somehow broken in some versions of xen and was finally fixed with version xen-3.4. The following patch set ... * adds support for handling variable offsets relative to localtime, * fixes libvirt to use clock/@offset='variable' for newer xen versions, * adapts the test suit accordingly I've tested this on CenOS5 (xend-3.0.3 + 3.1.2 hypervisor?), UCS-2.3 (xen-3.2.1), UCS-2.4 (xen-3.4.3) and UCS-3.0 (xen-4.1.2). Since v1: + fix handling of direct-PV-domains + added handling of localtime=1 + rtc_timeoffset + fixed test suite Since v2: (on feedback by Eric) + add the adjustment='reset' attribute to force the old behaviour + handle adjustment='$timeDelta' as a short-cut for the conversion to variable. + simplify error path handling + update version numbers to 0.9.11 Since v3: + Add missing offset=VARIALE for adjustment='$timeDelta' conversion. Philipp Hahn (3): Support clock=variable relative to localtime Xen: Fix clock handling Xen: Adapt clock tests docs/formatdomain.html.in | 18 ++- docs/schemas/domaincommon.rng | 30 +++- src/conf/domain_conf.c | 61 +++- src/conf/domain_conf.h | 17 ++- src/libvirt_private.syms |1 + src/qemu/qemu_command.c|8 +- src/qemu/qemu_process.c|2 +- src/xenxs/xen_sxpr.c | 167 +++- src/xenxs/xen_xm.c | 123 --- .../qemuxml2argv-clock-variable.xml|2 +- tests/sexpr2xmldata/sexpr2xml-boot-grub.xml|2 +- tests/sexpr2xmldata/sexpr2xml-bridge-ipaddr.xml|2 +- tests/sexpr2xmldata/sexpr2xml-curmem.xml |2 +- .../sexpr2xml-disk-block-shareable.xml |2 +- tests/sexpr2xmldata/sexpr2xml-disk-block.xml |2 +- .../sexpr2xml-disk-drv-blktap-qcow.xml |2 +- .../sexpr2xml-disk-drv-blktap-raw.xml |2 +- .../sexpr2xml-disk-drv-blktap2-raw.xml |2 +- tests/sexpr2xmldata/sexpr2xml-disk-file.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-legacy-vfb.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml |2 +- .../sexpr2xml-fv-serial-dev-2-ports.xml|2 +- .../sexpr2xml-fv-serial-dev-2nd-port.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml |2 +- .../sexpr2xml-fv-serial-tcp-telnet.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-utc.xml |2 +- tests/sexpr2xmldata/sexpr2xml-fv-v2.xml|2 +- tests/sexpr2xmldata/sexpr2xml-fv.xml |2 +- tests/sexpr2xmldata/sexpr2xml-net-bridged.xml |2 +- tests/sexpr2xmldata/sexpr2xml-net-e1000.xml|2 +- tests/sexpr2xmldata/sexpr2xml-net-routed.xml |2 +- tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml |2 +- tests/sexpr2xmldata/sexpr2xml-pci-devs.xml |2 +- .../sexpr2xml-pv-bootloader-cmdline.xml|2 +- tests/sexpr2xmldata/sexpr2xml-pv-bootloader.xml|2 +- tests/sexpr2xmldata/sexpr2xml-pv-localtime.xml |2 +- tests/sexpr2xmldata/sexpr2xml-pv-vcpus.xml |2 +- .../sexpr2xml-pv-vfb-new-vncdisplay.xml|2
