I posted a rather lengthy entry about this topic on my blog recently http://joergsstorageblog.blogspot.com, but I thought that I would summarize it here as well.

Virtualization Changes Everything

I keep hearing this, and to some extent, it’s true, but on the other hand, if you have been around storage you also see a lot of similarities to the issues that we always had to deal with as storage admins/managers. The main difference with VMWare is that you might find that it’s even more important that you address the following three issues:

1. Application performance is dependent on storage performance. This isn’t news for most storage administrators. However, what’s different is that since VMWare can combine a number of different workloads all talking through the same HBA(s), the result is that the workload, as seen by the storage array, turns into a highly random usually small block I/O workload. These kinds of workloads are typically very sensitive to latency much more than they require a great deal of bandwidth. Therefore the storage design in a VMWare environment needs to be able to provide for this type of workload across multiple servers. Again, something that storage administrators have done in the past for Exchange servers, for example, but on a much larger scale.
2. End to end visibility from VM to physical disk is very difficult to obtain for storage admins with current SRM software tools. These tools were typically designed with the assumption that there was a one-to-one correspondence between a server and the application that ran on that server. Obviously this isn’t the case with VMWare, so reporting for things like chargeback becomes a challenge. This also effects troubleshooting and change management as well since the clear lines of demarcation between server administration and storage administration are now blurred by things like VMFS, VMotion, etc.
3. Storage utilization can be significantly decreased. This is due to a couple of factors, the first of which is that VMWare requires more storage overhead to hold all of the memory, etc. so that it can perform things like VMotion. The second reason that VMWare uses more storage is that VMWare admins tend to want very large LUNs assigned to them to hold their VMFS file systems and to have a pool of storage that they can use to rapidly deploy a new VM. This means that there is a large pool of unused storage sitting around on the VMWare servers waiting to be allocated to a new VM. Finally, there is a ton of redundancy in the VMs. Think about how many copies of Windows are sitting around in all those VMs. This isn’t new, but VMware sure shows it to be an issue.

So, the question is, what can we do about these things? Well, some new technology that’s just coming into the market will help. things like thin provisioning, block storage virtualization, new SRM tools that can do correllization between servers, networks, and storage will help. Another thing that we are storating to see are virtual HBAs which will help as well on the reporting end of things.

So, as I see it, server virtualization (VMWare) will drive storage virtualization. I would even go so far to say that you won’t be able to get the full promise of server virtualization unless you impliment some storage virtualization. If I’m right about that, then we should see a significant uptick in the sales of virtualization very soon…