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

[Michal Privoznik]

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.

Michal