Migrating to vVols
VMware Virtual Volumes (vVols) significantly simplifies and enables your array to do what it was intended, provide array-based services to the guests. Without going into great detail on how vVols function, the gist is vVols allow the VM to directly interact with dedicated volumes on the array. Similar to an RDM, but without the loss of functionality associated with RDMs.
In this blog, the key point I want to make is vVols does not have to be a replacement for your existing VMFS or NFS datastores. vVols can exist, in parallel, with both on the same array. In many cases, you will end up using some combination of both. Once I have conveyed this to customers, they typically are more willing to investigate vVols and try it in their existing environment. In fact, I highly encourage them and you to try vVols in your environment. If you have an array that supports vVols, and vSphere version 6.0 or above, you can add vVols to your virtual environment. This allows the VI admin and the storage admin to see how vVols work, see the actual objects on the array, see how simple setup and migration are. In the vSphere environment, a vVols Datastore looks and works just like a regular datastore. Subsequently, migration to and from a vVols Datastore is just as simple storage vMotion allowing migration without impact. Once you have set up a vVols Datastore, you can also see and use Storage Policy-Based Management (SPBM) policies for your array.
One of the benefits of vVols configuration is it uses the same connectivity you are currently using. No change is required. FC, NFS, iSCSI, and FCoE are all supported with vVols. The best part about vVols is you no longer have to create and manage LUNs or volumes! No more creating a datastore with specific storage capabilities for your VMs. This aspect of vVols greatly simplifies daily operations and reduces mundane tasks, allowing your storage admin to be more heads up and focus on projects instead of operations. With vVols, you control the storage capabilities via SPBM policy and apply policies at a VM level, not the datastore level. You allow the VI admin to create and use storage capabilities based on application, security, or organizational requirements.
VMware and our storage partners continue to focus on and develop vVols for external storage. Another aspect of vVols is how it’s complimentary with vSAN. They both allow you to use SPBM to manage your HCI and external storage. This enables ease of scale, which is an essential aspect if you are looking into Cloud Foundation or Kubernetes. Imagine managing hundreds or thousands of LUNs or volumes manually; it’s not a scalable process. Managing storage via a programmatic process like SPBM allows that daunting scale to be tackled easily, and effortlessly be administered.
To learn more about vVols architecture, head over to http://core.vmware.com/vVols.