What data storage virtualization looks like today
A comprehensive collection of articles, videos and more, hand-picked by our editors
SearchVirtualStorage spoke with one of the architects of VMware Virtual Volumes (VVOLs), PernixData co-founder...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and CTO Satyam Vaghani. In this section of the interview, Vaghani takes a deep dive into features and limitations of VVOLs, and how they affect virtual machine management.
Vaghani, who served as VMware's principal engineer and storage CTO before leaving to start PernixData, described what VVOLs can and cannot do. He also discussed what storage administrators should know before implementing their array vendors' VVOLs.
How do VVOLs differ from other virtual machine management features in vSphere?
Vaghani: VVOLs are mostly focused on the storage side of virtual machines, or virtual management. Unfortunately, most of the advancement of virtual machine management until now has been on non-storage components. We were keeping storage systems at an arm's length, so storage systems are a ridiculously complicated piece. They actually provide very, very interesting data services, interesting snapshotting services, cloning, replication, provisioning services, but VMs could never use that. And so I think VVOLs completes the picture. There were a lot of advancements made on the CPU memory side, a lot of advancements made on the network side, and now VVOLs completes the picture of storage services that are available to VMs and are truly 21st century.
Who is the target audience for VVOLs? Is it the storage administrators or the server administrators?
Vaghani: That's a great question. Roughly speaking, everything that VMware or the ecosystem partners have done in virtualization has all been targeted toward the server administrators. But VVOLs is actually targeted not just to the server administrator, but also to the storage administrator. This is a common substrate, a common language that they could finally both use.
So the server administrators can do what they want to do, which is administer VMs, but now these VMs use VVOLs. And so now the storage administrator for the first time can talk the language of the server administrator. When the server administrator now says, "Look, this VVOL needs troubleshooting," then the storage administrator knows exactly what the server admin is talking about.
Before this, the server admin always wanted to talk about VMs and quality of service on VMs, but the storage admin always wanted to talk about LUNs and the quality of service on LUNs. And both camps would be equally angry at each other, because they were getting this feeling that the other camp is not getting them. The storage admin is constantly frustrated. "I'm giving you great LUNS to use, why are you complaining that the storage is slow? I'm doing the right thing." And the VM admin says, "Well I'm complaining that this VM is slow, and you can't fix it."
Now they can actually divvy up the work of virtualization. Typically the work of virtualization all belonged to the server admin and the storage admin was looked at as old age, and they were looked at as people who were trying to prevent virtualization. But that wasn't the case. They were upset because they just couldn't understand what virtualization needed and how they could actually help. For the first time now they can. They can actually understand because they have the tools and the concepts to actually participate.
Learn more about VVOL technology and virtual machine management in part one of SearchVirtualStorage's interview with Vaghani.
So what types of questions should a customer ask of their array vendors about VVOLs?
Vaghani: A few things come to mind. One is we have developed an incredible level of expertise when it comes to designing storage systems. You can give me an IOPS spec or a latency spec, and I can tell you how many spindles you should put in. I can tell you which array, which vendor you should buy, how much flash it should have, how many ports it should have, et cetera.
And unfortunately, all that knowledge will have to be re-thought, because this is a very different world. Now you are talking about VVOLs, which is a very different way of presenting storage. This is not going to be as simple as, "Yay, great technology. Let me use it and great things will happen." People need to architect for VVOLs, and not enough people have architected for VVOLs because the technology is just now beginning to come out. And so people better ask for empirical evidence, saying, "For a given use case, show me VVOL-based architecture that you, Mr. Vendor, have deployed at some other place and that has worked."
One should not just look at VVOLs as a technology to say that, "Look, it will give you more IOPS or better latency." You should really ask the operational questions. Is it compatible with everything else that I run in my data center? And wherever it's not, what is the road map? Ask whether the array vendor is going to fix it, or whether I should be investing in new solutions.
So you better have that plan already laid out before you ever create the first virtual machine that uses VVOLs. And that is going to be a non-trivial task, if you ask me. ... That is something that users should ask their vendors and their consultants. They should ask for that very, very clear plan before they operationalize.
Storage array vendors have been developing VVOLs for several years. So why aren't they commonplace in arrays right now?
Vaghani: I think partly it is because of the difference in requirements. So like I was saying, now we are going to move from something that requires a thousand LUNs per data center or per storage system, to hundreds of thousands of VVOLs per storage system. And that requires quite a lot of changes, especially in legacy storage architectures. And unfortunately, many vendors have legacy storage architectures to deal with, so that took a while.
And then even the VMware work wasn't easy. It was a matter of going from a storage stack that VMware created for 10 years that essentially provided software-based services on top of data stores to an object-based storage stack, which is what VMware now uses for both VSAN and VVOLs. Now every virtual machine deals with these objects, which are virtual disks.
And then of course, VMware is a very mature hypervisor. What do [VVOLs] do for my data protection APIs? Making VMware APIs for data protection work with VVOLs is yet another task.
We had to make many value-added VMware services work with VVOLs, and you will notice that some of these services don't work in the first version of VVOLs. So, Storage DRS [Distributed Resource Scheduler] support doesn't exist and SRM [Site Recovery Manager] support doesn't exist. Linked clone support that is used for VMware Horizon View doesn't exist.
VMware VVOLs and VM storage management explained
What to expect from storage offerings with VVOLs in place
VMware VVOL implementation basics