The Deep End | Paul Venezia » September 2007

September 27, 2007 | Comments: (0)

VMware Workstation VMM issues resolved in 2.6.22?

TAGS: Gear, Systems, Virtualization

For those unaware, VMware Workstation 6 has been exhibiting some significant stability issues under some 2.6.19 and 2.6.20 kernels. VMware Workstation would run and behave normally for some period of time, then crash with a VMM (VM Monitor) error, and take down the X11 subsystem, requiring a reboot of the whole system. I saw clear evidence of this under Fedora Core 6 x86_64 on these kernels, but not on the 2.6.18 kernel. There were several threads dedicated to this problem on VMTN, and a few possible fixes offered, but none worked. I resigned myself to running the VMware Server Console on my workstation, and housing my VMs on a different VMware Server system, which definitely has some benefits over running them locally, but I was bothered by this mysterious issue. My main workstation is a Sun Ultra 40 M2 with two dual-core Opteron 2220s and 8GB of RAM, so using that to drive VMware Workstation for my Windows needs is really the best option from a performance and functionality standpoint.

Since then, a FC6 kernel update to 2.6.22 was released, and rather than step back to 2.6.18 on that system, I tried going up to 2.6.22. That was about a week ago, and the VMware Workstation instance on my main workstation has been stable since. I haven't found any direct reason for the problem, or its resolution, but there you have it. Also, for those curious on getting the VMware Workstation components to compile and run on Fedora or other distributions, you'll likely need the VMware any-to-any patches found here.

Posted by Paul Venezia on September 27, 2007 10:42 AM

September 04, 2007 | Comments: (0)

Quality time with hold music

TAGS: Life, the Universe and Everything, Systems

To make a very long story short, an Exchange server experienced catastrophic hardware failure, scrambled the mailstore, and was rendered completely inoperable. An hour on the phone with HP resulted in a promise that the warrantee replacement parts would arrive within 24-48 hours, no guarantee. However, an "uplift" service was available for the low, low price of $2,500 to expedite parts for next day. The whole server cost less than $2,500. Instead, I found a refurbished 1U server locally for around $1k with twice the resources of the original. We rebuilt the Exchange server, only to find the mailstore corruption. 11 hours later, the mailstore repair tools had finished and the mailstore was finally remounted... with errors.

Some (not all) users could access their mailbox, but were not receiving new mail. The errors in the event log elicited only two hits on Google, and none on Microsoft's site. The two hits were related to the same forum post with no resolution -- useless. Microsoft's own tools for locating resources pertaining to this error went nowhere. The actual error is from source MSExchangeIS Mailbox, ID 1025, error data "An error occurred on database "First Storage Group/Mailbox Store (MAIL). Function name or description of the problem: SLINK::EcUpdate Error: 0xfffffa84". Since I could find references to part of this error, but nothing about it in it's entirety, I had to call Microsoft. That's where the fun started.

After calling in and navigating half a dozen voice prompts, I spoke with a customer service rep who kindly took my credit card information for a $245 charge, gave me a case number, and told me that the tech queue wait time would be 5 minutes or so. I waited on hold for 62 minutes before I got a tech with a very heavy accent. He asked for the case number. I was surprised that he didn't have it already. How could he not have it? I was on the same call. I looked around and couldn't find the paper I'd jotted it down on over an hour earlier. I asked if he could look it up, and he brusquely transferred me back to the CSR pool. While he did this, I found the number. I checked it with the new CSR representative, and discovered that I'd been given the wrong number to begin with. Then, I was told that I'd be put back in the queue, with a hold time of only 45 minutes. I spoke with a supervisor who was very sorry that this was the case, but there was nothing he could do. Back I went into the land of Nod.

I was two hours and $245 into a service call to Microsoft to find more information on their own error code that isn't referenced anywhere on their site that I could find. I finally got a tech for the second time, who asked for the case ID, interrupted me twice while I was trying to give it to her, then abruptly hung up on me. Livid doesn't begin to describe my state of mind. I've worked with Microsoft enterprise products for a decade, and I've never had to call them before. That's truly a blessing.

What a racket. I'd love to get $245 to abuse my customers like this. I'd be a billionaire.

Posted by Paul Venezia on September 4, 2007 02:43 PM