On April 2, 2020, VMware released its general availability of vSphere 7, which embeds containers and Kubernetes into the platform, and it enables IT administrators to run existing enterprise applications in vSphere. These updates address several issues found within vSphere, such as those pertaining to lifecycle management, security, performance and resiliency.
Some specific vSphere 7 features that VMware enhanced include Lifecyle Manager, Identity Federation, vSAN, DRS, and content libraries and templates.
In addition, one of the major enhancements of vSphere 7 is the integration with Kubernetes, which enables admins to run containerized workloads on vSphere with Kubernetes. However, this feature is only available in the edition of vSphere that comes with VMware Cloud Foundation.
Updates to Lifecycle Manager
The updated Lifecycle Manager in VMware vSphere 7 simplifies updating ESXi hosts and keeping those hosts compliant.
Lifecycle Manager replaces Update Manager, but admins still have the option to use Update Manager in vSphere 7 if needed. The image below shows which ESXi image admins can use to keep hosts compliant in Lifecycle Manager.
The Image Depot tab provides the feature to add and use vendor add-ons and components such as drivers. This is similar to what admins might use when setting up images for the Auto Deploy feature, which places hosts in a cluster boot with Preboot Execution Environment from the same image and, therefore, will all have the same consistent setup.
Though the updated Lifecycle Manager installs the software locally, it still provides the same functionality: ensure all hosts are based on the same image. The difference with Update Manager is that admins can choose a baseline image that only verifies installed patches. The base image and other drivers could vary between hosts in a cluster.
The image below shows a cluster that is being configured with an image used for the entire cluster. Once admins enable this, they can no longer use Update Manager and baselines.
Content libraries and templates
Content libraries have never been very popular with admins because they can be too hard to manage and keep up to date. Content libraries are practical to keeping templates synchronized between vCenter Servers, but updating templates in a content library was never simple.
However, in vSphere 7, templates from a local library are now visible in the vCenter inventory and the system can use them directly from there. As a result, there is no need for admins to navigate to the content library first to deploy a new VM. But what's even more important is that admins can check out a template from the library to apply an update and once the update is complete, they can check the template back in.
For example, the image below shows a template named Linux-Web that was checked out to a VM named Linux-Web-v2. That VM can now be powered on, updated and then checked back into the content library. With the existing library synchronization, subscribed libraries will also receive the updated template.
Content library synchronization was not configurable in previous versions of vSphere, but vSphere 7 has an advanced configuration option that enables admins to change the synchronization settings.
Identity federation and authentication
Until now, vSphere admins have been using the Platform Services Controller to connect their environments to Active Directory (AD) or other Lightweight Directory Access Protocol directories. This is still possible in vSphere 7, but a new approach is to use Identity Federation. However, admins can only use Identity Federation with the Active Directory Federation Services (ADFS).
The image above shows where admins can navigate to Single Sign-On and configure Identity Provider to point to ADFS.
This setup uses OpenID OIDC and OAUTH2 as protocols to change the login process as described in the diagram to the left. For example, admins connect to the vCenter Server to log in to the vSphere Client. The login is then redirected to the Identity Provider that authenticates admins logging in.
Once authenticated, the system generates a token used to access the vSphere Client.
The benefit of this setup compared to previous Single Sign-On techniques is that admins can now consume any multifactor authentication methods configured for AD and ADFS.
Enhancements to vSAN
Several technical improvements have been made for storage support in vSphere 7, such as hot plug support for non-volatile memory express devices and for capacity disks up to 32 TB. In addition, VMware introduced a new feature in vSAN known as File Services.
With File Services, admins can now access the vSAN Datastore via Network File System, which enables admins who can work as NFS clients to consume storage from their vSAN cluster. For this to work, admins must deploy a VM on every host in their vSAN-enabled cluster. These VMs can then communicate with the VMkernel to gain access to the distributed file system.
Though, theoretically, any NFS client can connect to the network with the help of File Services, even an ESXi host, that's not what it's there for. Cloud-native applications that have a large number of containers connecting to a single volume can especially benefit from this feature of centrally storing files on a vSAN-enabled cluster.
Improvements to DRS
VMware's DRS service has seen new features in previous releases of vSphere, but the engine didn't really change in vSphere 7. In previous versions of vSphere, migration recommendations were made every five minutes based on the load of all ESXi hosts in a cluster.
In vSphere 7, the recommendations are now based on a VM DRS score that calculates by the minute. Metrics such as CPU ready time and swapping are taken into consideration to determine if a VM is experiencing resource contention and, if so, whether there are other hosts in the cluster containing more resources available to run the VM.
Another improvement VMware made to DRS is scalable shares. A problem that many admins didn't even know they had was that using shares on resource pools with an unbalanced number of VMs could lead to unexpected results. Many would, therefore, shy away from using resource pools at all. However, in some cases resource pools were useful.
For example, when a resource pool with low shares contains a single VM and a resource pool with high shares contains 10 VMs, then vSphere assigns those resources to the resource pools based on the shares' value. However, if 10 virtual machines are sharing resources from an 8,000-shares pool and a single VM uses resources from a 2,000-shares pool, then the VM using the 2,000-share pool is better off.
In vSphere 7, admins can now change this behavior on the cluster level, as shown in the image below.
However, if admins don't require this behavior for all resource pools in the cluster, then they can enable it on a per-resource pool level, as shown in the image below.
