| At the time this book is going to press I have been working with the very first prerelease vPars software for Superdome. This appendix contains salient information related to vPars on Superdome based on my preliminary work. All of the material covered throughout this book applies to vPars on Superdome. The hardware paths of Superdome are substantially different from those on the L-Class and N-Class systems used in the examples throughout this book. I will, therefore, cover some brief examples of vPars on Superdome that include path-related information. Each Superdome hard partition (nPartition) is the equivalent of a separate server. The examples of L-Class and N-Class systems that are used throughout this book are like a Superdome nPartition. We can, therefore, load several vPars on each nPartition provided that we meet all the requirement for vPars at the time of this writing, such as: a separate boot device for each vPar; each Local Bus Adapter (LBA) assigned to only one vPar; a minimum of one CPU per vPar; and so on. For the upcoming example we have indeed met these requirements. The Guardian Service Processor (GSP) on the Superdome is used to supply console control for the Superdome complex. By connecting to the GSP you can select the nPartition that will have console control. You can switch the console control to any of the nPartitions in the Superdome complex. This is different from the Ctrl-A function we use to switch the console between vPars. When we connect to our nPartition using the console through the GSP, we are connected to the nPartition, not to one of the vPars within the nPartition. As part of the configuration of vPars in an nPartition, we will assign the core I/O card to one of the four vPars in our nPartition. Let's begin our Superdome vPar work by viewing a complete Superdome complex and then focusing on one nPartition that will be used to support multiple vPars. | 
