This is the second time this has happened to me, so I'm writing to you, my future self, a quick note so you don't have to relearn this a second time.
If when restarting a DomU, the DomU hangs at "Checking for hardware changes", check on the Dom0 to see if your xenconsoled has died. If so, restart it (ie. /usr/sbin/xenconsoled) and it should immediately fix the hanging DomUs.
This guy has a blog post with same issue, but I don't think he ever figured it out because he took a scorched-earth route to fix the problem. However, it does have a nice screen shot of what the hung DomU looks like.
Thursday, May 13, 2010
Saturday, February 27, 2010
Monday, February 01, 2010
I grabbed some time formatting code from an older project of mine to use in my current project.
However, I noticed that the constants defined at the top of the class had some weird values. The constant, number of milliseconds per whatever, was ending in a 1 instead of a 0. My first thought was that a co-worker had mangled my source to fix some stupid off-by-one time issue they were having, incidentally breaking everything else that relied on that constant.
While 600 to 601 is a plausible change, 60 milliseconds per minute to 600 milliseconds per minute should have set off alarm bells in my head.
I spent several minutes grepping through the svn repository trying to find the lazy rat-bastard that had messed with my code, only to find that it wasn't a '601' but a '60l' (60L). The L is there to force the value into a long integer type.
Lesson learned? Use uppercase L.