Efficient management and configuration of in-band resources

There is disclosed herein, by way of example, an enterprise server computing platform configured to provide stateless computing, wherein each node has no set configuration, including for example, MAC addresses, UUIDs, firmware, and BIOS by way of non-limiting example. Certain devices or peripherals may be considered “out-of-band,” meaning that they are discoverable and configurable in standby power by a baseboard management controller (BMC) without need for an OS. Certain other peripherals are considered “in-band,” meaning that they may need an OS for discovery and configuration. According to one or more example embodiments of this Specification, a system and method are disclosed for automatically discovering and configuring out-of-band devices on a server. Out-of-band devices may then be disabled, and the server is booted with minimal resources and a bootstrap OS to discover and configure in-band devices.

FIELD OF THE DISCLOSURE

This application relates to the field of virtual computing, and more particularly to a system and method for efficient management and configuration of in-band resources.

BACKGROUND

The unified computing system (UCS) is an x86-based data center platform useful for providing, for example, large-scale data and hosting services. In certain embodiments, a UCS may include one or more blade servers, one or more rack servers, or a combination of blade and rack servers. Both the rack form factor and the blade form factor provide industry-standard connectors and interfaces, enabling a UCS to conform to open protocols and to use third-party hardware and software. In certain embodiments, a UCS may be provided with a plurality of servers, each of which may host a hypervisor such as a VMware ESX, ESXi, a Microsoft Hyper-V, a Citrix Zen server, or similar. In other embodiments, a server may be provided with a host operating system (OS), and may provide other virtual machines, such as a VMware workstation.

It will be recognized that in accordance with industry practice, a hypervisor may be provided in one of at least two configurations. A type I hypervisor runs directly on a server's hardware, and manages guest OSs directly without the need of a host OS.

Examples of type I hypervisor's include the aforementioned VMware ESX and ESXi, Microsoft Hyper-V, and Citrix XenServer.

A type II hypervisor includes a host OS running on the hardware, which then provides hypervisor management software. Examples of type II hypervisors include VMware workstation and virtual box hypervisors. It is also possible to provide certain hybrid hypervisor that are not strictly type I or type II, for example, a kernel-based virtual machine (KVM).

In certain circumstances, it is desirable for a server providing hypervisor functionality to have certain configurable resources rather than fixed and immutable attributes. Thus, one useful function of a UCS is to provide configurable attributes for servers, and thus provide increased flexibility to clients operating hypervisors on the UCS.

Because UCS is an open architecture, it may be compatible with off-the-shelf and legacy solutions. Available resources on a server may be usefully divided into two categories. Out-of-band resources are directly configurable by the UCS, without the need for a host OS running on the server. In-band resources are resources that, for example, may not be UCS-aware because they are legacy or off-the-shelf solutions, and therefore are not directly configurable by an out-of-band management. In that case, in-band resources may need to be configured by an OS.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Overview

There is disclosed herein, by way of example, an enterprise server computing platform such as Cisco's® Unified Computing System (UCS), configured to provide stateless computing, wherein each node has no set configuration, including for example, media access control (MAC) addresses, universally-unique identifiers (UUIDs), firmware, and basic input/output system (BIOS) settings by way of non-limiting example. Certain devices or peripherals may be considered “out-of-band,” meaning that they are discoverable and configurable in standby power by a baseboard management controller (BMC) without need for an OS. Certain other peripherals are considered “in-band,” meaning that they may need an OS for discovery and configuration. According to one or more example embodiments of this Specification, a system and method are disclosed for automatically discovering and configuring out-of-band devices on a server. Out-of-band devices may then be disabled, and the server is booted with minimal resources and a bootstrap OS to discover and configure in-band devices.

EXAMPLE EMBODIMENTS OF THE DISCLOSURE

Different embodiment may have different advantages, and no particular advantage is necessarily required of any embodiment.

An important benefit of UCS as disclosed in this Specification is so-called “stateless computing.” Stateless computing means that each node within the UCS, such as a server, need not have a fixed or immutable configuration. Rather, many attributes of the node can be persistently configured, and the node can then be operated as though those persistent attributes were immutable attributes of a standalone system. For example, a standalone system may have a fixed and immutable media access control (MAC) address for a network interface card (NIC). The MAC address may be, for example, provided by a read-only memory (ROM) or other memory that is not user configurable. In contrast, a node on a UCS may have a user configurable MAC address. Thus, a UCS client can specify a desired MAC address, and the NIC on that UCS node may be configured with that MAC address.

