Re: [Qemu-devel] Rethinking missed tick catchup

[Anthony Liguori]

"Daniel P. Berrange" <address@hidden> writes:

> On Thu, Sep 13, 2012 at 07:14:08AM -0600, Eric Blake wrote:
>> On 09/13/2012 04:49 AM, Gleb Natapov wrote:
>> >> They do if you hibernate your laptop.
>> >>
>> > AFAIK libvirt migrates vm into a file on hibernate. It is better to move 
>> > to S3
>> > (using qemu-ga) instead and migrate to file only if s3 fails.
>> 
>> On host hibernate, libvirt currently does nothing to the guest.  When
>> the host resumes, the guests see a large gap in execution.
>> 
>> Libvirt would need a hook into host hibernation, to have enough time to
>> tell the guests to go into S3 prior to allowing the host to go into S3.
>> 
>> On host reboot, libvirt currently saves guests to disk using migrate to
>> file.  The ideal solution would be to first tell the guest to go into S3
>> before migrating to file, but the migration to file STILL must occur,
>> because the host is about to reboot and S3 is not persistent.  S3 is a
>> better solution than S4, in that S4 requires the guest to have enough
>> memory (and if it doesn't cooperate, data is lost), but with S3, even if
>> the guest doesn't cooperate, we can still fall back to migration to file
>> with the guest only losing time, but not data.
>
> Trying to hook into host S3/S4 and do magic to the guests is just
> asking for trouble. Not only can it arbitrarily delay the host going
> into S3/S4, but it is not reliable in general, even for OS which do
> support it. Much better off hooking into the resume path on the host
> and issuing a QEMU GA call to each running guest to resync their
> clocks

I think it's better for QEMU to talk to qemu-ga.  We can tell when a large
period of time has passed in QEMU because we'll accumulate a large
number of missed ticks.

This could happen because of stop, host suspend, live migration to a
file, etc.

It's much easier for us to call into qemu-ga to do the time correction
whenever this event occurs than to try and have libvirt figure out when
it's necessary.

We know exactly when it's necessary, libvirt would need to guess.

Yes, we could generate a QMP event when a large skew was dedicated, but
I think this could happen often enough that it would be problematic.
Since QEMU is already implementing policy doing timer catchup in the
first place, I think we probably should own time catchup policy entirely.

Regards,

Anthony Liguori

>
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|