Today VMware announced the public beta of the next version of vSphere, and veryone can apply for it and test out all the new upcoming features. Duncan Epping explained here how to register for the beta program.
One of the coolest and most awaited feature available in this beta is Virtual Volumes, also known as vVols. Virtual Volumes is a new technology that will make possible to map single vmdk virtual disks to storage array volumes; finally storage arrays and hypervisors will talk the same language, and many configurations will be done at the VM level more than the LUN level. It would be something like having a dedicated LUN per VMDK, but without all the burder and complexity of such a configuration. It will give everyone an increased granularity that will help in defining QoS policies at the VM level. Cormac Hogan explained how Virtual Volumes work in this blog post.
There is one problem tough. How can we test this new feature?
Even if vSphere Beta is freely available, in order to test Virtual Volumes we need a storage array that supports it. Obviously, no storage at the moment supports it, since it’s not an official product. There are however already several videos from different vendors showing the technology preview of their Virtual Volumes support (I’ve seen at least Netapp, EMC, Tintri, Nimble and Solidfire), but in order to test it we need first to have access to one of their storage arrays, and install on top of it a beta version of their code.
Not that easy. And here comes the reason for this blog title.
To all the storage vendor that have a “software defined storage” solution (a VSA or a installable software). Since your solution is software only, and in the background you are surely already working on supporting Virtual Volumes, what about publishing it? It doesn’t need to be officially supported, it can be time limited and also feature limited (no replication? limited in TB? whatever), it can also be “officially unstable”.
You will instantly become the hero of every virtualization guy in the world.