If the NIC is specifically designed to be UCS-capable and aware, then configuration of the NIC may be accomplished by out-of-band management. This means that a UCS manager device (UCSM) may access a baseboard management controller (BMC) resident on the node, and the BMC may autonomously configure the NIC with the desired MAC address. On the other hand, if the NIC is an off-the-shelf or legacy NIC that is not UCS-aware and capable, configuration of the MAC address may not be accomplished via the BMC or out-of-band management. In that case, an OS running on the UCS node may be required to configure a desired MAC address on the NIC. This situation is referred to as in-band management.

Nonlimiting examples of attributes that may be configured by a UCS, either in-band or out-of-band, include the following: For storage devices, worldwide port name (WWPN) or worldwide node name (WWNN) of the server computer, virtual storage area networks (VSANs) with which the server computer is associated, any adapter policy specifying error handling and timing settings, and configurations of the local storage drive of the server computer.

Configurable hardware attributes may include, by way of nonlimiting example, a universally unique identifier (UUID) of the server computer, basic input/output system (BIOS) settings, firmware levels/versions of the server computer, and boot policies.

Network attributes that may be configurable include, by way of nonlimiting example, the MAC address of the server computer, the NIC firmware (e.g., associated with the network interface) of the server computer, the quality of service (QoS) assigned to the server computer, and the virtual local area networks (VLANs) switch to which the server computer is assigned or associated.

Operational attributes that may be configurable include, by way of nonlimiting example, data indicating external management access, firmware bundles and management of the server computer, health policy of the server computer, and an activation attribute that indicates whether the service profile is active or inactive.

FIG. 1is a block diagram of UCS100according to one or more examples of the present Specification. In an example, UCS100includes an enclosure108, a fabric interconnect140, and a plurality of cloud services including a storage area network (SAN)180, a local area network182, and management services184.

Enclosure108may be configured as a rackmount system, a blade system, or any other suitable enclosure type. To facilitate discussion, enclosure108will be treated herein as a blade chassis. Enclosure108may include a number of slots to receive UCS nodes such as servers110. It should be noted that a server is not the only type of possible UCS node, and that other types of UCS nodes are available. For example, certain UCS nodes may be provisioned for use as storage appliances, security appliances, or other useful types of appliances.

In this example, enclosure108includes two servers110. Specifically, server110-1is a full-slot server, while server110-2is a half-slot server. It should be recognized that many other types of servers are possible, and that in certain embodiments, not all servers110need to be necessarily provided with an enclosure108. In some embodiments, a server110may be a standalone device that is communicatively coupled to enclosure108or to fabric interconnect140. It should also be noted that various types of interconnections and buses will be disclosed within this Specification. As used throughout this Specification, a “bus” or “interconnect” includes any wired or wireless interconnection line, network, connection, bundle, single bus, multiple buses, crossbar network, single-stage network, multistage network or other conduction medium operable to carry data between parts of a computing device, or between computing devices. It should be noted that these uses are disclosed by way of non-limiting example only, and that some embodiments may omit one or more of the foregoing buses, while others may employ additional or different buses.

Full-slot server110-1also includes a BMC160-1. BMC160-1is provided to perform management and configuration functions, especially for out-of-band management operation. It should be noted that BMC160is disclosed by way of a specific example, and that certain BMCs160provide management and configuration services that are specific to a Cisco® implementation of UCS. It is not intended, however, that BMC160is restricted specifically to the Cisco® BMC. Rather, BMC160may include any hardware, software, firmware, or combination thereof configured to provide configuration and management services of UCS resources and without the need of a dedicated OS or other similar resident program.

In particular, it is intended that BMC160-1perform configuration and management services while server110is in a low-power state, such as a standby state. In contrast, OS130, or bootstrap OS136may require full-slot server110to be in a relatively high power state. It should also be noted that “low-power” and “high-power” are provided simply as relative terms to one another. In general, a low-power state may include a state where server110is not completely powered on and does not provide all or substantially all of its full functionality, whereas the high-power state is a state where server110is powered on and provides all or substantially all of its capabilities, less capabilities that are specifically disabled for purposes of management and configuration as disclosed herein.

