Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Scenario:

  1. Exchange 2010 VM, running on VMWare
  2. 120gb of data
  3. Run window of Saturday 12am-8am (can be extended a little bit, if needed)

Two action packed questions:

  1. I want to unmount my datastores, take a snapshot of my Exchange VM, run a drive level defragmentation of C and D (database) drives, remount the datastores & remove the snapshot (if everything is ok).

  2. My other option is: take a snapshot of my Exchange VM, unmount data stores, run ESEUTIL offline & defrag C drive (not D drive?), remount the datastores & remove the snapshot (if everything is ok).

What are your thoughts? Am I taking the correct approach to defragging / error checking my exchange server?

share|improve this question
    
First of all... Why? Exchange 2010 runs a background maintenance job (including online defrag), on all mounted databases, once every 24 hours (look for event id 1221 in the application event log). Second, what kind of disks are you using? –  Mathias R. Jessen Aug 25 '12 at 18:11
    
It says that the volumes are really fragmented.. Vmdk over iscsi NAS - SATA (not SSD) –  InfoTech Aug 25 '12 at 20:21
    
@infotech an exact error message, source and event id would be helpful. –  Tim Brigham Aug 25 '12 at 21:47
    
Ditto Mr.Jessen. –  Simon Catlin Aug 25 '12 at 22:36
    
Is the VMDK fragmented, or the files on it? Or both? If you've got a Thin provisioned, fragmented VMDK, an OS defrag won't help much. –  HopelessN00b Aug 26 '12 at 2:56

1 Answer 1

Before I went to all that work to defrag the drive + DB's just to satisfy a generic warning message, I would do a few things:

  1. What would you expect to get out of it? Exchange Server fragmentation is largely irrelevant to your users if they are all using Outlook cached mode. If Exchange is given enough RAM, it's storing chunks of each mailbox in RAM so your disks become less important. Modern Exchange is actually designed to run on slower disks then old Exchange (2000/2003).

  2. Defragmenting inside a VM is not what you think it is. You've got multiple levels of abstraction between your physical disks and the exchange DB's. You've got a RAID set serving up a LUN off of a shared set of iSCSI disks, how do you know if that LUN is contiguous on the actual disks? I doubt it is, especially if it's thin provisioned. Then you've got a .vmdk file you created in VMWare, which is likely fragmented itself. Did you thin provision it, or ever change the .vmdk size after initial creation? If you went through all these different levels starting with iSCSI, then to vmdk, then to guest OS, then to Exchange... what would it result in? Maybe faster OWA, if that...

Bottom line is I've never seen production systems that are virtual get defragmented and actually result in an improvement in the user experience. I'm not saying it's impossible to do... I'm just saying it's unlikely.

Tips on VMWare VM's and defragging: http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html

One interesting quote from that link:

"I should point out that I have read that, internally at VMware, we have not observed any noticeable improvement in performance after a defragmentation of Guest OSes residing on SAN or NAS based datastores."

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.