Re: HVM Migration of domU on Qemu-upstream DM causes stuck system clock with ACPI

[Diana Crisan <dcrisan@flexiant.com>]

On 21/05/13 11:47, David Vrabel wrote:
> On 21/05/13 11:22, Diana Crisan wrote:
>> Hello,
>>
>>> On Mon, May 20, 2013 at 11:38:45PM +0100, Alex Bligh wrote:
>>>> Konrad,
>>>>
>>>> --On 20 May 2013 15:28:52 -0400 Konrad Rzeszutek Wilk
>>>> <konrad.wilk@oracle.com> wrote:
>>>>
>>>>> It was actually David (CC-ing him here). Alex, when you boot the hosts,
>>>>> are the RTC times the same? (date?)
>>>> I believe they boot with ntpdate and run ntp, so the wallclock times are
>>>> the same. I haven't specifically checked the CMOS clock times if that's
>>>> what you meant - I'm not even sure how one does that - but I believe
>>>> ntp writes to the CMOS RTC these days.
>>> 11 minutes after ntpd has started.
> NTP updates the persistent clock when it is first synchronized and then
> every 11 minutes.
>
>> I have checked our machines and they aren't running ntpd, but they
>> were synchronised with ntpdate. The date command showed the wallclock
>> was in sync and clock -r showed the rtc was also in sync. Both cases
>> have a delay of at most 1 second.
> Running ntpdate does /not/ set the persistent wallclock so the
> persistent clock may be incorrect however if the CMOS RTC is correct on
> both machines then the persistent clocks will be approximately the same
> anyway.
> So, you could try the wallclock[1] series but I think it is unlikely to
> help here.
>
> It looks like the guests may not be properly notified of a resume (after
> the migration) and therefore are not properly accounting for the step
> change in their clock source.  This means migrations one way look like
> the clock source as stepped backwards and I guess this is confusing the
> kernel as the close source is supposed to be monotonic.
>
> Migrations the other way then work fine as the clock source steps
> forwards not backwards.
Actually, I have seen the problem replicated when the vm migrates back 
to the original host ( the one it was started on), as well as on a first 
migrate. I can confirm I alternated between the hosts on the creation of 
the vm to ensure I get all the possible scenarios. This was done without 
re-synchronising the hosts.
> Can you restart the hosts say, 5 minutes apart and then see if the
> guest's time recovers (without manually setting the time etc.) within ~5
> mins?
I restarted the hosts as you asked 5 minutes apart and the wallclocks 
and the hardware clocks are still in sync without having run any manual 
update/ ntpdate on the clock.

> David
>
> [1] http://lists.xen.org/archives/html/xen-devel/2013-05/msg01399.html