Full-slot server110-1also includes a processor102-1that is configured to communicatively couple to other system elements via one or more interconnects or buses. Processor102-1includes any combination of hardware, software, or firmware providing programmable logic, including by way of non-limiting example a microprocessor, DSP, FPGA, PLA, ASIC, or virtual machine processor.

Processor102-1is communicatively coupled to a memory120-1, for example in a direct-memory access (DMA) configuration. Memory120is disclosed as a single logical block in this example, and may include any suitable volatile or non-volatile memory technology, including DDR RAM, SRAM, DRAM, flash, ROM, optical media, virtual memory regions, magnetic or tape memory, or any other suitable technology. In certain embodiments, memory120may be a relatively low-latency volatile main memory. It should also be noted that although DMA is disclosed by way of non-limiting example, DMA is not the only protocol consistent with this Specification, and that other memory architectures are available.

It should be noted that full-slot server110-1may also include a separate storage, such as a hard drive, optical media, or similar, separate from memory120-1. For simplicity of discussion, memory120-1and storage are not shown as separate logical blocks in this configuration.

Memory120-1may be operable to load and execute both an OS130-1and a bootstrap OS136-1. In certain embodiments, OS130-1and bootstrap OS136-1may not be configured to execute concurrently. Rather, bootstrap OS136-1may be configured to provide discovery, management, and configuration of resources, and in particular in-band resources, as disclosed herein. OS130-1, in contrast, may be configured to provide more traditional OS services, and may be configured to take advantage of the full capability of full-slot server110-1.

Full-slot server110-1may include both in-band resources134-1and out-of-band resources132-1. Out-of-band resources132include those resources that are UCS-aware, or that are otherwise configurable without the need for bootstrap OS136. Thus, UCS100can configure out-of-band resources132-1, including the attributes described herein that may be desirably configured on behalf of an end user, without having to operate full-slot server110-1in a higher power configuration. Rather, out-of-band resources132-1may be discovered and persistently configured while keeping full-slot server110-1in a low-power mode, such as a standby mode.

Enclosure108may also include a half-slot server110-2. It will be recognized that half-slot server110-2is in many respects similar to full-slot server110-1, including the provision of a BMC160-2, processor102-2, memory120-2, OS130-2, bootstrap OS136-2, in-band resources134-2, and out-of-band resources132-2. However, half-slot server110-2may include fewer overall resources then full-slot server110-1. In particular, in some embodiments, half-slot server110-2may include fewer processors and fewer DIMMs, thus providing less processing power and memory.

Full-slot server110-1and half-slot server110-2are provided by way of example only. It is not intended to imply herein that enclosure108is required to have at least one full-slot server110-1or at least one half-slot server110-2. Furthermore, enclosure108may include additional servers110, which may be of any species. Thus, it should be appreciated that enclosure108may include a plurality of different types of UCS nodes in many different configurations.

It will also be recognized that enclosure108may also include blades or slots that are not servers110and that are not UCS specific devices. For example, enclosure108may include additional power supplies and support hardware that is not specific to UCS100. In particular, enclosure108may also include one or more fabric extenders162. In this particular embodiment, two fabric extenders162-1and162-2are shown. Fabric extenders162may be special UCS nodes that may occupy a blade or rack position within enclosure108. In one embodiment, fabric extender162-1and fabric extender162-2may be operable to service different types of servers110.

For example, fabric extender162-1may be configured and operable primarily to service full-slot servers110-1, while fabric extender162-2may be configured and operable primarily to service half-slot server110-2. In certain embodiments, the primary intelligence for performing UCS functions with an enclosure108is provided by fabric extenders162. Thus, fabric extenders162may sit as an intermediary between servers110and a fabric interconnect140. By way of example, fabric extender162-1may include adaptive firmware P, which may be operable to perform global NIC configuration and perform statistics and housekeeping. Fabric extender162may include a chassis manager C, which is configured to perform server discovery and sequencing, power management, temperature monitoring, and fan control looping. An interconnect infrastructure I may be included to provide a data routing interface. In certain embodiments, each of P, I, and C may be provided as ASICs or other fixed-logic device. Advantageously, ASICs provide increased processing speed and efficiency over certain programmable processing devices. It should be noted, however, that the specific features of fabric extender162-1are provided by way of example only, and are intended to be nonlimiting. It will be recognized that many additional configurations are possible for a fabric extender162, and it is intended that they be included within the scope of this Specification.

