The announcement of Project Pacific last year at VMworld came to the surprise of engineers around the world. Project Pacific, in a nutshell, is the deployment of Kubernetes within vSphere and the solution to deploy Kubernetes clusters on vSphere hypervisor. From the customer perspective, there were so many unanswered questions. I was allowed to take part in an early access on both beta and a blogger access webinar on vSphere 7 and other releases. We tried to ask as many questions as we could, but so many more remained. With the new cloud solutions all around us, the different cloud spaces, and modern K8 clusters, and from the infrastructure that is built, to the applications running on that infrastructure, the direction of business has changed. Obviously, in our ever changing and fast-pace business space this makes sense, as ‘the application’ is what makes the money. For a long time, vSphere has been focusing on the operations and enterprise architect engineers, which has allowed us to use our beloved solution to bring applications and VMs to manage resources. With the release of vSphere 7, our beloved hypervisor is getting not into the OS kernel deployment solution, but into pure application management, operation, and deployment. For today, lets just look at the vSphere 7 updates and look at how they bolster vSphere for both the engineer, and operator.
vCenter Server Profiles
vCenter Server Profiles is a desired state file that holds the configuration for your hosts. This includes authentication, management network, etc. that can be exported and then imported to servers and then set universally. This can also be done to multiple vCenters, allowing the same settings across DR zones or different co-locations. A surprise of this solution is that it’s API based, so, you are pulling the configuration of the host and then importing it through the API. Now, some may rejoice at this solution, but others, may hold back their rejoicing as APIs can be difficult to navigate, but fear not! The big V has added an API explorer to help you navigate around and configure your GET, SET, POST, PUT etc. The Server Profile will allow you to set your network solution, but be advised that NIC1 will always be utilized as vCenter HA.
For vCenter, they also ‘beefed up’ the allowed resources you can connect to your solution, allowing your environment to grow even larger. Here is a quick snip of the increases.
As a vRealize guy, templates have been critical to my whole life. Being able to deploy golden versions of templates is a huge part of the solution. Content library, to me, has always been a frustrating solution, because it has never really been useful to me. However, Content Library has some amazing new features including versioning. The Content Library will allow a check-in and check-out solutions to pull those templates out and update, or adjust them. After adjustment, if it fails and you have crashed your template, you can revert it! If you are like me, and know the pain of having to create a new template every time a patch screws up sysprep, or, if you have ever had to make an adjustment and needed to revert and the snap isn’t there, this safety net is a really nice feature.
With the new release of vSphere 7, updating is getting easier and more automatic. While we all love VMware Update Manager, and the solutions that it brings, I’m sure we can all agree it would be better if it removed the process of creating baselines, but still gave us the ability to manage what patches are deployed. These are the issues they seem to be working on, and we’re getting a better patching solution, for both vCenter and ESXI.
The vCenter Upgrade Manager will address the patches that are available for upgrading vCenter as well as the environment. This includes the solutions that are installed including the vRealize Suite, and the compatible versions for those solutions. This allows engineers to see the gotchas that they may experience after the upgrade, before clicking the button. The manager also allows modifying the solutions that are deployed, which lets engineers add solutions if they are not automatically seen, and setting the versions so they can be run against the vCenter upgrade delta.
For ESXI, VUM is no longer, and has been replaced with Lifecycle Manager. We all love the solution of VMware Upgrade Manager allowing us to add devices and drivers, but the goal of Lifecycle Manager is to bring that solution automatically, This allows those users who use partner products, currently HPE and DELL, to be able to view ESXI patches, as well as drivers and firmware for the hardware. Once again, the goal here is “Desired State” keeping all hosts in the same settings across your environment. Lifecycle Manager allows the driver and firmware updates set in the recommended settings to verify that they are safe to run before installation. Once again, this solution is available via both API and a GUI allowing those API engineers the solution of pulling and pushing code to set the variables, and push the solution.
Workload Utilization – DRS
Previously, DRS had been focused on a cluster based metric, verifying the solution across each ESXI host. Now, DRS is focused around the workloads running on the cluster. This gives an increased polling rate at 5 minutes to check the solution and populate a DRS Score. This score will run on each host, and if a better score is on a different host, the solution will consider migration, and if it is better to keep the workload on the host that it is currently on, DRS will decided to keep it there. The DRS Score score brings in CPU-ready time, Memory swap, Cache behavior, etc., meaning this takes into account both compute and storage.
DRS also will take into account specific hardware accelerator solutions such as vGPU solution on the VMs that are running.
In the DRS improvements, VMware also took a look at VMotion and have made adjustments to help VMotion work on large or monster size VMs. For these large machines (like SAP HANA, or Oracle) VMotion will now lower the stun time and migration. They worked really hard to create or refactor a solution to help with these larger VMs and have found a process that works better. Along with this refactor comes better memory migration for VMotions, and the stun time reduction will help all VMotions, but the most noticeable change is on the bigger VMs. Additionally, with these configs, EVC now has new versions of CPU to set on your EVC settings.
For the ESXI hardware component, they include a watchdog timer to catch OS failures, and reboot upon failure, also, a Precision Time Protocol or PTP to help financial apps or features, which keeps that time setting down to milliseconds. This is only available in hardware components within 7.0 but great features to help those that 3 A.M. calls about machines that failed on patch update reboots, or time being outside the needed parameters for sales, financials, etc.
Now, let’s look at changes in Certificate management. If anyone has replaced certificates in the PSC, you know that replacing multiple certificates and having the number of certs is kinda crazy in vCenter.
This picture was very much a relief to me personally, as there were about 6 (8 total) more certificates in 6.7 and in 7.0 there are only 2.
vSphere Trust Authority is being introduced as a new feature for vSphere. It introduces attestation for key management if needed. It also makes it easy to implement the principle of least privileged, allowing users only the needed access instead of more. vSphere Trust Authority also requires a vCenter cluster of 3 hosts outside of the “Workload” vCenter to maintain this, and it can also encrypt Workload vCenter Server instances.
Identity federation in 7.0 will let single federation of ADFS allow authentication into your environment. This also has Multi-factor Authentication available, allowing a huge feature to be available to those wanting to bring in a more trusted and secure authentication process to log into your environment.
This is available only for vCenter, but eventually they will bring in other solutions into the federated solutions. This does bring federation into Kubernetes namespaces as they are built into vCenter.
vSphere 7.0 is not just an iterative upgrade for VMware. This is a full solution upgrade for engineers that brings in many solutions that we were looking at third parties to provide. Now, we have the ability to find these solutions directly in vSphere. Your homelab will run easier with these solutions, and your enterprise 20,000 VM solution will run better. I’ve been in the vSphere Beta for the past 2 months, and I’ve loved the solutions this has brought. I’ve only scratch the surface in my homelab (and in this blog), but there are hundreds more updates that are in vSphere that will make being a VI admins job easier. I hope this helps fill in the gaps in where vSphere is headed on March 10th. I look forward, as I’m sure you all do, to utilizing these functions and working with the new solutions.