On Thu, Sep 13, 2012 at 09:35:18AM -0500, Anthony Liguori wrote:
> Gleb Natapov <g...@redhat.com> writes:
>
> > On Thu, Sep 13, 2012 at 09:06:29AM -0500, Anthony Liguori wrote:
> >> "Daniel P. Berrange" <berra...@redhat.com> writes:
> >>
> >> 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.
>
> Not for host suspend. For stop and live migration, we stop vm_clock.
> But QEMU isn't aware of host suspend so vm_clock cannot be stopped.
>
Hmm, true. What about hooking into suspend and doing vmstop during
suspend.
> >> 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?
>
> Yes, at least that's fixable by the end-user. QEMU consuming 100% CPU
> for a prolonged period of time isn't fixable.
>
You mean yes to "leave guest with incorrect time"? QEMU will still
consume 100% of cpu for some time calling qemu_timer callback millions
times. timedrift code is not the right level to fix that.
--
Gleb.
