Monday, November 12, 2007

Ubuntu Gutsy Xen Kernel Panic

A couple of weeks ago I installed Ubuntu 7.10 (Gutsy) on a decent Intel branded Xeon server, with the purpose of running it as a Xen server. I planned to run 4 or 5 Gutsy domUs on it with Apache, etc for various internal web apps.

After doing the usual aptitude setup business on the host machine, I started provisioning the guest images, etc. During the debootstrap process (read: heavy disk I/O), the host server would kernel panic and fall over. I tested similar operations with the non-Xen kernel and the server was stable. I assumed that there was some disk I/O compatibility issue between the Xen kernel and my Intel SRCU42X Raid card, and abandoned the idea of Gutsy. I used Feisty for the host and guests instead, with no problems.

Then, a few days ago (just to humor myself), I tried again to set up a Gutsy Xen server on a basic desktop machine. Dual core Athlon 64 3800+, nForce 4 chipset, single 80GB SATA drive: Same issue - kernel panics during heavy-ish disk I/O operations.

So for now, there is no way I'm using the Xen kernel in Gutsy. Xen on Feisty seems to be really stable on the 4 or 5 boxes that I have running it. The one problem with this is that debootstrap in Feisty doesn't have the scripts for building a Gutsy guest image, so it's a manual process for running Gutsy guests on a Feisty host.

Saturday, November 3, 2007

Exchange 2003 Offline Defrag

We run a SBS 2003 Standard box at the office for AD, Exchange, etc. Not exactly my preferred server OS, but inherited systems are like that.

Lately, some users have been recieving duplicate incoming emails. Everything in the AD configuration seemed correct, so after some Googling I decided to do an offline defragmentation of the private mailbox store using eseutil.

Eseutil works by copy all of the store data into a new DB file set, thus reducing (eliminating?) fragmentation. The store has to be dismounted first by right-clicking it in Exchange System Manager and selecting 'dismount'.

Then we can do the defrag from the cli. Eseutil is located in the \Program Files\Exchsrvr\bin directory (it was for me anyway).

eseutil /d "d:\Program Files\Exchsrvr\MDBDATA\priv1.edb" /p /t f:\exchange\priv1.edb /f f:\exchange\priv1.stm

/d = Perform a defrag, followed by the path and name of the exchange DB (edb). The associated streaming (stm) file is included by default.
/p = Don't overwrite the existing file at completion. By default eseutil uses a temp output file then overwrites the actual DB with it when it's done.
/t & /f = Location for the output edb and stm files.

I decided to use an alternate physical location for the output, to reduce the amount of time taken. The server is a ML350G3 with 3x 146GB in RAID5. Disk performance is pretty average, so a different output location made sense. We have a nice quick gigabit network, so I just mapped a drive (F:) to my desktop for the output files.

The defrag took about 1 hour to complete. Once done I moved the old DB files out from the MDBDATA directory, copied the new output files from my desktop to the server and re-mounted the store in System Manager.

There was a pleasant benefit of the DB files dropping in size:
  • priv1.edb: 12GB => 10GB
  • priv1.stm: 13GB => 7GB

The server doesn't have a lot of free disk space, so picking up 8GB for free is always a bonus.

I probably won't know for a couple of days yet whether the defrag has fixed the duplicate emails. TBA.