VMware vShield Zones – Reviewers Guide – If you haven’t figured this out yet, pay close attention to the Reviewers Guides.  If you have even slightly thought of trying out a product or technology, the reviewers guide is the next best thing to having an engineer over your shoulder walking you thru the product.  This is a really good one on Zones.  I learned quite a few things about the product that I was unaware of.  It’s a great read if you need to lock down and firewall off your VMs (or if you just want to learn how the VMs talk to each other).

Performance Brief for IBM WebSphere Application Server 7.0 with VMware ESX 4 on HP ProLiant DL380 G6 Servers – This is a very specific paper on running Websphere on HP servers.  I did find some interesting bits in it however.  Specifically, configuration tips to maximize performance running Websphere in a VM.  The performance metrics should also be evaluated if you want to run Websphere on any hardware platform (perhaps even IBM).

Best Practices for Running vSphere on NFS Storage – I’m currently in a documentation war with my EMC Channel SE who swears by running VMware on NFS (You still have to convince me Steve, I’m a block-IO bigot).  This is a must-have for all Admins running VMware on NFS.  It’s also a really good guideline if you want to compare performance between file-level or block-level IO in your VMware environment and make sure your making an accurate decision.  My favorite section of this paper: “Previously thought to be Best Practices.”  Every best practice white paper should have that to debunk outdated information.  Outstanding work VMware!

PVSCSI Storage Performance -This is a paper I was waiting to see.  It compares the performance of the PVSCSI adapter to the LSI Logic adapter.  I guessed pretty close on the outcomes.  The PVSCSI adapter does perform better under higher IO workloads (some have stated only use it >2000 IOPs.)  The only thing I didn’t like about the test was that RDMs were used.  VMware has argued for the last few years that high-performance should not be a requirement for using RDMs.  So why not use what the majority of customers use in their environments?

RIM BlackBerry Enterprise Server on VMware Virtual Infrastructure Deployment Guide – I really liked and hated this paper.  I liked it because it has some really good best practices and deployment tips depending on the size of the environment.  I hated it because it definitely contains errors: Table 2 shows a BES server with 23% utilization on ESX 3.5, Table 3 shows a BES server with 27% utilization under ESX 4, Figure 12 says the CPU load went down from 27 to 23 going to vSphere – not according to your tables kids.

That will do it for this month’s White Paper Review.  We’ll see you next month and look for more great technical information.

Performance is definitely the harder of the two to determine.  Not every storage frame is created equal.  I’ve held Engineering positions at EMC and NetApp.  I can tell you that there’s a lot of marketing you are going to have to weed through to find out what you need from a performance standpoint.  In addition, no two customer’s environments require the same storage performance.  What I often suggest is to track the disk I/O on your physical machines.  You can use the standard OS Performance counters to do this.  Take a note on the physical hosts and gather the average MB/second of storage reads and writes and the average numbers of transactions per second.  You will also want the peak of these counters as well.  You can provide an aggregate of these to your storage vendor’s engineer to confirm their frame can deliver your minimum performance requirements.  Clearly you would want to pad these numbers to anticipate future growth.  If you do not have the expertise (or time) in-house, check with your storage vendor or Partner to see if they offer any virtualization/storage assessments.  Some offer free for basic results and some have paid assessments which can get extremely detailed and leave "no stone unturned".  To answer the performance question, the more detail you have on your own performance requirements, the better off you will be.  VMware has a very high-level protocol performance whitepaper which describes how the protocols perform from ESX server.  Remember that there are different price points for the protocols with Fiber Channel typically being the most expensive.  Price is always another factor to consider but every customer weighs price differently in the list of priorities.  Look for a balance of performance, price and functionality.  Know the priority of each factor for your company and review it often during the evaluation process, it may change.

The second factor in the protocol decision is functionality.  While I know that performance can be a difficult factor to clarify, functionality is pretty cut and dry. These are listed by protocols with the most functionality to the least.

Fiber Channel

Fiber Channel (FC) has most complete set of functionality.  If you go with a FC solution, there are no suprises with functionality limitations.  All of product functionality is supported (vMotion, HA, DRS, Lifecycle Manager, Lab Manager, Boot from SAN, etc.).  The other protocols run into a few limitations however.

iSCSI

From a VMware perspective booting the ESX hypervisor from SAN is only supported on iSCSI if you use hardware-based iSCSI initators.  The included software-based initatior does not support ESX boot-from-SAN.  Please remember, I’m referring to booting the ESX hypervisor itself from iSCSI is not supported with the software initiator, booting the VM’s from iSCSI is fully supported. Second, Microsoft Cluster Services is not supported on iSCSI, only Fiber Channel.  If you wanted to run MSCS nodes inside virtual machines, iSCSI will not work for you.

NFS

You cannot boot ESX from NFS.  That seems obvious but I’ll list it for the newcomers.  Second, you cannot do Raw Device Mappings on NFS.  Raw Device Mappings are presenting a LUN directly to a VM’s operating system.  No LUNs here on NFS.  Third, Storage vMotion is not supported going to or from NFS.  Storage vMotion is migrating where the VMs are stored while they are running.  If you want to migrate any VM’s to or from NFS today, you have to shut down the VMs and do a cold migration to move them.  Fourth, Site Recovery Manager currently does not support NFS.  If you want to use SRM to manage your DR plan today, NFS will not get you there.

One additional point I want to make is two pieces of functionality that NFS does support that all the other protocols do not.  They are thin provisioning and dynamic expandability.  NFS will allow you to thin provision VM’s and it’s actually the default behavior.  Thin provisioning is creating a virtual disk for a virtual machine and the only space taken on physical disk is the amount of data stored in that virtual disk.  For example, if I create a VM with a virtual disk that is 10GB.  I then load an OS in that VM that takes up 5GB of that virtual disk.  On local storage, iSCSI, and Fiber Channel this scenario will use 10GB of physical storage (the full size of the virtual disk, even if I’ve stored anything in it or not).  In the same scenario, NFS only takes up 5GB and it’s virtual disk file would grow dynamically as I put more in the VM.  VMware has announced that thin provisioning is coming to VMFS datastores in 2009 , NFS does it today.  Additionally, some storage frames do this behind the scenes at a storage frame level.  Check with your vendor’s capabilities.

The last benefit that NFS has over the others is dynamic expandibility.  ESX uses datastores to store it’s VMs.  Datastores can be comprised of one or more LUNs, or in the case of NFS, a mountpoint.  With an NFS datastore, the filesystem is maintained by the storage frame.  You can dynamically expand the NFS datastore by increasing it’s size on the storage frame and the ESX servers will recognize the increased storage with no additional effort.  With the VMFS datastores, you have to add extents to increase the datastore’s size.  In the case of VMFS, there’s a bit of administrative work to make this happen.

Local Storage

My least favorite and only recommended to customers just getting into virtualization who cannot afford a SAN or for small Remote Offices with no shared storage available.  Local does allow you to boot ESX from it (obviously).  However vMotion, DRS and HA are not permitted.  You cannot use it for a MSCS cluster.  It is not supported with SRM or Storage vMotion.

Here’s a quick summary chart of the functionality differences:

In summary, know what you require for performance and make sure your storage vendor can meet your demands.  Then make sure the protocol has the functionality that you need at a price you are willing to accept.  You’ll be off and running in no time, with a infrastructure that has the elasticity and versatility to respond to whatever your business can ask of it.