In vSphere 7 U1, for core storage, the big announcement along with VCF 4.1 is the support for vVols as principal storage!
You may ask, “Why is this such a big deal”? With Cloud Foundation, your management domain requires vSAN, which can easily be managed using policy-based management or SPBM. SPBM allows simplified operational management of your storage capabilities. Although you can use tag-based policies with external storage for Cloud Foundation, it is not something that scales easily and requires quite a bit of manual operations. When you think about the possible scale Cloud Foundation enables, manually tagging datastores can become daunting. Subsequently, being able to programmatically manage all your VCF storage simplifies your operations, freeing valuable time for other tasks.
In Cloud Foundation 4.0 we supported vSAN, NFS, and VMFS on FC for Principal Storage for newly created Workload Domain clusters. Cloud Foundation 4.1 expands Principal Storage options by adding support for vVols. vVols was previously supported for Supplemental Storage only. The big difference between the two is Principal Storage is the initial storage option selected when creating new clusters in Cloud Foundation, the setup of principal storage is automated through Cloud Foundation workflows. Supplemental storage is added to a cluster manually through the vSphere Web UI after it has been created. With vVols, numerous benefits may now be utilized in Cloud Foundation and, you can use the same SPBM management plane for your vSAN and external arrays. vVols enables you to use all of your array’s capabilities such as array-based snapshots, cloning, and replication. All managed via policies, on a single vVols datastore, with VM granularity.
The Cloud Foundation engineering team has been diligently working internally and with our storage partners to enable vVols as principal storage. With the 4.1 release, we support NFS 3.x, FC, and limited iSCSI protocols for vVols. For iSCSI, there are a few pre-tasks that must be completed. Setting up your SW iSCSI initiator on all your hosts in the new WLD, and your VASA must be listed as a Dynamic Target.
The VASA registration has been enabled outside the workflow in the event incorrect VASA details are entered. This way, the workflow doesn’t fail, allowing you to update incorrect information for the VASA registration.
Once you get to the storage for the new WLD, you can enter the details for the vVols datastore.
After going through the rest of the details for the new WLD, you will see we now have vVols storage.
With the WLD build completed, you can then go into your hosts, and you will see a vVols datastore connected to the hosts.
As a default, an SPBM policy, “vVols No Requirement Policy,” is created. We do not create any other SPBM policies because there are too many variables between array types and customer requirements. There is no way to generate an advanced policy, tailored to the requirements needed, without input from the customer. This allows the customer to create specific and tailored SPBM policies that meet application, organization, or security requirements.
vVols continues to be developed for many of VMware’s products and our partners are also continue to enable more and more features for vVols. To learn more about vVols or VCF, head over to the vVols or VCF pages at core.vmware.com.
To learn more about VCF and vVols, make sure to attend Todd Simmons and my VMworld session.
VCF and vVols: Empower Your External Storage [HCI2270]
Be sure to check out the VCF announcement blog.
What’s New with VMware Cloud Foundation 4.1
More VMworld sessions
vSphere 7 U1 storage related blogs
