VMware

During a recent customer VMware healthcheck, we noted a customer did perform the VMware NFS timeout tunings as recommended by NetApp TR-3749. However none of the guests had the correct guest level timeout tuning.

TR-3749 doesn’t explicitely spell out that you should make sure and update your guest level disk timeouts to match the NFS timeout tunings.

Also note that these disk timeout settings if done once in the guest, may be reset through a VMware Tools upgrade. (See http://communities.vmware.com/thread/212235) so watch out.

See NetApp article kb41511 “VMware ESX Guest OS I/O Timeout Settings for NetApp Storage Systems”  for more details.

We frequently get questions from customers with NetApp if they should store the swap with the VM or on a separate datastore, and how big should they make their swap datastore.

NetApp recommends in NetApp TR-3749 to use a separate datastore, as to avoid storing “transient” data like swap when using array based snapshots or disk-to-disk replication with SnapMirror and/or SnapVault. (Also See TR-3428).

For sizing, you can thin provision and use autogrow on the NetApp side to avoid having to worry about an “exact” space figure as this space is dynamic in nature depending on the number of VM’s, the memory in those VM’s, and memory reservations, and is used only when there is memory pressure.

If you want an absolute worse case add up all the VM’s you would create with the memory you anticipate allocating to them, and use that result if you need an absolute worse case number.