Fabric extender162may communicatively couple enclosure108to a one or more fabric interconnects140. In this example, two fabric interconnects140-1and140-2are provided. In an example, fabric interconnect140-1is configured and operable to communicate primarily with fabric extender162-1. Fabric interconnect140-2is configured and operable primarily to communicate and work with fabric extender162-2. However, it will be recognized that many other configurations are possible.

Notably, each fabric interconnect140-1includes a UCSM142. UCSMs142may be operable to perform UCS configuration and control services within the context of UCS100. Thus, the primary intelligence and top-level control of the overall UCS100is provided by UCSMs142. UCSMs142include, for example, infrastructure management subsystems, transactional information model subsystems, and an application gateway subsystem that may be configured to interact with system components. In this example, UCSM142-1of fabric interconnect140-1is communicatively coupled to UCSM142-2of fabric interconnect140-2. This provides, in one example, a completely redundant UCS fabric with two independent fabric interconnect paths.

Fabric interconnect may also include a plurality of application-specific integrated circuits (ASICs) G, A, and S, provided for data path connectivity In this example, each UCSM142is communicatively coupled to a G ASIC. UCSMs142may also be communicatively coupled to cloud services, such as management services184. Fabric interconnect140-1and140-2may also be configured to connect to other cloud services. For example, fabric interconnect140-1may communicatively couple to SAN180-1, while fabric connect fabric interconnect140-2may be communicatively coupled to SAN180-2.

Furthermore, fabric interconnect140-1and140-2may both jointly connect to a local area network (LAN)182. Thus, UCS100is operable to connect to a local network, and in appropriate instances may also be operable to connect to a broader network such as an Internet. It should be noted that LAN182and the Internet are provided by way of example only, and other types of networks are anticipated herein. As used herein, a network, including LAN182, includes any communicative platform operable to exchange data or information within or between computing devices, including by way of non-limiting example, an ad-hoc local network, an internet architecture providing computing devices with the ability to electronically interact, a plain old telephone system (POTS), which computing devices could use to perform transactions in which they may be assisted by human operators or in which they may manually key data into a telephone or other suitable electronic equipment, any packet data network (PDN) offering a communications interface or exchange between any two nodes in a system, or any local area network (LAN), metropolitan area network (MAN), wide area network (WAN), wireless local area network (WLAN), virtual private network (VPN), intranet, or any other appropriate architecture or system that facilitates communications in a network or telephonic environment.

FIG. 2is a block diagram of an intelligent platform management interface (IPMI) according to one or more examples of the present Specification. It should be noted that IPMI200is based around BMC160, which was disclosed inFIG. 1. IPMI200is provided not as a replacement forFIG. 1, but rather as an alternate view, in this case with focus on signal interchange and IPMI functions. Thus, the hardware blocks of IPMI200may, in certain embodiments, be realized within UCS100. Those with skill in the art will recognize that there are many possible ways of integrating IPMI200into the disclosure of UCS100.

IPMI is a standards-compliant system interface for computing platforms, and is useful, for example, in performing out-of-band management of computing systems such as UCS100. IPMI200may be operated by a system administrator in configuring access to computing resources.

For example, a customer may contact a system administrator and request that a virtual machine or hypervisor be configured with specific resources. The end user may request that the hypervisor have a specific UUID and a specific MAC address. In cases where adapter170is a UCS-aware adapter, this may be accomplished via out-of-band management. For example, the system administrator may use a standardized interface and protocols to perform management within UCS100, which management may include one or more servers110. Advantageously, the IPMI system200ofFIG. 2may be operated independent of OS130and bootstrap OS136. Thus, IPMI200may be accessed and operated while one or more servers110are in a low-power state, such as standby state. IPMI200may also advantageously be operated by a system administrator in the case that OS130fails or becomes unreachable. This enables the system administrator to perform management of a server110without the need of interfacing with a failed OS.

In an example, a system administrator uses IPMI messaging to perform tasks such as monitoring the status of server110, including parameters such as temperature, voltage, fans, power supplies, and chassis intrusion detection; query inventory information; review logs and alert condition; and perform recovery procedures, including for example issuing requests for remote console access during system powered down and rebooting, or configuring watchdog timers. IPMI200may also include protocols for alerting the system administrator of special conditions.

