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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list