On 02.05.2016 16:36, Peter Krempa wrote: > On Fri, Apr 29, 2016 at 18:43:10 +0200, Michal Privoznik wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1139766 >> >> Thing is, for some reasons you can have your domain's RTC to be >> in something different than UTC. More weirdly, it's not only time >> zone what you can shift it of, but an arbitrary value. So, if >> domain is configured that way, libvirt will correctly put it onto >> qemu cmd line and moreover track it as this offset changes during >> domain's life time (e.g. because guest OS decides the best thing >> to do is set new time to RTC). Anyway, they way in which this >> tracking is implemented is events. But we've got a problem if >> change in guest's RTC occurs and the daemon is not running. The >> event is lost and we end up reporting invalid value in domain >> XML. Therefore, when the daemon is starting up again and it is >> reconnecting to all running domains, re-fetch their RTC so the >> correct offset value can be computed. >> >> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> >> --- >> src/qemu/qemu_process.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 44 insertions(+) >> > > [...] > >> int >> qemuProcessRefreshBalloonState(virQEMUDriverPtr driver, >> @@ -3679,6 +3720,9 @@ qemuProcessReconnect(void *opaque) >> if (qemuRefreshVirtioChannelState(driver, obj) < 0) >> goto error; >> >> + if (qemuRefreshRTC(driver, obj) < 0) >> + goto error; > > Any failure in qemuProcessReconnect results into libvirtd killing the > process. I don't think this failure is criticall enough to allow such > brutality. > > Peter > Well, if guest has updated its RTC while we were not running, we would report spurious time in our XML. Since we are doing something similar for ejectable disks, i.e. CDROMs too, I presumed it is okay. But I don't mind changing this to something softer. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list