Re: [Qemu-devel] Rethinking missed tick catchup

[Gleb Natapov <gleb@redhat.com>]

On Thu, Sep 13, 2012 at 09:06:29AM -0500, Anthony Liguori wrote:
> "Daniel P. Berrange" <berrange@redhat.com> 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.
> 
With RTC configured to use vm clock we will not.

> 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.
And if guest does not have qemu-ga what is better inject interrupts like
crazy for next 2 minutes or leave guest with incorrect time?

> 
> 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 :|

--
			Gleb.