> This page is for version 11 (default). > For other versions, use one of these documentation indexes: > - 11 (default): https://docs.nvidia.com/base-command-manager/product-manuals/11/llms.txt > - 10: https://docs.nvidia.com/base-command-manager/product-manuals/10/llms.txt > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/base-command-manager/product-manuals/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/base-command-manager/product-manuals/_mcp/server. # Introduction Download PDF This *Upgrade Manual* describes the procedure for upgrading a BCM (Base Command Manager) cluster that is being managed by BCM version 10, to a cluster managed by BCM version 11. A clean installation of BCM is recommended instead of an upgrade because it is simpler. If an upgrade is to be carried out, then reasonable familiarity with Base Command Manager is assumed. A good idea is to look up any unfamiliar concepts described in this manual in the other BCM manuals. The *Upgrade Manual* should be read carefully before the upgrade. The BCM Support team can be contacted using [https://enterprise-support.nvidia.com/s/create-case](https://enterprise-support.nvidia.com/s/create-case) if there are BCM-related upgrade issues for which the documentation is insufficient. ## 1.1 Supported BCM Versions And Linux Distributions ### 1.1.1 Upgrades From The Following BCM Versions Are Supported: * BCM 10 ### 1.1.2 The Following Linux Distributions Are Supported: * RedHat Enterprise Linux 8 (update 8.10 and later) * RedHat Enterprise Linux 9 (update 9.5 and later) * Rocky Linux 8 (update 8.10 and later) * Rocky Linux 9 (update 9.5 and later) * SuSE Linux Enterprise Server 15 (SLES15 SP6) * Ubuntu 22.04 * Ubuntu 24.04 ### 1.1.3 An Overview Of Software Upgrades In Relation To A Cluster These three softwares can be considered when upgrading the main softwares for a cluster. * The underlying (distribution) OS on the head node. * The BCM software that manages the regular (compute) nodes and is on the regular nodes * The underlying (distribution) OS on the regular nodes. That OS is what is provided by the software image. #### 1.1.3.1 Upgrading The Underlying OS Is Not Supported The underlying OS is the software that runs the head node. This can be any of the distributions listed in [section 2.1.1 of the *Installation Manual*](/installation/introduction#211-what-os-platforms-is-it-available-for). It is the distribution on which BCM runs. BCM in turn provides software images that are provisioned to the other nodes. The software images run on an underlying distribution OS that can be the same distribution as on the head node, but can also be of another distribution. The architecture can be `x86_64` or `aarch64`. Upgrading the underlying OS, that is, upgrading from the existing major release of the OS upon which BCM runs, to the next major release of the OS (for example, RHEL8 to RHEL9, or Ubuntu 22.04 to Ubuntu 24.04) while keeping BCM as it is, is not supported. If the underlying OS is to be upgraded, then BCM must be reinstalled from scratch. #### 1.1.3.2 Upgrading BCM Is Supported The discerning reader will have understood that upgrading the BCM cluster manager software from version 10 to 11 is the subject of this upgrade manual. The upgrade to BCM is carried out for the head node(s), and is carried out for the BCM used on the images that are used by the regular nodes. The upgrade process requires planning, preparation, and commitment, because once the upgrade is started—which is really when `cm-upgrade` is executed—rolling back is very hard. The parallel upgrade procedure (section [1.2](#12-parallel-vs-in-place-upgrades)) is recommended for cluster administrators who would like to check along each step of the way as they upgrade. #### 1.1.3.3 Upgrading The Software Images Is Supported Creating software images for provisioning is described in [section 9.6 of the *Administrator Manual*](/admin/softwareimagemanagement#96-creating-a-custom-software-image). Upgrading the software images that are provisioned to other nodes is possible. This is however independent of a BCM upgrade. This means that, for example, an Ubuntu 22.04 image can be upgraded to an Ubuntu 24.04 image for a regular node while keeping the BCM 10 head node running Ubuntu 22.04. Sometimes that is all that the cluster administrator or users require, instead of upgrading BCM 10 to BCM 11. An implication of the support for image OS upgrades independent of BCM upgrades is that a new DGX OS 7 image (which is based on Ubuntu 24.04) can be upgraded from a DGX OS 6 image (which requires Ubuntu 22.04 on the head node) in BCM 10 if the cluster has multiOS. However, only the B200 hardware is supported by DGX OS 7 in BCM 10, and it requires Ubuntu 24.04 on the head node. This means that DGX image upgrades from DGX OS 6 to DGX OS 7 for an Ubuntu 22.04 head node are not a supported image upgrade path in BCM 10. Upgrading to BCM 11 and then setting up a new DGX 7 image within the new BCM 11 is recommended instead. BCM 11 clusters do not support DGX 6 images. This means that if a BCM 10 cluster with DGX OS 6 images is upgraded to BCM 11, then new DGX OS 7 images must be created when upgrading, by following the procedure in section [2.10.12](/upgrade/parallelupgrade#21012-enable-mixed-os-setup-and-create-a-dgx-os-7-image) for a parallel upgrade, or in section [3.8.13](/upgrade/inplaceupgrade#3813-enable-mixed-os-setup-and-create-a-dgx-os-7-image) for an in-place upgrade (the idea behind a parallel upgrade and in-place upgrade is described in section [1.2](#12-parallel-vs-in-place-upgrades)). When upgrading the software image, it is important to note that any configuration changes that were carried out on the old image need to have their equivalents or their analogous versions carried out for the new image. ## 1.2 Parallel Vs In-place Upgrades There are two kinds of upgrades possible. 1. A **parallel upgrade**: This is when a clone is made of the active head node. This means that * For a cluster with one head node (a cluster with no HA failover configuration), the clone is a new clone of the head node, and that there are now two head nodes in existence—one active, and one clone. * For a cluster with two head nodes (a cluster with an HA failover, with one head as one active, and one head as the passive), the clone is a new clone of the active head node, and that there are now 3 head nodes in existence—one active, one passive, and one clone. The clone is taken away and isolated from the network of the original cluster. Any passive is also taken to the new network and made the passive of the clone. The cloned system (that is: head node, or active head node and passive head node) is then upgraded. Meanwhile, the original head node keeps managing the cluster, so that there is not such a severe pressure on getting the upgraded cluster up before a deadline. This means that if there are unexpected issues that take time to resolve during upgrade, then the original cluster and users remain unaffected. After the required upgrade steps are completed for the isolated head node (or head node pair) that is undergoing the upgrade, then the unupgraded head node that is managing the cluster is replaced by the upgraded head node (or head node pair). 2. An **in-place upgrade**: This is when an upgrade is carried out using the existing head node or head nodes in a production cluster. The regular nodes need to be powered off when the upgrade is carried out, which means a significant downtime and can mean a severe pressure on the cluster administrator to get the upgraded cluster up before a deadline. Chapter [2](/upgrade/parallelupgrade) covers the steps and considerations for the upgrade procedure that are specific to the parallel upgrade. Chapter [3](/upgrade/inplaceupgrade) covers the steps and considerations for the upgrade procedure that are specific to the in-place upgrade. --- [Download this manual as a PDF](https://docs.nvidia.com/base-command-manager/manuals/11/upgrade-manual.pdf)