In an example, IPMI200comprises a BMC160. BMC160may also be communicatively coupled, for example, to a Southbridge Super I/O230, an adaptor170, switching logic250, and inter-integrated circuit (I2C)210. IPMI intelligence is provided by BMC160. In certain embodiments, other controllers may be distributed among various subsystems of server110, within enclosure108, or throughout UCS100. These other management controllers are treated herein as being logically connected to BMC160, but it will be recognized, by those with skill in the art, that devices may be distributed in any suitable fashion, and that in some embodiments BMC160may include more than one piece of physical hardware.

A system administrator may manage BMC160with the remote management control protocol (RMCP). In certain embodiments, where BMC160is to be managed over LAN182or over the Internet, an enhanced version of RMCP called RMCP+, which includes stronger authentication, may be used. BMC160may include a specialized microcontroller, or other processor embedded within BMC160, which itself may be embedded, for example, within a motherboard of server110.

Physical interconnects to BMC160may include, by way of nonlimiting example, a low-pin count (LPC) bus270, system management bus (SMBUS)272, a serial bus274, an I2C bus278, and IPMI bus276. In an example, each of these buses forms an interface to a class of connected devices. For example, IPMI bus276communicatively couples BMC160to IPMI devices220. I2C bus278communicatively couples BMC160to I2C devices210. LPC bus270communicatively couples BMC160to a Southbridge Super I/O subsystem230. SMBUS272communicatively couples BMC160to a network interface card (NIC)240. Serial bus274communicatively couples BMC160to switching logic250, which is in turn communicatively coupled to a serial connector252, which may be, for example, an RS-232, RS 422, Ethernet, FireWire, USB, or other suitable serial port, and to a super I/O258.

In various embodiments, any or all of the peripheral devices described inFIG. 2may be either an in-band resource134, or an out-of-band resource132.

For example, in one embodiment, LPC bus270, and serial bus274may be legacy interfaces that are compatible only with legacy devices that are not suitable for out of band management. On the other hand, IPMI bus276, I2C bus278, and SMBUS272may all be more modern interfaces that are suitable for out-of-band management by BMC160. Thus, during provisioning of server110, BMC116may appropriately provision NIC240and I2C devices210. IPMI devices220may be used in the provisioning step to provide data to BMC160. In other cases IPMI devices220may also need to be provisioned. Once BMC160has properly provisioned NIC240, IPMI devices220, and12C devices210, out-of-band management is complete.

Server110may then disable IPMI bus276, I2C bus278, and SMBUS272. In may then boot to bootstrap operating system136, with only minimal processor102and memory120resources. Server110is then ready for provisioning of in-band resources134. Upon booting, bootstrap OS136may discover the buses that are still enabled, namely LPC bus270, and serial bus274. Bootstrap OS136may then query LPC bus270and serial bus274for attached devices. Bootstrap OS136may therefore discover Southbridge super I/O230, switching logic250, super I/O258, and serial connector252. Finally, bootstrap OS136may perform in band management of these resources and provision them as necessary. Upon completion of this step, server110may be properly configured and ready for use by an end user, and may be powered down, upon which persistent configuration of both in-band and out-of-band resources is maintained.

FIG. 3is a functional block diagram of select elements of a server110according to one or more examples of the present Specification. In this example, server110includes BMC160, which may be communicatively coupled to an I/O controller hub330. BMC160may also be communicatively coupled to UCSM142. UCSM142is communicatively coupled to various client devices. These include a media client380, a keyboard-video-mouse (KVM) client382, a secure socket layer (SSL) client384, and an IPMI client386.

I/O controller hub330may be a subassembly of server110, and in this embodiment includes a basic input/output system (BIOS)334, and bootstrap OS136.

UCSM142includes a number of logical blocks, such as a DME352, an IP tables/network address translation (NAT) module362, a pluggable authentication module (PAM)358, a host aggregator356, and a management controller354. UCSM142is also communicatively coupled to a UCS I/O module360, which may be provided to manage input and output services for UCSM142. The functions of IP tables/NAT module362, PAM358, host aggregator356, and DME352are all well known, and in an embodiment of this Specification, it is intended that these modules perform their known functions. Management controller354may be provided with the particular function of providing a communications interface to BMC160.

BMC160also includes a number of logical blocks. For example, BMC160may include a media server318, a peripheral server322, a serial server324, a serial proxy326, and an IPMI server390. In an example, the logical blocks of BMC160may be provided for performing out-of-band management and configuring interfaces to a plurality of clients. For example, graphics controller316may configure a graphics device for use with KVM client382. Similarly, media server318may be operable for configuring services for media client380. IPMI server390may provision services for IPMI client386.

