Note: I am using some internal versions of the DSM 2.0 product which may not be generally available yet. Therefore some of the screenshots captured in this post may differ slightly in the released product. However, for the purposes of our getting started series of posts, this should not matter too much.
Maintenance Policy
It is important to note that upgrades of the DSM provider may also be scheduled. The Maintenance Policy configuration option allows a DSM user to set a future date which will stage and install the provider update automatically as per the date and time defined in the schedule. The Maintenance Policy can be configured from DSM UI as well as from the vSphere Client, and is found under Versions and Upgrades (see screen shot below). However, for the purposes of this post, I will manually trigger an upgrade of the DSM provider rather than wait for a maintenance slot.
Upgrades Available
Notifications for available upgrades to the DSM provider appear in two locations, the vSphere Client and the DSM UI. In the vSphere Client, under Configure > Data Services Manager > Version & Upgrade, Available Upgrades displays any new versions that might be available. When the Tanzu Net Token is configured in the DSM Settings, details about available upgrades are automatically retrieved and is highlighted in the UIs. Note that this particular upgrade also requires a reboot of the DSM provider, as per the field ‘Expected Impact’. Therefore you may wish to schedule this upgrade outside of production hours.
In the DSM UI, the same information on Available Upgrades is viewable.
In both the vSphere Client and the DSM UI, click on the bread-crumbs to the left of the ‘Source Version’ (first filed) which allows you to Stage and Install the upgrade. When Stage is initiated, the status changes to “Stage in progress” to reflect this:
Once the staging step has downloaded the upgrade components, clicking on the breadcrumbs now allows an install to take place. The status is currently showing ‘Ready to install’.
And as one might expect, selecting Install will change the status field once again, this time to “Install in progress”.
At this point, the DSM UI will display a popup message saying that it is entering maintenance mode. This means that certain DSM actions are not possible during this upgrade.
The upgrade task, including the time to reboot the DSM appliance, usually takes a number of minutes.
Upgrade Success and History
If an upgrade requires the DSM provider to reboot, then there may be various errors returned in the UI whilst the provider is offline. Many errors could relate to http 502 errors or 502 bad gateway errors. However, once the upgrade has completed successfully, these errors will no longer be visible, and the UI should now show that new details about the upgrade. If the upgrade involved the installation of a new vSphere Client Plugin, then it will also be necessary to refresh the browser containing the vSphere Client. There should be a popup in the vSphere Client to indicate this. Once the upgrade is complete, the Upgrade History should be visible in both the DSM UI and the vSphere Client. The Upgrade History details should include the original DSM version, the new version, the status of the upgrade and when it was upgraded, as shown below.
That completes the upgrade. Hopefully you can see how easy it is to implement. DSM allows these upgrades to be done as soon as an update becomes available, or you can setup a Maintenance Policy which will automatically do the upgrade when the time configured in the maintenance policy is reached.