Nutanix Life Cycle Manager

Read Time:2 Minute, 6 Second

Nutanix Life Cycle Manager (LCM)

With the introduction of AOS 5 Nutanix introduced Life Cycle Manager (LCM), something that Is one of the best but least known Nutanix features. Put simply its part of the Nutanix update mechanism but for dealing with hardware rather than the software components.

To me what makes LCM stand out is its pure simplicity. I have seen other solutions where it can be confusing to find out what hardware is on the HCL and then what firmware version is required and then the appropriate driver for that combination. This becomes unmanageable at a large enough scale. Where I currently work we have a mix of five different Nutanix node types of different hardware generations. ( All based on Supermicro hardware) . The below screenshots walk through an upgrade of one of these clusters.

The above picture demonstrates the simplicity, It’s showing that at present the only update available is to the “Cluster Software Component” Once this has been updated the next step is to perform an Inventory of your cluster.
LCM will then show you all of the components in your cluster and the relevant upgrades available. If you work in a “Dark Site” . Offline downloads are also available.
The below cluster has not had any updates run against it.

Once the inventory has been done its time to decide if you want to run all of the updates or just a selection and off you go.

You can see above all of the available updates in this 3 node cluster. Note than only 2 of the SSD’s needed updates as we had previously had one replaced and this was shipped with a later firmware.

Because the LCM is aware of the end to end stack it’s aware of any relevant dependencies. The upgrade for the HBA listed below doesn’t have any.

Once you have started the upgrade progress LCM handles the orchestration piece, stopping just the required services and functions to allow the upgrade to complete.

For the HBA upgrade, LCM stopped the storage-related services on the CVM but it left the CVM powered on and was not required to evacuate VM’s from the ESXi host. This meant that the upgrade was done very quickly and the storage services started again before moving to the next node.