In addition to the logical blocks disclosed above, BMC160may include a super I/O interface314for communicating with bootstrap OS136and BIOS334, and a processor320. Processor320may include any combination of hardware, software, or firmware providing programmable logic, including by way of non-limiting example a microprocessor, DSP, FPGA, PLA, ASIC, or virtual machine processor.

In an embodiment, a front panel350may be provided as an interactive interface for an end-user to view the status of BMC160and to perform limited control functions. Sensors and component interface340may also be provided so that BMC160may interface with sensors and other components.

It should be noted thatFIG. 3includes a number of logical blocks and elements, each of which is provided by way of nonlimiting example only. Each of the logical blocks ofFIG. 3may include, as appropriate, any combination of hardware, software, and/or firmware necessary to implement its function. Thus, it should be recognized that certain hardware, software, and firmware elements may be shared between various logical blocks, and the logical blocks may be understood to provide a division of function more than a strict division of substance. Those with skill in the art will recognize that there are many additional ways to implement the devices shown inFIG. 3.

FIG. 4is a block diagram of an example method400of performing discovery and configuration of a server110according to one or more examples of the present Specification. Method400starts in block402. In block410, UCSM142discovers out-of-band devices and resources on one or more servers110. As described in this Specification, out-of-band devices include devices that are configurable by a BMC160, or that are otherwise UCS-aware. Discovery of out-of-band devices is accomplished without needing to boot OS130or bootstrap OS136.

In block420, UCSM142configures out-of-band devices. In some examples, this configuration is persistent, and may be stored for example on an internal flash memory for out-of-band devices. Thus, powering off server110and/or rebooting server110does not affect configuration of out-of-band devices.

In block430, UCSM142sets up bootstrap OS136. This may be accomplished, for example, by sending an appropriate signal to full-slot server110instructing server110to perform any actions necessary to prepare bootstrap OS136for operation. In block440, server110boots bootstrap OS136. Booting bootstrap OS136may include a number of steps. For example, in one embodiment, bootstrap OS136performs a full power-on self-test (POST). The POST may include, for example, checking each individual cell of memory120. It may also include performing other self-test features, and scanning hardware. In some examples, each core of processor102performs one or more self-test functions.

After the POST is complete, server110discovers all attached devices. Discovery of devices includes both out-of-band devices and in-band devices. In some embodiments, discovery of devices may also include performing self-testing of devices or otherwise scanning the devices.

Once the devices are properly discovered, bootstrap OS136loads appropriate drivers for each device. This may include for example loading kernel modules that are configured to handle each device. It will be recognized that in some cases, performing step440may take a substantial time. In one example, step440may take approximately ten minutes or more. For some users and clients waiting for resources to be allocated, this delay may be unacceptable. In certain embodiments, the POST is the most time-consuming single element of block440. This is particularly true where server110includes a large amount of memory120. In some cases, server110may include up to several terabytes of memory. Performing a POST of each cell of several terabytes of memory, as well as multiple cores of each of several processors102, may be very time-consuming.

In block450, bootstrap OS136discovers all devices attached to server110. Notably, discovery of devices attached to server110includes discovery of both in-band devices and out-of-band devices. However, in certain cases, out-of-band devices may be ignored in step450, because those out-of-band devices were discovered and configured persistently in block420. Thus, out-of-band devices may be ignored in block450.

In block460, bootstrap OS136configures discovered in-band devices. As with the configuration of out-of-band devices, configuration of in-band devices in block460may be persistent.

In block470, once discovery of all in-band devices is complete, and those in-band devices have been properly and persistently configured, server110may shut down bootstrap OS136.

In block480, devices are properly detected, persistently configured, and allocated. Thus, server110is prepared to boot to a hypervisor environment for operation by a user. It should be recognized that a hypervisor environment is disclosed as only one example of a possible configuration of server110, and that many other configurations, such as a virtual machine, or native OS are possible for booting server110.

FIG. 5is a flow diagram of a method500of configuring allocating resources according to one or more examples of the present Specification. Method500starts in block502. In block510, UCSM142discovers out-of-band devices and resources on one or more servers110. As described in this Specification, out-of-band devices include devices that are configurable by a BMC160, or that are otherwise UCS-aware. Discovery of out-of-band devices is accomplished without needing to boot OS130or bootstrap OS136.

