5 new workflows that will ease your life
Here we’re going to compare the recently introduced in vSphere 7.0 new way of updating/upgrading clusters‘ with the old one and see that this time the change is not an incremental one, but a giant leap.
Let’s start with a brief history. Until vSphere 6.0, the main vSphere client was the desktop client and the main tool to update/upgrade clusters was the vSphere Update Manager (VUM). VUM had a plugin for the vSphere Client (screenshot below). The main concept was the baseline, which you attached to a cluster/host, check compliance, and remediate against.
Then, in 6.0 we introduced VUM plugin in vSphere Web Client (based on Flash technology). Apart from changing the underlying technology, we kept the workflows the same, thus VUM in Flash-based client looked very similar to VUM in the desktop client.
Several years later, when the Flash technology started to decline, we rewrote the client in HTML and release partial workflows supported in vSphere 6.5, fully operational in vSphere 6.7 series. This time, instead of rewriting it 1:1, we took the opportunity to redesign and simplify some screens and add some new features. Still, the main concept stayed the same. So apart from changing the underlying technology, these 3 clients were very similar; the changes between them were incremental:
VUM in desktop, flash and HTML clients. Click image to open it full-size
In 7.0 we didn’t do just an incremental change but a giant leap – we fundamentally changed the underlying concept through introducing a simplified declarative way of managing clusters by a single image. Because of that, we have rebranded the update/upgrade functionality to vSphere Lifecycle Manager (vLCM).
Let’s take a look at 5 new workflows that will ease VMware administrator’s life.
1 – Updating software and firmware together
So far, VUM worked with Updates and ISOs, both of which contained collections of vSphere Installation Bundles (vibs). The workflow was: create baselines/baseline groups containing updates and/or ISOs, attach them to objects (like hosts or clusters), check for compliance and then remediate.
In 7.0 we introduced the concepts of Components (logical collection of vibs, representing a separate feature), grouped into Vendor Addons (e.g. software provided by VMware partners) and ESXi Versions (bootable images provided by VMware). These three concepts describe the software stack that will be installed on a host.
Now it is possible to upgrade the firmware together with the software (so far with VUM this was available only for VSAN clusters). This is done through setting the “Firmware and Drivers Addon”. An external depot should be configured to provide such addons, for example for Dell see Dell OpenManage Integration.
The combination of ESXi Version, Vendor Addon, Firmware and Drivers Addon and Components defines the desired state. With it:
- Firmware can be installed together with software;
- ESXi image, vendor addon and components can be set, versioned and distributed separately (in contrast with Bulletins);
- There is no need to maintain Baselines and Baseline groups anymore;
Desired state in edit mode (Cluster > Updates > Image > Edit)
2 – Export and import desired state
Exporting and then importing baselines was missing so far. Now we added export of cluster’s desired state in a JSON file, which can easily be edited manually.
Note that all the components from the JSON file must be present in the depot of the vCenter Server it is being imported into, otherwise import will fail. This is why there is a possibility for a cluster’s image to be exported as an offline bundle – for importing into vLCM depot. There is also a third way of exporting – as a bootable ISO that could be imported in the VUM depot and used in baselines.
Exported desired state as an JSON file (Cluster > Updates > Image > Export)
3 – Recommended Images and Hardware Compatibility
The vSphere Lifecycle Manager can recommend images among the ones available in its depot, that are based on the latest ESXi major or minor release.
Recommended Images (Cluster > Updates > Image > View recommended images)
Recommended images are first validated for missing dependencies or conflicting components.
Previously, recommending ESXi images was available only for VSAN clusters, while now they are generally available. However, for vSAN clusters, the validation also runs a hardware compatibility check against the vSAN Hardware Compatibility List – a list with I/O devices certified for use with different vSphere releases.
Hardware Compatibility checks can also be triggered and viewed in details separately.
Hardware Compatibility (Cluster > Updates > Hardware Compatibility)
4 – Overriding depot and settings on cluster level
The global remediation settings can be overridden on the cluster level. In this case, the cluster ones can be compared with global ones and, if needed, reset the settings back to default (e.g. to global ones).
View overridden settings on cluster level (Cluster > Updates > Image > Image Compliance > View settings)
Depots can also be overridden on the cluster level. This is useful for example for clusters in Remote Office and Branch Office (ROBO) deployments that can be setup to download data from a local depot instead of globally defined vCenter depots. If depots are overridden, global depots are not used for the cluster.
View overridden settings on cluster level (Cluster > Updates > Image > Image Compliance > Manage depot overrides)
5 – Better monitoring of Precheck / Remediation
The vSphere Lifecycle Manager provides real-time monitoring of cluster/host precheck and remediation tasks with the ability to cancel it. So far this was possible through Recent Tasks pane; here however we show detailed information at a convenient place.
Monitoring of precheck task
The last results of the precheck and remediation tasks are stored and can be accessed any time later.
Last precheck result (Cluster > Updates > Image > Image Compliance > Last pre-check results)
This list is not exhaustive nor elaborate – we will follow up with more posts on this topic.
