[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 21/05/13 11:47, David Vrabel wrote:
On 21/05/13 11:22, Diana Crisan wrote:

On Mon, May 20, 2013 at 11:38:45PM +0100, Alex Bligh wrote:

--On 20 May 2013 15:28:52 -0400 Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> 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
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
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.


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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.