In block520, UCSM142configures out-of-band devices. In some examples, this configuration is persistent, and may be stored for example on an internal flash memory for out-of-band devices. Thus, powering off server110and/or rebooting server110does not affect configuration of out-of-band devices.

In block530, UCSM142sets up bootstrap OS136. This may be accomplished, for example, by sending an appropriate signal to full-slot server110instructing server110to perform any actions necessary to prepare bootstrap OS136for operation.

In block540, bootstrap OS136may disable out-of-band devices and excess resources. Disabling out-of-band devices may include powering them down, or simply allocating a table that indicates that the devices are not to be detected or configured in the following steps. In one example, disabling excess resources includes disabling all but one core of each processor102. Disabling excess resources may also include disabling all but one memory bank of memory120for each processor102. This provides a minimal amount of processing power and memory during the boot process. Although this processing power and memory may be substantially reduced from the total available within server110, the trade-off may be acceptable inasmuch as bootstrap OS136is not configured to perform heavy processing loads, but rather to only configure in-band devices, and otherwise prepare server110for operation by an end user.

In block542, server110boots bootstrap OS136. As with block440ofFIG. 4, booting bootstrap OS136may involve a POST. However, instead of several terabytes of memory, this process may include a self-test of only a few gigabytes, or in some examples only a few hundred megabytes of memory. Furthermore, rather than involving multiple cores of multiple processors, the POST of block542involves only one core of several processors in an example embodiment. As noted above, the POST of block440ofFIG. 4may be the most time-consuming aspect of booting bootstrap OS136. Thus, by disabling excess resources that are not necessary or desirable for carrying out the function of bootstrap OS136, block542ofFIG. 5may substantially reduce the time to complete the booting of bootstrap OS136. As with block440ofFIG. 4, block542discovers available devices and loads drivers for those devices. However, in one embodiment, rather than scanning, discovering, and loading drivers for all attached devices to server110, the scanning, discovering, and loading of block542involves only scanning, discovering, and loading drivers for in-band devices that were not disabled in block540.

Thus, in block550, discovery of devices involves discovering only remaining devices, which in an example includes only in-band devices and other devices minimally necessary to boot bootstrap OS136.

In block560, server110configures in-band devices. As with block460ofFIG. 4, this configuration is persistent, so that when bootstrap OS136is shut down, and server110is powered down or restarted, the configuration is not lost.

In block570, configuration and preparation is complete, so that bootstrap OS136may be shut down.

In block580, server110is properly prepared and provisioned, and a hypervisor is booted. As before, a hypervisor is disclosed as only one example of a possible operating configuration for server110.

Throughout this Specification, certain features of the disclosure may be described in terms of modules, functions, or other logical blocks. It should be noted that according to modern computer architecture practices, these logical blocks may include any combination of hardware, software, firmware, or similar. For example, any computing device disclosed herein may include a processor, a memory, and one or more interconnect interfaces. In many cases, however, a processor may be provided as part of a virtual machine architecture or other emulation or virtualization environment, in which a physical processor provides a virtual processor via software. Similarly, “memory” need not refer to a single monolithic memory element or structure. Rather, “memory” may include, by way of non-limiting example, on-chip cache, L1 memory, L2 memory, cache memory, main memory, paging files, or virtual memory. Furthermore, a memory structure such as a main memory may be subdivided into one or more memory banks, which may be interleaved or otherwise arranged.

Logical blocks also need not be physically separate devices. For example, in some cases, a “memory” and a “storage” will be shown as separate logical blocks, but those with skill in the art will easily recognize that in some architectures, a single physical memory block may serve as both a main memory and a storage region. Similarly, a network interface and a peripheral interface may be disclosed as separate logical blocks, but in many cases, a network protocol such as a virtual terminal or hypervisor is provided so that peripherals and user interface elements are accessed via a network such as an internet protocol (IP) network.

Thus, at a high level, it should be appreciated that the logical blocks disclosed herein represent functions that may be carried out by some combination of hardware, software, and/or firmware, while the various interfaces disclosed represent any communication medium, including appropriate hardware and software protocols, internal or external, that may be used to communicatively couple those logical elements to one another.

