Sometimes the best way to show the value of something is to show it in action. For example, I could show you a picture of my favorite guitar and describe how the hollow body resonates for a warmer, woodier sound, then describe how the pickups are crazy good at replicating the natural tones of the quality woods they’re made from…or you could just hear it in action.
The same is true for Flex System Manager (FSM). In this article, instead of just describing how Flex System Manager is built (even though I’m crazy-proud of its new FSM Explorer user interface), I’m going to show you a very specific example. I’ll show you the value FSM can add to your Power environment without bringing down your workloads when it comes to firmware updates.
Setting the Scene
I’ll be walking through how to use FSM to check ibm.com for updates; take your compute node out of production, which will initiate a relocate of your important workloads (VMs, or what we know as partitions) to other Power compute nodes in your Flex environment; update your Power compute node; and return the compute node into production. To do this, I’ll be using FSM configured with server system pool support that orchestrates live relocation (under the hood, FSM uses Fix Central and PowerVM’s live partition mobility).
See a Problem, Check for Updates
The first step in this scenario is seeing a problem in the chassis map and beginning to solve it. Figure 1 shows an error in the flyover of the compute node that mentions something about firmware.
Once you see there might be a problem related to firmware, the first step to solve it is to check Fix Central to see what, if any, updates are needed. The fastest way to do this is to select the Release Management > Acquire Updates menu action and select Check for updates. This will connect you to ibm.com and pull down a list of needed updates (note that only the list is downloaded, not the binary files). If you decide to install the update(s), you can then download the full binary file.
If you’re like a lot of IBM’s customers, your FSM won’t have a direct (or proxy) Internet connection. In that case, you’d go directly to Fix Central, download the updates, and then import them into FSM using the Acquire Updates menu action (Figure 2).
Once you import the updates, a Show and Install Updates button appears, which lets you verify the firmware level that IBM says you need (Figure 3).
You can verify that your firmware is out of date by using the compliance view in the chassis map (Figure 4). In this example, you can see that although I’m using a rather out-of-date system, the next firmware level I’ve imported is higher than the currently installed firmware.
Note that I’m using IBM’s standards as an example, but you can also set up your own compliance policy to ensure all your Power compute nodes match a specific firmware level. This is the system most customers I talk to use, since the “latest and greatest” levels need to undergo quite a bit of testing before they’re released in real customer environments. FSM lets you download the latest update—what IBM says is needed to a test system—verify that it works, update your compliance policy with that update, then have your IT staff roll out the firmware update using the method I’m showing here.
Take the Compute Node Out of Production: Relocate VMs
Now that you’ve identified the firmware to update and the compute node that needs the update, you’ll want to move all workloads off of that compute node. FSM makes that fairly easy by utilizing live partition mobility through the Enter Maintenance Mode and Relocate actions (Figure 5).
I was able to relocate all VMs from the compute node in two clicks because I grouped all my Power compute nodes into a system pool. This system pool contains software that ensures servers in the pool can host the VMs being moved based on performance and status. The actions then show you what they plan to do to each VM in the current compute node and which compute they plan to move the VMs to. Once you click OK on the relocation, you can watch the VMs move using the FSM Explorer view (Figure 6). (Note that I’m not trying to trivialize the steps you’ll need to go through to activate mobility across your compute nodes. My hope is that by showing you how easily you can harness LPM’s capabilities, you’ll find that mobility has even greater value.)
Update Your Compute Node
Now that your compute node is empty of VMs, you can install the firmware. To get back to the list of needed firmware, right-click the compute node from either the Hosts view or Chassis Map view and select Show and Install Updates. This will bring up the window shown in Figure 7. Select the firmware update then click the Install button.
The install wizard itself is very simple, so once you start installing, you can open the job details view to see progress of each step, as shown in Figure 8.
Notice that if you hadn’t imported the firmware update and Flex System Manager had an Internet connection, it would bundle all the steps to install, including:
- Downloading from ibm.com
- Pushing the update out to the compute node (staging) installing
- Collecting the updated firmware inventory
- Verifying compliance
Of course, you could perform the first two steps independently. You can download or import the update when it’s convenient for you, and you can also “stage” the install by selecting the update and then selecting Installation Staging. This will push the update (which could be quite large) out to the compute node so that when your maintenance window begins, you can focus on installing the firmware, not pushing the binaries around your network.
One more thing about viewing job status: If you have to leave your office while the update is installing, you can use the new Flex System Manager Mobile app to view recent job status…meaning you can see from your phone when the installation completed.
Return the Compute Node Into Production
Once the install task has completed, you’ll want to confirm the update on the compute node, test it out, and then return the compute node into production. To confirm the update installation, simply go back to the chassis map and mouse over the compute node. Figure 9 shows the updated firmware level.
Once you see the updated firmware level, you can right-click and select Availability > Exit Maintenance Mode. This will put the compute node back into active system pool membership, and future deployed VMs could target this host. If you want to move a specific VM back into this host, right-click a VM, select Relocate, and choose which host you want it to go to. Or, you can optimize the system pool so that if some hosts in the pool are fully utilized, a few VMs might be moved onto the compute node you just added back into production.
The Value of FSM
I hope this article helped you see the potential value FSM can offer your shop. After you’ve walked through this update process once, you can expand on it and select multiple updates across multiple systems. For example, FSM lets you select all components in a chassis and then choose Show and Install Updates. With many compute nodes selected, you might see quite a list of updates that mix Power and x86 compute nodes. You can pick multiple updates to install, click the Install button, and watch as multiple targets are updated. Of course, you should only update what you’re comfortable with—start small and let FSM prove itself as a trusted tool.
To learn more about update process and FSM, see the references below. See you next time!