VMware Cloud Foundation (VCF) 4.1 – What’s new?

To coincide with a new release of vSphere 7.0U1 and vSAN 7.0U1, there is also a new release of VMware Cloud Foundation releasing. This is VCF version 4.1. In this release, as well as a bunch of updates to the versions of the various VMware products that make up the VCF bill of materials, there are also some nice new enhancements. In this post, I’ll highlight the big features that I know a number of customers are interested in.

Support for vVols as a Principal Storage for Workload Domains

Virtual Volumes (vVols) is gaining more and more traction among VMware customers, not just for virtual machine workloads, but also for container workloads. Customers continue to request the ability to place different workloads on different storage tiers for various reasons. This has always been a challenge, because is means that the different storage features need to be well understood by the VI-Admin so that they are able to select the correct storage for the application. This operation has been greatly alleviated through Storage Policy Based Management (SBPM) which allows storage policies to be created to represent the capabilities of the storage. vVols is tightly integrated with SPBM so that array based features (snapshot schedules, replication, QoS) can be leveraged for workloads, in a similar way to how we leverage SPBM policies for vSAN workloads.

By introducing vVols as a principal storage in VCF for VI Workload Domains, we will automatically take care of the necessary VASA Provider registration and creation of vVols datastore when it is chosen as the Principal Storage for a VI Workload Domain. For a primer on vVols (including VASA, Storage Containers and Protocol Endpoints, feel free to check out this post).

Support for VCF Remote Clusters (VCF at the Edge)

We continue to see more and more workloads deployed at the Edge. We see this in fields such as Healthcare, Telco, Point of Sale Retail, Oil & Gas, Video Surveillance and so on. For this reason, we are introducing VCF Remote Clusters, which will allow vSphere Administrators to carry out tasks such as the creation and lifecycle management of a Workload Domain at the Edge.  If your workload domain contains multiple clusters, this features also enables one or more of the clusters in the workload domain to be deployed at the Edge. Through VCF, we manage and monitor the remote cluster, including providing the ability to add or remove nodes.

In VCF 4.1, support for Remote Clusters will be a 3-4 node vSAN Ready Node configuration. We are looking at other configuration options going forward. The requirements on a remote cluster is that there must be less than 50ms of end-to-end latency between the VCF Management Domain and the VCF remote cluster, and at least 10Mbps bandwidth.

One last point – even though this feature is being announced in VCF 4.1, remote clusters can be supported on VCF v3.9 and later.

Improved vRealize Suite Lifecycle Manager Interoperability

In previous editions of VCF, there was the potential for issues to arise if vRSLCM, vRealize Suite Lifecycle Manager,  was used to provision vRealize products rather than VCF’s SDDC Manager. If SDDC Manager was unaware of a vRealize product deployment or upgrade, it was very difficult to return to the SDDC Manager to do future lifecycle management of these products. In VCF 4.1, we have introduced a bidirectional vRSLCM and SDDC Manager relationship. This will provide a much better cross product experience. Users can log into vRSCLM to perform operations, and SDDC Manager can now discover if vRSLCM was used to deploy vRealize products such as vRealize Automation, vRealize Operations and vRealize Log Insight while also being able to carry out  lifecycle manager operations on the vRealize product set (patching, upgrades, etc.). A nice improvement and one I know many customers have requested.

A new VCF User Role – Viewer

Historically, VCF has had only 2 roles, that of Administrator and Operator. In VCF 4.1, a new role is being introduced – that of Viewer. This is a very restrictive role as the name suggests – it does not have the ability to make changes to the environment but has the ability to view the status of the system. This is another feature that I know many of our VCF customers were keen to have included in the product.

Summary

This post has taken a look at the major features in the new release of VCF 4.1. There are of course additional features which I have not included in this post. Please review the official VCF 4.1 release documentation for the complete list on enhancements in this release.

6 Replies to “VMware Cloud Foundation (VCF) 4.1 – What’s new?”

  1. Thanks Cormac for making a nice series on VCF 3.x to 4.x. Have a small doubt and wanted to confirm my understanding. In VCF 4.0 with NSX-T, does it deploy two separate sets of NSX-T cluster, one for Mgmt. domain and other for Workload domain?

    1. Yes – unless you take the consolidated approach which allows you to run a Workload on the Management Domain. In that case, there is one one NSX-T Manager instance deployed.

  2. Hey Cormac, do you know if vvol is supported when taking the consolidated approach? If not for the first Cluster running the management-components at least for additional Clusters?

    1. Hi Ian, when I think of consolidated, I think of the management cluster and workload cluster being the same 4 nodes. Since the management cluster is using vSAN, I guess we expect that the workload cluster would also use it.

      I can honestly say that for consolidated, I have never tried vSAN + vVols attached on the same set of hosts, so I don’t know if it would work or if it is supported.

      I’m also not sure why you would add more clusters to a consolidated environment – why would you do this approach rather than run a separate workload domain with vVols as the primary storage? Curious to know what the use-case is.

      1. Hey Cormac, we are providing the customer a consolidated cwd to start with. Once the customer wants to extend, we do not deploy a new WLD. We allow the customer to scale by adding hosts to this first cluster or to add additional ESXi-Cluster, where the first (Management-Cluster) still contains Management and Workload-VMs and additional Cluster contain only Workload-VM. Deploying a separate vCenter-WLD would result in customer having his first VMs on the consolidated WLD and later VMs in a separate WLD, which makes management for customer more complex.

Comments are closed.