Upgrading VMware Cloud Director with Single API Call

Today I have upgraded two VMware Cloud Director environments to version 10.3.2 each with 3 appliances with two API calls. All that thanks to VMware Cloud Lifecycle Manager.

curl --location --request PUT 'https://172.28.59.10:9443/api/v1/lcm/environment/vcd-env-2/product/vcd-1/upgrade?action=UPGRADE' \
--header 'Content-Type: application/json' \
--header 'JSESSIONID: 4E908BE08C282AF45B1CF5BB6736FE32' \
--data-raw '{
    "upgradeDetails": {
        "targetVersion": "10.3.2",
        "additionalProperties": {
            "keepBackup": true
        }
    }
}'

As I have blogged about the VMware Cloud Provider Lifecycle Manager (VCP LCM) in the past I just want to highlight how it handles frequent updates of the solutions it manages. VCP LCM is now in version 1.2 and deployed as an appliance. It is update about twice a year. However when one of the solution that it manages has a new update (VMware Cloud Director, Usage Meter, Tenant App) a small LCM interop update bundle is released (VCP LCM download page, Driver and Tools section) that provides support for update of the newly released solution(s). That way there is no lag or need to wait for new (big) VCP LCM release.

So in my case all I had to do was just download and apply (unzip and execute) the new LCM interop bundle, download the VCD 10.3.2 update file to my VCP LCM repo (NFS) and trigger the API update call mentioned above.

The interop bundle(s) are versioned independently from the VCP LCM itself, are cumulative and do check if the actual underlying VCP LCM will suport the bundle (for example LCM Interop bundle 1.2.1 can be installed on top of VCP LCM 1.2 or 1.2.0.1 but not on 1.1). This can be seen in the interop_bundle_version.properties file (inside .lcm zipped file).

product.version=1.2.0,1.2.0.1
vcplcm_interop_bundle.build_number=19239142
vcplcm_interop_bundle.version=1.2.1

I should mention that VCP LCM only supports environments that it created. It does have import functionality, but that is to import existing VCP LCM deployed environments as it does not (currently) keep their state when it is rebooted.

So what is actually happening when the update is triggered with the API call? In a high level: VCP LCM will first check that the to be updated environment (VCD installation) is running properly, that it can access all its cells, etc. Then it will shut down the VCD service and database and create snapshot of all cells for quick roll back if anything goes wrong. Then it restarts the database and creates regular backup which is saved to VCD transfer share. Update binaries are then uploaded and executed on every cell followed by database schema upgrade. Cells are rebooted and checks are performed that VCD came up properly with the correct version. If so snapshots can be removed and optionally the regular backup as well.

Happy upgrades!