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

[David Vrabel <david.vrabel@citrix.com>]

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.

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?

David

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