I'm looking for feedback from anyone who is using a NETapp filer, with Snap Manager for Exchange. We plan to install one and the consultant has told us that our current virtual server running exchange 2003 can stay virtual, but the drives containing the log files and the exchange information store need to be move outside of vmware, i.e. can't be stored inside an vdmk file.

My understanding is the log and information store will need to be stored on separate LUNs in the filer and the virtual machine will mount these LUNs.

My question: I've looked through all of Netapp's best practices and I haven't found a similar setup. I believe the consultant, but I would be interested in additional confirmation that this is the prefered setup, or a best practices guide.



I found this information in the vmware forums:

The simple answer is "yes" you can run Exchange using vmdks stored on NFS storage and usually in small to medium size environments this is the way to go. If you have 2-4 thousand heavy Exchange users on a mailbox server you might want to reconsider.

The more complicated answer is this should be considered carefully in the context of several things.

1.Are there any SAN or backup application that need native access to the LUNs (RDM or iSCSI). Things like Snap Manager for Exchange need to use an iSCSI or FC LUN presented directly to the Exchange VM. If this is the case, you would still run your operating system on a VMDK stored on NFS and then present an iSCSI or FC LUN to the guest for things like Database or Translogs.

2.You should profile your application using perfmon and determine the average (but include spikes) for throughput and I/Os per second and compare this to the throughput that you can get using NFS which will depend on how you set up your networking.

  • This information is correct. We run SnapManager for Exchange on an Exchange 2007 server virtualized with VMware vSphere 4. Our only requirement was to use iSCSI LUNs for the data and log drives because SnapDrive required this. I believe newer versions of SnapDrive than we have installed can also use FC inside the VM but I haven't tried or verified that. Don't confuse this with attaching storage to VMware via FC. We have FC attached Storage but had to use iSCSI because the VM sees our storage as VMDK and it needed "raw" access to the drives, not VMDKs Aug 28 '09 at 21:01
  • Thanks Kevin! We'll be using NFS to attach our vmware datastore to the FAS2050, and as you mentioned it sounds like we'll map an iSCSI LUN inside the virtual exchange server for the information store and logs. I've been reading everything I can get my hands on, but I haven't come across 'Don't confuse this with attaching storage to VMware via FC'. Can you explain or point me in the right direction on what this means. Thanks again
    – Aaron
    Aug 29 '09 at 12:40

Some other good answers here. I will just answer from personal experience, that for a small exchange / AD deployment SME is a waste of time and money. It's great if you have a large exchange dataset, but for the few 10's of gigabytes I was managing it was just added complexity. It's quite complicated, and requires a whole pile of very specific software revisions to work.

Exchange in a VM will DEFINITELY work, and if you forego SME you can use the native exchange multi-master replication to boot. NetApp obviously would like you to purchase SME, and will most likely not want to take responsibility for data corruption if you don't use it, but simplicity of VM setup, management, and snapshots will probably make up for it.

It just depends on the size of your deployment... if you're under 50-100 users I don't think I'd consider SME.


I work with Netapp but I am not directly familiar with Snapmanager for Exchange so hopefully somebody with direct experience w/ SME and virtualized Exchange can offer better insight. Likewise, apologies if this is just a total rehash of what you've investigated so far. I did a quick look for some documentation that specifically deals with this and I didn't find anything explicit. There are references to physical and virtual resources in the Snapmanager for Exchange admin guide but I believe those are related to Exchange cluster resources and not virtual disks or virtual machines.

Thinking it through, it makes sense that SME requires LUNs rather than vmdks if you take into account what it would be snapshotting. Leveraging an array snapshot against a vmdk is kind of tricky since the disk in question is actually a file sitting in a datastore which is in turn sitting in some pool of array-based storage. To get a proper snap of the filesystem inside the vmdk file, VMware snapshotting would be required. To make this VMware snapshot useful at the array level, there'd need to be some coordination between VMware and the storage array so that a 2nd snapshot (a storage-based snap) actually captures the vmdk filesystem in a state worth snapshotting (buffers flushes, ops quiesced, etc. by the first VMware snapshot). Additionally, since Netapp snapshots are volume-based, to get a snapshot of a vmdk, the entire volume housing the VMware datastore that the vmdk is in would need to be array-snapshotted and you can't easily "drill down" and just snap that part of the volume where the vmdk lives or pluck it out after the whole-hog array snapshot has been taken.

Snapmanager for Virtual Infrastructure does some coordination between VMware snapshots and Netapp array snapshots to streamline all of this but I don't know that Snapmanager for Exchange has that awareness.

SME Admin guide: http://now.netapp.com/NOW/knowledge/docs/SnapManager/relsme50/pdfs/admin.pdf (NOW login required)

  • +1 appreciate the answer
    – Aaron
    Aug 28 '09 at 20:16

I work in an environment in which we use SME with Exchange 2010. I realize this is different from your environment however I thought this might be worth sharing. Unlike your environment, our Exchange servers are physical though the log and information store on on separate physical luns being served out by NetApp via iSCSI which is in line with what the consultant told you.

I cant speak to anything visualization related, however my experience says that is is a good idea to have separate physical luns for the log and information store, especially if you plan to take snaps. We have a medium sized exchange environment however the number of changes written by Exchange 2010 to the log volume in particular is staggering. The amount of storage necessary to keep the snaps around for 2 weeks is amazing. Keep in mind that snaps capture all changes to the volume (the volume contains the lun). This is especially noticeable if you are performing mailbox moves or maintenance within Exchange.

Also worth noting, Exchange is constantly writing to the Netapp so it is good to have the log and information store in separate aggregates (separate disks) for performance reasons.

Anyway, this might be a little outside of the scope of your question but it might be good food for thought if you decide to go the Netapp route.


I work for NetApp Support and do support the SnapManager products and can confirm that any current release of SnapManager for Exchange (SME) does not support VMDK disks of any kind. SnapManager for SQL (SMSQL) does support it but not SME at this time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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