[libvirt] [PATCH 2/2] qemu: Refresh RTC adjustment on qemuProcessReconnect

Michal Privoznik mprivozn at redhat.com
Mon May 2 16:35:35 UTC 2016

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 at redhat.com>
>> ---
>>  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.


More information about the libvir-list mailing list