Certain embodiments, including for example BMC160, may readily include a system on chip (SOC) central processing unit (CPU) package. An SOC represents an integrated circuit (IC) that integrates components of a computer or other electronic system into a single chip. It may contain digital, analog, mixed-signal, and other functions: all of which may be provided on a single chip substrate. Other embodiments may include a multi-chip-module (MCM), with a plurality of chips located within a single electronic package and configured to interact closely with each other through the electronic package. In various other embodiments, the digital signal processing functionalities may be implemented in one or more silicon cores in Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and other semiconductor chips.

In example implementations, at least some portions of the processing activities outlined herein may also be implemented in software. In some embodiments, one or more of these features may be implemented in hardware provided external to the elements of the disclosed figures, or consolidated in any appropriate manner to achieve the intended functionality. The various components may include software (or reciprocating software) that can coordinate in order to achieve the operations as outlined herein. In still other embodiments, these elements may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof.

Additionally, some of the components associated with described microprocessors may be removed, or otherwise consolidated. In a general sense, the arrangements depicted in the figures may be more logical in their representations, whereas a physical architecture may include various permutations, combinations, and/or hybrids of these elements. It is imperative to note that countless possible design configurations can be used to achieve the operational objectives outlined herein. Accordingly, the associated infrastructure has a myriad of substitute arrangements, design choices, device possibilities, hardware configurations, software implementations, equipment options, etc. Furthermore, in various embodiments, the processors, memories, network cards, buses, storage devices, related peripherals, and other hardware elements described herein may be realized by a processor, memory, and other related devices configured by software or firmware to emulate or virtualize the functions of those hardware elements.

Any suitably-configured processor component can execute any type of instructions associated with the data to achieve the operations detailed herein. Any processor disclosed herein could transform an element or an article (for example, data) from one state or thing to another state or thing. In another example, some activities outlined herein may be implemented with fixed logic or programmable logic (for example, software and/or computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (for example, (FPGA), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM)), an ASIC that includes digital logic, software, code, electronic instructions, flash memory, optical disks, CD-ROMs, DVD ROMs, magnetic or optical cards, other types of machine-readable mediums suitable for storing electronic instructions, or any suitable combination thereof. In operation, processors may store information in any suitable type of non-transitory storage medium (for example, random access memory (RAM), read only memory (ROM), (FPGA), (EPROM), (EEPROM), etc., software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. Further, the information being tracked, sent, received, or stored in a processor could be provided in any database, register, table, cache, queue, control list, or storage structure, based on particular needs and implementations, all of which could be referenced in any suitable timeframe. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory.’ Similarly, any of the potential processing elements, modules, and machines described herein should be construed as being encompassed within the broad term ‘microprocessor’ or ‘processor.’

Computer program logic implementing all or part of the functionality described herein is embodied in various forms, including, but in no way limited to, a source code form, a computer executable form, and various intermediate forms (for example, forms generated by an assembler, compiler, linker, or locator). In an example, source code includes a series of computer program instructions implemented in various programming languages, such as an object code, an assembly language, or a high-level language such as OpenCL, Fortran, C, C++, JAVA, or HTML for use with various OSs or operating environments. The source code may define and use various data structures and communication messages. The source code may be in a computer executable form (e.g., via an interpreter), or the source code may be converted (e.g., via a translator, assembler, or compiler) into a computer executable form.

In the discussions of the embodiments above, the buffers, graphics elements, interconnect boards, clocks, DDRs, switches, digital core, transistors, and/or other components can readily be replaced, substituted, or otherwise modified in order to accommodate particular circuitry needs. Moreover, it should be noted that the use of complementary electronic devices, hardware, non-transitory software, etc. offer an equally viable option for implementing the teachings of the present disclosure.

In one example embodiment, any number of electrical circuits of the FIGURES may be implemented on a board of an associated electronic device. The board can be a general circuit board that can hold various components of the internal electronic system of the electronic device and, further, provide connectors for other peripherals. More specifically, the board can provide the electrical connections by which the other components of the system can communicate electrically. Any suitable processors (inclusive of digital signal processors, microprocessors, supporting chipsets, etc.), memory elements, etc. can be suitably coupled to the board based on particular configuration needs, processing demands, computer designs, etc. Other components such as external storage, additional sensors, controllers for audio/video display, and peripheral devices may be attached to the board as plug-in cards, via cables, or integrated into the board itself. In another example embodiment, the electrical circuits of the FIGURES may be implemented as stand-alone modules (e.g., a device with associated components and circuitry configured to perform a specific application or function) or implemented as plug-in modules into application specific hardware of electronic devices.