[libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for <clock offset='variable' basis='utc'/>

[Eric Blake]

On 05/23/2014 08:54 AM, Eric Blake wrote:

>   For this to work, a
> persistent guest definition needs to record the offset that was in use
> at the time the guest powered off, and the next time qemu is started,
> pass _that_ offset as the command-line offset against UTC.  In libvirt's
> case, we intentionally run qemu to stay alive even after the guest
> quits, and send an event that the guest is no longer running; this event
> could be our trigger to read the qemu offset and adjust the persistent
> state to track the new offset to use on the next boot of the guest.

Hmm, I wonder if we have a libvirt design dilemma on our hands.
Remember, ever since qemu exposed the -no-shutdown flag, we have been
using it in libvirt.  It says that even though the guest has quit
executing, the qemu process must stick around until we explicitly let go
of it.  This is because the guest can shut down during a libvirtd
restart, so the new libvirtd can still connect to the qemu process,
learn that the guest has shut down, and take appropriate actions (query
qemu for other details like the final state of the RTC offset, tidy up
any transient XML, generate the libvirt event to management app, etc).
As long as the libvirt guest is persistent, the management app can still
query about the guest even after it shuts down.

But VDSM uses only transient guests.  Similar to how libvirt uses
-no-shutdown to keep qemu hanging around until libvirt acknowledges that
the guest is done, what recourse does VDSM have to keep a transient
guest's virDomainPtr around (even across libvirtd restarts) until VDSM
has had time to query the RTC offset from libvirt?  That is, since the
only libvirt use of RTC offset is to adjust the persistent definition
for the next boot, but VDSM is using only transient guests, VDSM needs a
way to track the RTC offset to tell libvirt to use the next time VDSM
creates a new transient guest for the same disk image.  Or put another
way, the moment that libvirt offloads persistence to a higher level
application, that higher level application needs a way to grab all
information that libvirt would have grabbed for a persistent guest,
which means a transient guest needs to exist in the shutoff state for at
least as long as VDSM hasn't closed it.  Do we have a design flaw in
that currently libvirt gets rid of transient guests as soon as they
shutdown, rather than waiting for management to close their last
reference to the shutdown domain?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140523/991e08a8/attachment-0001.sig>