So what about those promised details on the HMC? Yeah, so in the previous videos, I mentioned the HMC, the hardware management console, as the component of PowerVM virtualization that handles the configuration of the LPARs. I did also mention NovaLink does that as well, but we're going to talk about the HMC, so let's have a closer look. All right, so the HMC is a PC-based console that's available in the desktop, or rack mount model, or in a virtual model. It runs a customized version of Linux with a management application based on Java. The user can access only the management console application, and no additional applications can be installed. A second HMC can be connected to a single managed system for redundancy. A single HMC can manage multiple managed systems. Remote access to the HMC application is provided by using a web browser. And finally, there are extensive HMC command line controls that are accessible by using SSH. So the HMC provides access, in summary, to the following key functions, virtual console, LPAR configuration and management tools, capacity on demand capabilities. That's the ability to use latent capacity in your system on demand and pay only as the capacity is used. Hardware service tools, very important, including error logging at the server level, consolidating errors from all the LPARs in a single filtered view. We'll talk much more about that in a later video. And then higher-level functions like the aforementioned VM relocation, or live partition mobility, it's called. Partition remote restart, which is the ability to remotely restart an LPAR when the machine that it was on has failed. And shared storage pools, a concept for accessing storage that we aren't going to get into any detail in here. So as you see, understanding how to use an HMC is critical to managing a PowerVM environment. But again, PowerVC above that can many cases obfuscate the need for HMC skills. So let me expand the previous PI diagram to show the HMC connection and elaborate on its functions. Now, the managed system refers to the system that is being managed by the HMC. Now, although the HMC is necessary for some functions, such as configuring LPARs, it's not needed for the operation of the partitions, right? It's disconnected, disconnected from the processing of the LPAR. So therefore, if something goes wrong on the HMC, the partitions are truly unaffected. The partition configuration information is not only kept on the HMC, but it's also kept in nonvolatile RAM, or NVRAM, on the managed system. Therefore, if the HMC crashes, the partitions would continue to run. In fact, you can remove the HMC, replace it with another, and then download the partition data from the NVRAM on the managed system without affecting their running partitions. An HMC's connected to the manage system through an Ethernet connection to the service processor. The service processor is yet another processor, separate and independent, that provides hardware initialization during system load. It monitors the environment, and it provides processing on error events and maintenance support. [MUSIC]