Server virtualization doesn’t kill storage. People kill storage. That’s all I’m saying.
I get hot under the collar when I hear people say things like “server virtualization increases storage requirements by huge amounts.” They slam server virtualization with this comment, as if changing a server from being a physical one to being a virtual one somehow magically increases its size. They list it as a reason that you shouldn’t use server virtualization.
So I got a little irked when I heard the CEO of Symantec, Enrique Salem, say something like it in his keynote this week at Symantec Vision. (It was a great show, by the way.) “Server virtualization increases storage use by 200% – 800%,” he said. When we had the media Q&A with him, this was the first question out of my mouth. “What about moving a server from being physical to being virtual increases storage requirements?” I asked a similar question of every other Symantec person I met with that day, as well as when I met VMware CTO, Steve Herrod.
In retrospect, I was probably a little hard on Mr. Salem during my Q&A. Even Steve Herrod from VMware verified that the typical VMware customer does see such a storage explosion. However, I still stand by my statement that this is not VMware’s fault. Moving to VMware does not cause your storage to magically explode. Moving to VMware probably does “help” it happen, though. Here are my thoughts on that.
VMware’s design actually reduces storage use
The average virtual machine image (VMDK in VMware speak) is significantly smaller than the smallest disk drive you can buy to put into a server. The smallest hard drive I can configure in a Dell server is 250 GB. You can create a thin-provisioned VMDK and it will consume only as much storage as it needs to, which is going to be far less than 250 GB. I don’t know Hyper-V as well as I do VMware, but I’m guessing it’s similar. I would also say that moving servers into VMware/Hyper-V means that you can put all those very duplicated images on a single storage volume that supports deduplication, removing that huge storage explosion. You can’t do that if you’re using physical servers with discrete hard drives.
Many people buy their first “real” storage array when they buy VMware/Hyper-V
They may feel that this “forces” them to increase their storage costs, because they’re used to just buying discrete hard drives — often with no RAID or monitoring. They then blame this increase in cost on VMware/Hyper-V. I don’t buy that either. First, they didn’t have to do that. They could have bought a nice HP/Dell/IBM server with internal storage and run VMware on that. The decision to buy a storage array is a second decision. Second, if VMware “forces” them into the 21st century as far as storage management is concerned, so be it. It’s about time they have real storage.
Server virtualization often means a lot of test/dev VMs
This was Mr. Salem’s point. VMware/Hyper-V makes it really easy to have many, many different images of different configurations, so people create dozens or hundreds of VMs in their test/dev environment, and that causes a huge increase in storage. I again say that you could continue to do in your dev/test lab whatever it was you did before you had VMware/Hyper-V, so it isn’t VMware/Hyper-V’s fault that you lab now uses 10 times more storage than it used to. But it sure does make it easy, though, doesn’t it? I would also say that this increase in storage is accompanied by a huge increase in usability of the lab.
VM sprawl is evil and real and it eats up storage
This was the universal comment from most everyone I talked to. When we step out of the test/dev world, it is a reality that when you are buying physical servers, there tends to be much more of an approval process. When all you have to do to create a new server is click the right button on your mouse, you tend to create new “servers” very quickly. Next thing you know, you have a whole lot more servers (and images of Windows/Linux) than you ever would have had if you had physical servers. VM sprawl is real, and it should be addressed with process and procedure.
VMware and Hyper-V are not the problem here. What we do with it is the problem. Yes, they make it much easier to do dumb things like VM sprawl, but blaming VMware and Hyper-V on your storage explosion is like blaming Ferrari for your tickets. Just saying.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.