On Thu, Sep 13, 2012 at 09:06:29AM -0500, Anthony Liguori wrote: > "Daniel P. Berrange" <berra...@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.
