Note that the problem Eric is describing exists during the window between when the guest changes its RTC while libvirtd is not connected, and the next time that the guest changes its RTC - at that time libvirtd will again have the correct offset. Of course if the domain is migrated or saved/restored while in this state, then the proper offset is lost forever, so it certainly is a bad problem that needs a solution.

As a matter of fact, once the command he suggests is implemented, any RTC_CHANGE event, regardless of clock settings, could simply ignore the sent offset and poll qemu for an up-to-date "offset from UTC" (which is what libvirt wants to send in its own RTC_CHANGE event).

(In reply to Laine Stump from comment #2)
> Note that the problem Eric is describing exists during the window between
> when the guest changes its RTC while libvirtd is not connected, and the next
> time that the guest changes its RTC - at that time libvirtd will again have
> the correct offset. Of course if the domain is migrated or saved/restored
> while in this state, then the proper offset is lost forever, so it certainly
> is a bad problem that needs a solution.
> 
> As a matter of fact, once the command he suggests is implemented, any
> RTC_CHANGE event, regardless of clock settings, could simply ignore the sent
> offset and poll qemu for an up-to-date "offset from UTC" (which is what
> libvirt wants to send in its own RTC_CHANGE event).

Its up to you to use RTC_CHANGE_EVENT (asynchronous) or query the offset
synchronously. Not sure what is the best option.

(In reply to Laine Stump from comment #2)
> Note that the problem Eric is describing exists during the window between
> when the guest changes its RTC while libvirtd is not connected, and the next
> time that the guest changes its RTC - at that time libvirtd will again have
> the correct offset. Of course if the domain is migrated or saved/restored
> while in this state, then the proper offset is lost forever, so it certainly
> is a bad problem that needs a solution.

If I'm understanding how things work, the RTC offset is part of the migration stream. For save/restore and live migration, we want the destination to start with the same command line as the source (and NOT fold the RTC offset into that command line) - that's because the destination qemu will apply the same RTC offset that it read from the migration stream as what the source qemu had left things in, with both qemu's doing it relative to the same reference point.  The ONLY time where libvirt needs to care about the RTC offset is when the guest stops - at THAT instant, libvirt needs to know the current RTC offset, and rewrite the persistent domain XML, so that the next time a new qemu process boots the same guest, the new qemu uses a NEW command line offset based on the old qemu's command-line offset + the old qemu's RTC offset when the guest shut down (that is, every time a new qemu process boots fresh, rather than doing an incoming migration, the RTC offset resets to 0, so to avoid losing that RTC offset from before, the command line offset has to be adjusted).

So yes, if libvirt doesn't know the current RTC offset when a guest shuts down (because it missed an event and the guest shuts down prior to causing another RTC change event), then libvirt will write the wrong time into the domain xml, and the next boot of the guest will have the wrong time.

It also raises the point that for transient guests, the management app using libvirt needs a way to query what the current RTC offset is.  Just as libvirt cannot rely on qemu events always being delivered, VDSM cannot rely on libvirt events always being delivered.  So if a transient guest shuts down, VDSM still needs a way to query what the RTC offset of that guest was at the time it shut down, so that VDSM can then create a new transient guest with the correct offset for the next time that guest is to be booted.  But that raises the question - if a transient guest shutting down makes the guest disappear, then what recourse does VDSM have to get that information?

Clone for RHEL7: Bug 1110429 (if this is fixed upstream and included in RHEL7 already, please close it).

Marcelo said offline that this fix depends on QOM and the fix would be too intrusive in RHEL6. Can/should we close it in RHEL6?

How hard would it be to provide a downstream-only __com.redhat_query-* command to get at the information in RHEL 6 without backporting QOM?  I'm not sure what the demand is for this; and upstream libvirt still hasn't been patched to take advantage even of the QOM solution.  It's a bit hard to say how much work we need to take on without knowing who needs the information to be accurate and without knowing how easy or hard it is to get libvirt to take advantage of the information once it is available upstream.