On Feb 8, 2008 3:46 PM, Tom Horsley <tom.horsley@xxxxxxx> wrote:
> On Fri, 8 Feb 2008 15:34:29 -0800
> [...]
> I'm not sure what fixed it, but I noticed that the failsafe boot didn't
> have the problem, and when I copied "apm=off acpi=off noapic" that the
> failsafe boot had to the primary kernel boot parameters, the problem
> disappeared (I have no idea why that made it disappear, or which
> one was important :-).
Outstanding! However...my guess is that nothing actually "fixed" the
problem, and that if you went back to the same conditions as when it
happened last time - _really_ went back... which is sometimes
downright impossible... that you'd find that particular HVM time-skew
problem to still be right where it's always been. I hope. I'll
explain that better below, (again) I hope.
It's awesome that you've got HVM virt working much better with the
triad of kernel params you've mentioned above - that qualifies as a
"major clue" (read: it should be in a FAQ somewhere if it isn't yet)
both (1) for others who want to get HVM virt working well, and (2) for
me in particular, since _omitting_ those options as part of my testbed
scenarios never even entered my mind until I found out you'd
experienced problems when (accidentally) omitting them.
So... Thank you - big time! (getting tired of the time-related puns
yet? are they... untimely?)
The wallclock on your HVM may or may not be "right" now, though. From
what you've said, things appear _much better_ and the wallclock is not
wildly out of kilter as it was before.
You'll still want to keep a close eye on it, test it slowly - not
quickly - for example, ask it what time it is every hour, and see if
it stays relatively accurate or if there's a tendency for the answer
to get, pardon my non-english, wronger-and-wronger over time. That
test is much more telling than say, a forever loop that prints a
timestamp then sleeps for one second. In the second case, the
observer's become way too much a part of the equation to be providing
really useful and/or (time-)telling information; its results are in
fact often totally misleading as compared to the results of a more
subtle wallclock-sampling approach.
My recent development effort (the ruby-based time monitor and
skew-correcting feedback-loop) is being influenced by a lot of fun
design criteria - including subtlety, a careful attention to the fact
that observers really _are_ part of whatever equations they're in...
but mostly it's been fueled by a driving need for something solid to
help with the particularly thorny issue of wallclock skew in virtual
environments.
...I seem to be putting this thing more and more on my own "front
burner" now, aren't I? ...that's a sign maybe I'll finish it up and
release it sometime soon. :-)
-pbr
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home