Persistent peripheral component interconnection express pass-through configuration in a virtualized environment
The system automates PCIe pass-through device reconfiguration by updating component allocation tables based on change events, addressing the challenge of cumbersome manual processes and reducing downtime in virtualized environments.
Patent Information
- Application Number
- DE102025101313
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-01-29
- Filing Date
- 2025-01-15
- Publication Date
- 2025-07-31
AI Technical Summary
Current systems lack automated mechanisms for reconfiguring Peripheral Component Interconnect Express (PCIe) pass-through devices to virtual machines (VMs) during deployment and maintenance, leading to cumbersome tasks and increased downtime in data centers and cloud environments.
Implementing a system that automatically updates a component allocation table based on change events involving components and VMs, using an operating system agent to manage PCIe device slots and VM/container IDs, and storing configuration information in tables to facilitate automated reconfiguration.
Enables seamless and automated reconfiguration of PCIe pass-through devices, reducing administrative effort and minimizing downtime during device additions, removals, or VM reconfigurations in virtualized environments.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
GENERAL STATE OF THE ART
[0001] Computing devices can provide services to users. To provide the services, the computing devices can include components. The components can be used to perform at least some of the services. The components can be added or removed from the computing devices over time. The software of the computing devices, such as virtual machines, can use the components to provide the services. A computing device can include multiple VMs (virtual machines), each using one or more of the components. The components can be allocated to the VMs to enable the VMs to use the components. SUMMARY
[0002] In general, the embodiments disclosed herein relate, in one aspect, to a method performed to configure components. The method includes identifying, by an operating system (OS) agent of a production host, a first change event, wherein: the production host includes a plurality of components and the plurality of components are used by a plurality of virtual machines (VMs) executing on the production host; making a first determination that the first change event is associated with a component of the plurality of components; updating a component allocation table based on the first change event in response to making the first determination; identifying a second change event; making a second determination that the second change event is associated with a VM of the plurality of VMs;Updating the component allocation table based on the second change event in response to making the second determination; and providing updated component allocations to an OS of the production host and the plurality of VMs, the component allocations enabling the plurality of VMs to use the plurality of components to perform computer-implemented services.
[0003] In general, the embodiments described herein relate, in one aspect, to a non-transitory computer-readable medium including computer-readable program code that, when executed by a computer processor, enables the computer processor to perform a method for configuring components. The method includes identifying, by an operating system (OS) agent of a production host, a first change event, wherein: the production host includes a plurality of components and the plurality of components are used by a plurality of virtual machines (VMs) executing on the production host; making a first determination that the first change event is associated with a component of the plurality of components; updating a component allocation table based on the first change event in response to making the first determination;Identifying a second change event; making a second determination that the second change event is associated with a VM of the plurality of VMs; updating the component allocation table based on the second change event in response to making the second determination, and providing updated component allocations to an OS of the production host and the plurality of VMs, the component allocations enabling the plurality of VMs to use the plurality of components to perform computer-implemented services.
[0004] Further aspects of the embodiments disclosed herein will become apparent from the following description and the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Certain embodiments of the invention will be described with reference to the accompanying drawings. However, the accompanying drawings only illustrate certain aspects or implementations of the invention by way of example and are not intended to limit the scope of the claims. Fig. 1A shows a diagram of a system according to one or more embodiments disclosed herein. Fig. 1B shows a diagram of a memory according to one or more embodiments disclosed herein. Fig. 2 shows a flowchart of a method for generating an initial component allocation table according to one or more embodiments disclosed herein. Fig. 3A-3B show a flowchart of a method for updating a component allocation table according to one or more embodiments disclosed herein. Fig. 4 shows a diagram of a computing device according to one or more embodiments disclosed herein. DETAILED DESCRIPTION
[0006] Specific embodiments will now be described with reference to the accompanying figures. In the following description, numerous details are set forth as examples of the embodiments disclosed herein. It will be apparent to those skilled in the art that one or more of the embodiments disclosed herein may be practiced without these specific details, and that numerous variations or modifications are possible without departing from the scope of the embodiments disclosed herein. Certain details known to those skilled in the art have been omitted to avoid obscuring the description.
[0007] In the following description of the figures, each component described with respect to one figure may, in various embodiments disclosed herein, be equivalent to one or more like-named components described with respect to another figure. For brevity, descriptions of these components are not repeated for each figure. Therefore, each individual embodiment of the components of each figure is incorporated by reference and is understood to be optionally present in any other figure having one or more like-named components. Furthermore, in accordance with various embodiments disclosed herein, each description of the components of a figure is to be construed as an optional embodiment that may be implemented in addition to, in conjunction with, or instead of the embodiments described with respect to a corresponding like-named component in another figure.
[0008] In this application, the elements of the figures may be labeled A through N. As used herein, the foregoing notation means that the element may include any number of elements and does not require that the element include the same number of elements as any other element labeled A through N. For example, a data structure may include a first element labeled A and a second element labeled N. This notation convention means that the data structure may include any number of elements. A second data structure, also labeled A through N, may also include any number of elements. The number of elements of the first data structure and the number of elements of the second data structure may be the same or different.
[0009] In general, embodiments of the invention relate to methods, systems, and / or non-transitory computer-readable media for storing and updating device configuration in a virtualized environment.
[0010] Most virtual machine devices can utilize the Peripheral Component Interconnect Express (PCIe) pass-through feature to maximize performance from the guest OS device running compute-implemented services. For example, nonvolatile memory express (NVMe) storage devices assigned as a pass-through device can be a common use case for latency / performance-intensive applications. Initial VM device configuration and in-field device replacement / maintenance for hot-pluggable PCIe pass-through devices can both be extremely cumbersome. In such scenarios, specific tasks may be required, such as safely removing the device and reconfiguring the newly added device to the VM / container.These tasks can consume administrator cycles and also increase downtime in data center / cloud / edge use cases. Deploying and reconfiguring passthrough devices can also be considered a use case when redeploying the operating system (OS) or hypervisor on on-premises bare-metal servers. Currently, no automated mechanisms are available to automatically reconfigure PCIe passthrough devices on corresponding VMs.
[0011] To at least partially address the aforementioned problems and those discussed above, the embodiments disclosed herein relate to systems, methods, and / or non-transitory computer-readable media that establish an allocation between the PCIe device slot and the VM / container ID in the factory and during runtime, store the configuration information in tables, and then provide the allocation data to the OS so that PCIe pass-through reconfiguration is automated.
[0012] Fig. 1A shows a diagram of a system according to one or more embodiments disclosed herein. The system may include one or more clients (100) and a production host (110). Fig. 1A may be operatively connected to each other and / or to other units (not shown) via any combination of wired (e.g., Ethernet) and / or wireless networks (e.g., local area network, wide area network, Internet, etc.) without departing from the embodiments disclosed herein. Each component of the system illustrated in Fig. The system illustrated in Figure 1A is discussed below.
[0013] In one or more embodiments, the production host (110) may be implemented using one or more computing devices. A computing device may be, for example, a mobile phone, a tablet computer, a laptop computer, a desktop computer, a server, a distributed computing system, or a cloud resource. The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., hard disk drives, solid-state drives, etc.). The persistent storage may store computer instructions, e.g., computer code, that (when executed by the processor(s) of the computing device) cause the computing device to perform the functions of the production host (110) as described herein and / or all or part of the Fig. 2-3B. The production host (110) may be implemented using other types of computing devices without departing from the embodiments disclosed herein. For further details regarding the computing devices, see Fig. 4.
[0014] The production host (110) may be implemented using logical devices without departing from the embodiments disclosed herein. For example, the production host (110) may include virtual machines that utilize computing resources of any number of physical computing devices to provide the functionality of the production host (110). The production host (110) may be implemented using other types of logical devices without departing from the embodiments disclosed herein.
[0015] In one or more embodiments, the production host (110) may include, or be otherwise programmed or configured to include, functionality for performing computer-implemented services for one or more clients (100) and users of the production host (110). In one or more embodiments, the client(s) (100) may be implemented as one or more computing devices as discussed above. The computer-implemented services may include email communication services, database services, calendar services, inference services, and / or word processing services. The computer-implemented services may include other and / or additional types of services without departing from the embodiments disclosed herein.To perform the computer-implemented services for the client(s) (100), the production host (110) may further include the functionality to send / receive data, requests, and / or other information to / from the client(s) (100). The production host (110) may include the functionality to execute all or part of the functions described in . Fig. 2-3B. The production host (110) may include other and / or additional functionality without departing from the embodiments disclosed herein.
[0016] As discussed above, the production host (110) may include the functionality to perform computer-implemented services. To perform the above-mentioned computer-implemented services, the production host may include virtual machines (112), an operating system (OS) (114), an OS agent (116), a hypervisor (118), a host controller (120), memory (122), and component slots (124). The production host (110) may include other, additional, and / or fewer components without departing from the embodiments disclosed herein. Each of the above-mentioned components of the production host (110) is discussed below.
[0017] In one or more embodiments disclosed herein, the virtual machines (112) are implemented as computer instructions, e.g., computer code, stored on a memory (e.g., 122) that, when executed by a processor of the production host (110), causes the production host (110) to provide the functionality of the virtual machines (112) described in this detailed description. The virtual machines may include the functionality to perform or otherwise provide at least a portion of the computer-implemented services to the client(s) and / or user. The virtual machines may include other and / or additional functionality without departing from the embodiments disclosed herein. The virtual machines (VMs) (112) may include any number of virtual machines. For example, the VMs (112) may include VM A (112A) and VM N (112N). Additionally, each VM (e.g.,112A, 112N) contain one or more guest OSs (not in . Fig. 1A) associated with the corresponding VM. VM functions; scheduling tasks; mediating interactivity between logical (e.g., software) and physical (e.g., hardware). For example, each guest OS may support basic components of the production host (110) (e.g., 126A, 126N) using the component allocation table, allocate resources of the production host (110), and execute or invoke other computer programs or computer instructions executing on the production host (110) associated with the corresponding VM. One of ordinary skill in the art will recognize that the guest OS may perform other functionalities without departing from the scope of the embodiments disclosed herein.
[0018] In one or more embodiments disclosed herein, an operating system (OS) (114) is implemented as computer instructions, e.g., computer code, stored on a memory (e.g., 122) that, when executed by a processor of the production host (110), causes the production host (110) to provide the functionality of the OS (114) described in this detailed description.
[0019] In one or more embodiments disclosed herein, the OS (114) may be designed and configured to oversee the operations of the production host (110). To this extent, the OS (114) may include functionality to, for example, support basic functions of the production host (110); schedule tasks; mediate interactivity between logical (e.g., software) (e.g., VMs (112)) and physical (e.g., hardware) components of the production host (110) (e.g., 126A, 126N) using the component allocation table; allocate resources of the production host (110); and execute or invoke other computer programs or computer instructions executing on the production host (110). The OS (114) may include functionality to perform all or part of the methods of the Fig. 2-3B. One of ordinary skill in the art will recognize that the OS (114) may perform other functionalities without departing from the scope of the embodiments disclosed herein. One or more OSs may be included in the production host (110) without departing from the embodiments disclosed herein.
[0020] In one or more embodiments disclosed herein, the operating system (OS) agent (116) may be implemented as computer instructions, e.g., computer code, stored on memory (e.g., 122) that, when executed by a processor of the production host (110), causes the production host (110) to provide the functionality of the OS agent (116) described in this detailed description. The OS agent (116) may be a software component of the OS (114).
[0021] In one or more embodiments disclosed herein, the OS agent (116) may include the functionality to perform component table allocation services. The component table allocation services may include generating and updating or initiating the generation and updating of the component allocation table based on configuration information. The component table allocation services may further include distributing or making the component allocation table available to the OS (114), the hypervisor (118), and / or the VMs (112). The component allocation table services may include other and / or additional services associated with the component allocation table (discussed below) without departing from the embodiments disclosed herein. The OS agent (116) may further include the functionality to perform all or part of the methods of Fig. 2-3B. The OS agent (116) may include other and / or additional functionality without departing from the embodiments disclosed herein. There may be one or more OS agents (116), each associated with one or more OSs (114), hypervisors (118), and / or VMs (112), without departing from the embodiments disclosed herein.
[0022] In one or more embodiments disclosed herein, the hypervisor (118) may be implemented as computer instructions, e.g., computer code, stored on a memory (e.g., 122) that, when executed by a processor of the production host (110), causes the production host (110) to provide the functionality of the hypervisor (118) described in this detailed description.
[0023] In one or more embodiments disclosed herein, the hypervisor (118) may be implemented as a physical device. The physical device may include circuitry. The physical device may be, for example, a field-programmable gate array, an application-specific integrated circuit, a programmable processor, a microcontroller, a digital signal processor, or another hardware processor. The physical device may be configured to provide the functionality of the hypervisor (118) described in this detailed description.
[0024] In one or more embodiments disclosed herein, the hypervisor (118) may include the functionality to manage one or more of the VMs (112). The hypervisor (118) may generate, update, and facilitate the communication of information and data between VMs (e.g., 112A, 112N) and between one or more VMs (112) and components (e.g., 116, 118, 120, 122, 124, 126A, 126N) of the production host (110). The hypervisor (118) may include the functionality to implement all or part of the methods of the Fig. 2-3B. The hypervisor (118) may include other and / or additional functionalities without departing from the embodiments disclosed herein. In one or more embodiments disclosed herein, there may be a single hypervisor (118) associated with all VMs (112). In alternative embodiments, although not Fig. 1A, there may be multiple hypervisors (118), each associated with one or more of the VMs (112).
[0025] In one or more embodiments disclosed herein, the host controller (120) may be implemented as computer instructions, e.g., computer code, stored on a memory (e.g., 122) that, when executed by a processor of the production host (110), causes the production host (110) to provide the functionality of the host controller (120) described in this detailed description.
[0026] In one or more embodiments disclosed herein, the host controller (120) may be implemented as a physical device. The physical device may include circuitry. The physical device may be, for example, a field-programmable gate array, an application-specific integrated circuit, a programmable processor, a microprocessor, a microcontroller, a digital signal processor, a system-on-a-chip (SoC), or one or more other hardware processors. The physical device may be configured to provide the functionality of the host controller (120) described in this detailed description.
[0027] In one or more embodiments disclosed herein, the host controller (120) may include the functionality to perform production host management services. The production host management services may include: (i) monitoring component slots (124), VMs (112), the OS (114), or other components of the production host not included in Fig. 1A, using sensors (e.g., temperature sensors, fan speed sensors, voltage sensors, etc.) and / or monitoring services to identify changes, (ii) generating and / or obtaining log information associated with the aforementioned changes, (iii) generating or obtaining configuration information (discussed below) associated with the component slots (124) and VMs (112) from the hypervisor (118), OS (114), and / or a user, and / or (iv) performing booting or shutting down of the production host (110). The production host management services may include performing out-of-band management. In other words, the host controller (120) may control access and management (e.g., by the host controller (120) itself and / or users (e.g.,System administrators)) to devices, components, and / or other infrastructure associated with the production host (110) at remote locations via a separate management network or management plane from the production network or plane. Accordingly, a system administrator can monitor and manage the production host (110) regardless of whether the production host is powered on or the OS is operational. The host controller (120) can communicate with a user via any suitable out-of-band network connection (e.g., an out-of-band LAN) without departing from the embodiments disclosed herein. The host controller (120) can communicate with a user using a user interface (e.g., a graphical user interface (GUI), a command-line interface, a web interface, etc.) and any suitable communications specification or protocol (e.g., Intelligent Platform Management Interface (IPMI)) without departing from the embodiments disclosed herein. The production host management services may include other and / or additional services associated with the production host (110) without departing from the embodiments disclosed herein. The host controller (120) may further include the functionality to perform all or a portion of the methods of the . Fig. 2-3B. The host controller (120) may include other and / or additional functionalities without departing from the embodiments disclosed herein.
[0028] In one or more embodiments disclosed herein, the memory (122) may be implemented using one or more volatile or non-volatile memories, or any combination thereof. The memory (122) may include the functionality to store and provide all or portions of the information that may be used by the production host (110) or components thereof (e.g., 112A, 112N, 114, 116, 118, 120, 126A, 126N), or may be otherwise configured to do so. The information stored in the memory (122) may include one or more data structures that include a component allocation table. The memory (122) may include other and / or additional information without departing from the embodiments disclosed herein. For additional information regarding the memory (122) and the component allocation table (130, Fig. 1B) see Fig. 1B.
[0029] While the above data structures (e.g., 130) and other data structures mentioned in this Detailed Description are illustrated / discussed as separate data structures and have been discussed as containing a limited amount of specific information, each of the above data structures may be divided into any number of data structures, combined with any number of other data structures, and contain additional, less, and / or different information without departing from the embodiments disclosed herein. Furthermore, each of the aforementioned data structures, although illustrated as being stored in memory (122), may be stored in other locations (e.g., in the memory of other computing devices) and / or distributed across any number of computing devices without departing from the embodiments disclosed herein.The data structures discussed in this Detailed Description can be implemented using, for example, file systems, lists, linked lists, tables, unstructured data, databases, etc.
[0030] In one or more embodiments disclosed herein, the component slots (124) may be implemented as one or more physical interface connections that operatively connect removable components (e.g., 126A, 126N) to the production host (110). Components (e.g., 126A, 126N) may be added to, removed from, and / or replaced with the corresponding component slots (124) over time. There may be any number of component slots (124) without departing from the embodiments disclosed herein. The component slots (124) may connect the components (e.g., 126A, 126N) to the production host (110) using any suitable expansion bus communication standard (e.g.,Peripheral Component Interconnect-Express (PCIe), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect eXtended (PCI-X), Accelerated Graphics Port (AGP), etc.) to enable the transfer of data between the production host (110) (or components thereof such as the VMs (112)) and the components (126A, 126N) without departing from the embodiments disclosed herein. The component slots (124) may be implemented using any software (e.g., computer instructions), cables, physical connectors, wires, circuitry, and / or any other components necessary to operatively connect the components (126A, 126N) to the production host (110) without departing from the embodiments disclosed herein.
[0031] In one or more embodiments, the components (126A, 126N) may include the following hardware components: graphics cards, audio cards, host bus adapters for hard disk drives, solid-state drives (SSDs) (e.g., Non-Volatile Memory Express (NVMe) drives), and / or network interface controllers (NICs). There may be any number of components (126A, 126N) without departing from the embodiments disclosed herein. The components (126A, 126N) may include other and / or additional types of hardware components without departing from the embodiments disclosed herein. The components (126A, 126N) may be used by the production host (110) and / or the VMs (112) to perform all or part of the computer-implemented services.For example, a NIC may perform network services of the computer-implemented services, a graphics card may perform graphics processing services of the computer-implemented services, an SSD may perform data storage services of the computer-implemented services, etc. The components (126A, 126N) may include other and / or additional functionality without departing from the embodiments disclosed herein.
[0032] Although the system of Fig. 1A with a certain number of components (e.g., 100, 110, etc.), in other embodiments disclosed herein, the system may include more or fewer components. For example, the functionality of each of the components described above may be divided among multiple components or combined into a single component. Furthermore, each component may be used multiple times to perform an iterative operation. Furthermore, there may be multiple components of each type (e.g., 112, 112A, 112N, 114, 116, 118, 120, 122, 124, 126A, 126N) of the production host (110).
[0033] Fig. 1B shows a diagram of a memory according to one or more embodiments disclosed herein. The memory (122) may be an embodiment of the memory (122, Fig. 1A). As discussed above, the memory (122) may store a component mapping table (CMT) (130). The CMT may be used to assign the removable components (e.g., 126A, 126N, Fig. 1A) to the VMs (112, Fig. 1A) running on the production host (110, Fig. 1A). In other words, the CMT (130) may provide the hypervisor (118), OS (114), and / or the VMs (112) with the necessary CMT information to enable the VMs (112) to use components allocated to the VMs. The CMT (130) may be implemented using any suitable type of table data structure without departing from the embodiments disclosed herein.
[0034] As discussed above, the CMT (130) contains CMT information. The CMT information may include entries (e.g., in Fig. 1B) associated with components. Any number of entries may be associated with currently connected components or previously connected components (e.g., historical entries). Each entry may include a component slot identifier (140), bus device function (BDF) information (150), a component type (160), an allocated VM identifier (170), and a configuration status (180). The CMT information may include other and / or additional information associated with the components without departing from the embodiments disclosed herein. Each of the above components of the CMT information is discussed below.
[0035] In one or more embodiments, a component slot identifier (140) may specify a particular component slot associated with a component. The component slot identifier (140) may specify the component slot to which a component is currently connected or was previously connected if not currently connected. Each component slot may be associated with a different component slot identifier. For example, a first component slot may be associated with component slot identifier A (142), a second component slot may be associated with component slot identifier B (144), a third component slot may be associated with component slot identifier C (146), and an Nth component slot may be associated with component slot identifier N (148).There may be any number of component slots and thus any number of component slot identifiers without departing from the embodiments disclosed herein. A component slot identifier (140) may be empty or set to a default value to indicate that the component associated with the entry has been removed and / or that the entry is a historical entry. A component slot identifier (140) may include other and / or additional information without departing from the embodiments disclosed herein.
[0036] In one or more embodiments disclosed herein, the BDF information specifies a bus number, a device number, and a function number associated with the component corresponding to the entry. In one or more embodiments, a bus number specifies the switch to which the component is connected and enables communication to be routed to the correct switch corresponding to the component. In one or more embodiments, the device number is used to identify the specific component within the switch to enable selection of the component by entities (e.g., VMs (112)) that wish to use the component.In one or more embodiments, the function number specifies one or more specific functions or capabilities associated with a component to enable users of the component to select the desired function. The BDF information enables the production host (110) or a VM to use the component corresponding to the BDF information. Each component in a component slot may be associated with BDF information. For example, a first component slot may be associated with a component having BDF A (152), a second component slot may be associated with a component having BDF B (154), a third component slot may be associated with a component having BDF C (156), and an Nth component slot may be associated with a component having BDF N (158).The BDF information (150) may include other and / or additional information associated with components without departing from the embodiments disclosed herein.
[0037] In one or more embodiments, the component type (160) may specify the type of hardware component corresponding to the component. The component type (140) may include a tag, identifier, label, or other indicator of the type of hardware component. The component type (160) may specify whether the corresponding component is, for example, a graphics card, an audio card, a hard disk drive host bus adapter, a solid state drive (SSD) (e.g., Non-Volatile Memory Express (NVMe) drives), and / or a NIC. The component type (160) may include additional information such as a vendor associated with the corresponding component, a version number associated with the corresponding component, a component identifier or product number, etc., without departing from the embodiments disclosed herein.The component type may further specify whether the corresponding component is a physical component or a virtual component (e.g., a single root I / O virtualization (SR-IOV) device) generated using at least a portion of a physical component. In one or more embodiments, each component or entry may be associated with a component type. For example, a first component slot may be associated with a component of component type A (162), a second component slot may be associated with a component of component type B (164), a third component slot may be associated with a component of component type C (166), and an Nth component slot may be associated with a component of component type N (168).The component type (160) may include other and / or additional information associated with components without departing from the embodiments disclosed herein.
[0038] In one or more embodiments, an allocated VM identifier (170) may specify a particular VM (e.g., 112A) among the VMs (112) to which a corresponding component is allocated. In other words, the allocated VM identifier (170) may specify the VM that uses the component associated with the entry. Each component or entry may be associated with an allocated VM identifier. For example, a first component slot may be associated with a component assigned to VM identifier A (172), a second component slot may be associated with a component assigned to VM identifier B (174), a third component slot may be associated with a component assigned to VM identifier C (176), and an Nth component slot may be associated with a component assigned to VM identifier N (178).There may be any number of component slots, components, and VMs, and thus any number of allocated VM identifiers, without departing from the embodiments disclosed herein. An allocated VM identifier (170) may be empty or set to a default value to indicate that the component associated with the entry is not currently allocated to a VM. An allocated VM identifier (170) may include other and / or additional information without departing from the embodiments disclosed herein.
[0039] In one or more embodiments, the configuration status (180) may specify the status of a component associated with the entry. The configuration status (180) may include a tag, identifier, label, or other indicator of the status of the component. The configuration status (180) may specify, for example, whether the corresponding component is active (e.g., ready for use and / or currently in use by a VM), inactive (not ready for use and / or not currently in use by a VM), powered off (e.g., the component does not include power), connected, removed, removed from an allocated VM, and / or has another status associated with the component. The configuration status (180) may be associated with a timestamp (e.g., a time corresponding to the status change to the current status). Each component or entry may be associated with a configuration status.For example, a first component slot may be associated with a component having status A (182), a second component slot may be associated with a component having status B (184), a third component slot may be associated with a component having status C (186), and an Nth component slot may be associated with a component having status N (188). The configuration status may include other and / or additional information associated with the status of a component without departing from the embodiments disclosed herein.
[0040] Fig. 2 shows a flowchart of a method for generating an initial component allocation table according to one or more embodiments disclosed herein. Fig. 2 can be implemented, for example, by a production host (e.g., 110, Fig. 1A). Other components of the system in Fig. 1A-1B can complete the entire process from Fig. 2 or any part thereof without departing from the scope of the embodiments described herein. Although Fig. 2 is illustrated as a series of steps, any steps may be omitted, performed in a different order, additional steps may be included, and / or any or all steps may be performed in a parallel and / or partially overlapping manner without departing from the scope of the embodiments described herein.
[0041] First, in step 200, the production host performs an initial power-up. In one or more embodiments, the production host may be shipped to the manufacturer and deployed in an environment (e.g., edge environment, data center, cloud environment, etc.). The host controller of the production host, when connected to power and powered on (e.g., through an input such as a user or administrator pressing a button), may perform a power-up by loading computer instructions into memory and executing them or by initiating execution of the computer instructions by one or more processors of the production host. The production host may perform the initial power-up via other and / or additional methods without departing from the embodiments disclosed herein.
[0042] In step 202, an initial CMT associated with the production host is generated. In one or more embodiments, the OS agent of the production host generates an initial CMT using initial configuration information. The initial configuration information may be stored on the memory of the production host prior to initial power-up in step 200 by the manufacturer or a user. The initial configuration information may be one or more data structures including the component slot identifiers associated with the component slots on the production host. The OS agent may generate an initial CMT with an entry associated with each component slot identifier included in the initial configuration information. The OS agent may use other portions of the entries (e.g.,Component BDF information, component type, allocated VM identifier, and configuration state) can be left blank or set to initial values / parameters. The OS agent can generate the initial CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, Representational State Transfer (REST) API calls, etc.) with the initial configuration information to the host controller or another entity (e.g., service, server, processor, etc.) not specified in . Fig. 1A and is capable of generating the CMT.
[0043] In alternative embodiments, an initial CMT associated with the production host may be manually generated by a user (e.g., a system administrator) and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with configuration information including the initial configuration information for generating the initial CMT. Alternatively, the user may generate the initial CMT via the user interface and provide it directly. The initial CMT may include an entry associated with each component slot identifier included in the initial configuration information.The initial CMT can contain empty or set initial values / parameters for the other parts of the entries (e.g., component BDF information, component type, allocated VM identifier, and configuration status).
[0044] In yet further alternative embodiments disclosed herein, the host controller directly generates the initial CMT using the initial configuration information. As discussed above, the initial configuration information may be stored in the memory of the production host and retrieved from the memory by the host controller, or the initial configuration information may be provided to the host controller by a user via the user interface associated with the host controller and the user.In one or more embodiments, the host controller may generate the initial CMT using a Device-Specific Method (DSM) method defined in the Basic Input / Output System (BIOS) and the initial configuration information to generate and update the initial CMT as an Advanced Configuration and Power Interface (ACPI) table. An ACPI table may refer to a table data structure of an ACPI-based system. BIOS may be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host.The VMs, hypervisor, OS, and / or OS agent may access the CMT, make requests (e.g., API calls), trigger a system management mode (SMM) (e.g., an operating mode used to suspend normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller. The _DSM method may refer to a user-defined function, process, or routine contained in BIOS to generate, update, maintain, and enable access to the CMT, or to provide CMT information from the CMT.
[0045] The initial CMT associated with the production host may be generated via other and / or additional methods without departing from the embodiments disclosed herein.
[0046] In step 204, the configuration information associated with the production host is obtained. As discussed above, the memory of the production host may include initial configuration information. In one or more embodiments, the initial configuration information may include configuration information. As discussed above, in some embodiments, the user may provide the configuration information to the host controller. The OS agent or host controller may analyze the initial configuration information to obtain the configuration information. The configuration information associated with the production host may be obtained via other and / or additional methods without departing from the embodiments disclosed herein.
[0047] In step 206, a determination is made as to whether the production host is associated with a default configuration. The host controller may analyze the configuration information to determine whether the production host is associated with a default configuration. As discussed above, the configuration information may be one or more data structures specifying the component slot identifiers associated with the production host. The configuration information may further specify a default configuration. In one or more embodiments, a default configuration may refer to a common or specified initial configuration of components pre-attached to the component slots by a manufacturer or a user and automatically assigned to specific VMs of the production host.There may be one or more different types of default configurations, each with different components installed in different component slots. In one or more embodiments disclosed herein, if the configuration information includes a default configuration, the host controller may determine that the production host is associated with a default configuration. In one or more embodiments disclosed herein, if the configuration information does not include a default configuration, the host controller may determine that the production host is not associated with a default configuration. Determining whether the production host is associated with a default configuration may be performed via other and / or additional methods without departing from the embodiments disclosed herein.
[0048] In one or more embodiments disclosed herein, if it is determined that the production host is associated with a default configuration, the method proceeds to step 208. In one or more embodiments disclosed herein, if it is determined that the production host is not associated with a default configuration, the method proceeds to step 210.
[0049] In step 208, the CMT is updated based on the default configuration. In one or more embodiments, the production host's OS agent updates the CMT using the default configuration specified by the configuration information. The default configuration may specify initial BDF information, component types, allocated VM identifiers, and configuration states associated with each of the component slot identifiers. The OS agent may update the entry associated with each component slot identifier with the CMT information associated with the component slot identifier included in the default configuration. The OS agent may update the initial CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, representative state transfer (REST) API calls, etc.).) with the CMT information included in the default configuration to the host controller or another entity (e.g., service, server, processor, etc.) not included in . Fig. 1A and is capable of updating the CMT.
[0050] In alternative embodiments, an initial CMT associated with the production host may be manually updated by a user (e.g., a system administrator) and deployed to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the default configuration (see steps 210-212), which includes the CMT information, to update the initial CMT, and the host controller may update the CMT as discussed below. Alternatively, the user may update and deploy the updated CMT directly via the user interface.The updated CMT may include initial BDF information, component types, allocated VM identifiers, and configuration status associated with each of the component slot identifiers in each entry, as specified by the default configuration.
[0051] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the default configuration. As discussed above, the default configuration may specify initial BDF information, component types, allocated VM identifiers, and configuration status associated with each of the component slot identifiers. In one or more embodiments, the host controller may update the initial CMT using the _DSM method defined in BIOS and the default configuration to update the initial CMT.
[0052] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The _DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0053] The CMT may be updated based on the default configuration via other and / or additional methods without departing from the embodiments disclosed herein.
[0054] In step 210, user configuration information is requested from a user. In one or more embodiments, the host controller may send a message or prompt a user to provide user configuration information via a user interface (e.g., a graphical user interface, a command-line interface, a web interface, etc.) over an out-of-band network connection to the user. The message or prompt may include a request to enter CMT information associated with a component configuration configured by the user (e.g., a non-default configuration). User configuration information may be requested from a user via other and / or additional methods without departing from the embodiments disclosed herein.
[0055] In step 212, user configuration information is obtained from the user. In one or more embodiments, in response to the prompt, a user may enter CMT information associated with the production host via the user interface (e.g., by checking boxes, selecting options, and / or entering information via a keyboard, touch screen, mouse, etc.). The host controller may obtain and / or extract the CMT information from the user interface. User configuration information may be obtained from the user via other and / or additional methods without departing from the embodiments disclosed herein.
[0056] In step 214, the CMT is updated based on the user configuration information. In one or more embodiments, the production host's OS agent updates the CMT using the user configuration information. The default configuration may specify initial BDF information, component types, allocated VM identifiers, and configuration status associated with each of the component slot identifiers. The OS agent may update the entry associated with each component slot identifier with the CMT information associated with the component slot identifier included in the user configuration information. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.).) with the CMT information contained in the user configuration information to the host controller or another entity (e.g., service, server, processor, etc.) not contained in . Fig. 1A and is capable of updating the CMT.
[0057] In alternative embodiments, an initial CMT associated with the production host may be manually updated by a user (e.g., a system administrator) and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with a user configuration (see steps 210-212) including the CMT information to update the initial CMT, and the host controller may update the CMT as discussed below. Alternatively, the user may update and provide the updated CMT based on the user configuration directly via the user interface.The updated CMT may include initial BDF information, component types, allocated VM identifiers, and configuration status associated with each of the component slot identifiers in each entry, as specified by the user configuration.
[0058] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the user configuration. As discussed above, the user configuration may specify initial BDF information, component types, allocated VM identifiers, and configuration status associated with each of the component slot identifiers. In one or more embodiments, the host controller may update the initial CMT using the _DSM method defined in BIOS and the user configuration to update the initial CMT.
[0059] BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), trigger a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The _DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0060] The CMT may be updated based on user configuration via other and / or additional methods without departing from the embodiments disclosed herein.
[0061] In step 216, component allocation is provided to the operating system based on the CMT. In one or more embodiments, the OS agent may provide all or part of the CMT information contained in the current CMT to the OS of the production host. The OS may also distribute the CMT information to the respective VMs and hypervisor(s) of the production host. The OS, the VMs, and the hypervisor(s) may then use the CMT information from the CMT to propagate the current configuration of the production host's components to the allocated VMs. Thus, the CMT information from the CMT may enable the VMs to use the allocated components to perform computer-implemented services.In alternative embodiments disclosed herein, the host controller may notify the VMs, hypervisor, OS, and / or OS agent that the CMT is being updated and / or make the _DSM method available to the VMs, hypervisor, OS, and / or OS agent. As a result, the VMs, hypervisor, OS, and / or OS agent may access the CMT, make requests (e.g., API calls), trigger a system management mode (SMM) (e.g., an operational mode used to suspend normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is included or otherwise managed via BIOS using the _DSM method by the host controller. The CMT may be updated via the method of . Fig. 3A-3B may be automatically updated when components or VMs are added, removed, or reconfigured. Component allocation may be provided to the operating system based on the CMT via other and / or additional methods without departing from the embodiments disclosed herein.
[0062] In one or more embodiments disclosed herein, the method ends after step 216. The method of Fig. 2 may be performed prior to deployment of the production host during the manufacturing process of production without departing from the embodiments disclosed herein.
[0063] Fig. 3A-3B show a flowchart of a method for updating a component allocation table according to one or more embodiments disclosed herein. Fig. 3A-3B may be implemented, for example, by a production host (e.g., 110, Fig. 1A). Other components of the system in Fig. 1A-1B can complete the entire process from Fig. 3A-3B or any part thereof without departing from the scope of the embodiments described herein. Although Fig. 3A-3B is illustrated as a series of steps, any steps may be omitted, performed in a different order, additional steps may be included, and / or any or all steps may be performed in a parallel and / or partially overlapping manner without departing from the scope of the embodiments described herein.
[0064] First, Fig. 3A, a change event is identified in step 300. In one or more embodiments, the host controller or another entity (e.g., a hardware monitor) may notify the OS agent when a component is changed. The notification may include log information associated with the change. A component change may include adding a component to a component slot or removing a component from a component slot. Similarly, the hypervisor or host controller may notify the OS agent when a VM is changed. The notification may include log information. A VM change may include adding a VM, removing a VM, or reconfiguring components associated with a VM.The OS agent may identify notifications received from the host controller and / or hypervisor associated with a component change or a VM change as a change event. The change event may be identified via other and / or additional methods without departing from the embodiments disclosed herein.
[0065] In step 302, a determination is made as to whether the change event is associated with a component change event. In one or more embodiments disclosed herein, the OS agent may review the log information associated with the change event included in the notification corresponding to the change event. The log information may be one or more data structures that specify whether the change was associated with a VM or a component. In one or more embodiments disclosed herein, if the log information specifies that the change event is associated with a component, the OS agent may determine that the change event is a component change event.In one or more embodiments disclosed herein, if the log information specifies that the change event is associated with a VM, the OS agent may determine that the change event is not a component change event. Determining whether the change event is associated with a component change event may be performed via other and / or additional methods without departing from the embodiments disclosed herein.
[0066] In one or more embodiments disclosed herein, if it is determined that the change event is a component change event, the method continues with step 304. In one or more embodiments disclosed herein, the method continues with step 318 of Fig. 3B if it is determined that the change event is not a component change event.
[0067] In step 304, a determination is made as to whether the component change event is associated with an added component. The log information associated with the component change event may specify whether a component was added to or removed from a component slot. In one or more embodiments, the OS agent may analyze the log information to determine whether the change event is associated with a component addition or a component removal. In one or more embodiments disclosed herein, if the log information specifies that the change event is associated with an added component, the OS agent may determine that a component was added.In one or more embodiments disclosed herein, if the log information specifies that the change event is associated with a component removal, the OS agent may determine that a component was not added (component was removed). Determining whether the change event is associated with an added component may be performed via other and / or additional methods without departing from the embodiments disclosed herein.
[0068] In one or more embodiments disclosed herein, if it is determined that the change event is associated with an added component, the method continues with step 306. In one or more embodiments disclosed herein, if it is determined that the change event is not associated with an added component (it is associated with a removed component), the method continues with step 310.
[0069] In step 306, a determination is made as to whether the added component is a previous component. In one or more embodiments, the component may be a component that was previously removed from a component slot. The OS agent may compare a component identifier included in the log information with component identifiers included in the entries of the CMT. In one or more embodiments disclosed herein, if the component identifier included in the log information matches a component identifier included in the CMT, the OS agent may determine that the component is a previous component.In one or more embodiments disclosed herein, if the component identifier included in the log information does not match a component identifier included in the CMT, the OS agent may determine that the component is not a previous component (e.g., the component is a new component). Determining whether the added component is a previous component may be performed via other and / or additional methods without departing from the embodiments disclosed herein.
[0070] In one or more embodiments disclosed herein, if it is determined that the added component is a previous component, the method continues with step 308. In one or more embodiments disclosed herein, if it is determined that the added component is not a previous component, the method continues with step 312.
[0071] In step 308, the CMT is updated to indicate that a previous component has been added. In one or more embodiments, the production host's OS agent updates the CMT using the log information. The OS agent may update the configuration status and, if installed in a new component slot, the component slot identifier included in the entry associated with the previous component. The log information may specify the component slot identifier and configuration status associated with the added component.Additionally, if the component is allocated to a new VM as specified by the log information, the OS agent may then update the allocated VM identifier associated with the entry corresponding to the component using the allocated component identifier included in the log information. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.) with the CMT information included in the log information discussed above to the host controller or other entity (e.g., service, server, processor, etc.) not specified in . Fig. 1A and is capable of updating the CMT.
[0072] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) based on the addition of a previous component and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the protocol information (e.g., similar to the methods discussed above; see steps 210-212) including the CMT information to update the CMT, and the host controller may update the CMT as discussed below.Alternatively, the user can update and deploy the updated CMT based on the addition of the previous component directly through the user interface. The updated CMT may include the component slot identifier and configuration state associated with the added component. Additionally, if the component is allocated to a new VM, as specified by the log information, the updated CMT may include the updated allocated VM identifier associated with the entry.
[0073] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the log information. The host controller may update the configuration status and, if installed in a new component slot, the component slot identifier included in the entry associated with the previous component. As discussed above, the log information may specify the component slot identifier and the configuration status associated with the added component. Additionally, if the component is allocated to a new VM, as specified by the log information, the host controller may then update the allocated VM identifier associated with the entry corresponding to the component using the allocated component identifier included in the log information.In one or more embodiments, the host controller may update the CMT using the _DSM method and protocol information defined in BIOS.
[0074] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The _DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0075] The CMT may be updated to indicate that a previous component was added via different and / or additional methods without departing from the embodiments disclosed herein.
[0076] In one or more embodiments disclosed herein, the method continues after step 308 with step 316.
[0077] In a step 310, the CMT is updated to indicate that the component has been removed. In one or more embodiments, the production host's OS agent updates the CMT using the log information. The OS agent may update the configuration status and component slot identifier included in the entry associated with the removed component to indicate that the component has been removed. The log information may specify the component slot identifier and configuration status associated with the removed component. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.) with the CMT information included in the log information discussed above to the host controller or other entity (e.g., service, server, processor, etc.).) that are not in . Fig. 1A and is capable of updating the CMT.
[0078] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) based on the removal of the component and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the protocol information (e.g., similar to the methods discussed above. See steps 210-212) including the CMT information to update the CMT, and the host controller may update the CMT as discussed below. Alternatively, the user may update and provide the updated CMT based on the removal of the component directly via the user interface.The updated CMT may include the updated configuration state and component slot identifier included in the entry associated with the removed component to indicate that the component has been removed.
[0079] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the log information. The host controller may update the configuration status and component slot identifier included in the entry associated with the removed component to indicate that the component has been removed. The log information may specify the component slot identifier and configuration status associated with the removed component. In one or more embodiments, the host controller may update the CMT using the _DSM method defined in BIOS and the log information.
[0080] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The _DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0081] The CMT may be updated to indicate that a component was removed via different and / or additional methods without departing from the embodiments disclosed herein.
[0082] In one or more embodiments disclosed herein, the method continues after step 308 with step 316.
[0083] In step 312, the CMT is updated to indicate that a new component has been added. In one or more embodiments, the production host's OS agent updates the CMT using the log information. The OS agent may update the CMT by generating a new entry in the CMT associated with the new component. The OS agent may include the component slot identifier, BDF information, component type, allocated VM identifier, and configuration status included in the log information in the generated entry. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.) with the CMT information included in the log information discussed above to the host controller or other entity (e.g., service, server, processor, etc.).) that are not in . Fig. 1A and is capable of updating the CMT.
[0084] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) based on the addition of the new component and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the protocol information (e.g., similar to the methods discussed above; see steps 210-212) including the CMT information to update the CMT, and the host controller may update the CMT as discussed below.Alternatively, the user can update and deploy the updated CMT based on the addition of the new component directly through the UI. The updated CMT can include a new entry associated with the newly added component and the component slot identifier, BDF information, component type, allocated VM identifier, and configuration status associated with the newly added component in the generated entry.
[0085] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the log information. The host controller may update the configuration status and component slot identifier included in the entry associated with the removed component to indicate that the component has been removed. The log information may specify the component slot identifier and configuration status associated with the removed component. In one or more embodiments, the host controller may update the CMT using the _DSM method defined in BIOS and the log information.
[0086] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The _DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0087] The CMT may be updated to indicate that a new component has been added via different and / or additional methods without departing from the embodiments disclosed herein.
[0088] In step 316, the updated component allocation based on the CMT is provided to the OS. In one or more embodiments, the OS agent may provide all or part of the CMT information included in the updated CMT to the OS of the production host. The OS or OS agent may also distribute the CMT information to the respective VMs and hypervisor(s) of the production host. The OS, VMs, and hypervisor(s) may then use the CMT information from the CMT to propagate the current configuration of the components to the allocated VMs. Therefore, the CMT information from the CMT may be automatically updated, enabling the VMs to use the allocated components to perform computer-implemented services, even if components or VMs are reconfigured, recreated, added, or removed.In alternative embodiments disclosed herein, the host controller may notify the VMs, hypervisor, OS, and / or OS agent that the CMT is being updated and / or make the _DSM method available to the VMs, hypervisor, OS, and / or OS agent. As a result, the VMs, hypervisor, OS, and / or OS agent may access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operational mode used to suspend normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that may be included or otherwise managed via BIOS using the _DSM method by the host controller.The updated component allocation may be provided to the operating system based on the CMT via other and / or additional methods without departing from the embodiments disclosed herein.
[0089] In one or more embodiments disclosed herein, the method ends after step 316.
[0090] With a view to Fig. 3B, in step 318, a determination is made as to whether the VM change is associated with a VM reconfiguration. The log information associated with the VM change event may specify whether a VM was added (e.g., a VM was created), removed, or reconfigured (allocated to other components installed on the production host). In one or more embodiments, the OS agent may analyze the log information to determine whether the change event is associated with VM reconfiguration. In one or more embodiments disclosed herein, if the log information specifies that the change event is associated with a VM reconfiguration, the OS agent may determine that a VM was reconfigured.In one or more embodiments disclosed herein, if the log information specifies that the change event is not associated with a VM reconfiguration, the OS agent may determine that a VM has not been reconfigured. Determining whether the VM change is associated with a VM reconfiguration may be performed via other and / or additional methods without departing from the embodiments disclosed herein.
[0091] In one or more embodiments disclosed herein, the method continues with step 320 if it is determined that the VM change event is associated with a VM reconfiguration. In one or more embodiments disclosed herein, the method continues with step 322 if it is determined that the change event is not associated with a VM reconfiguration (it is associated with a removed or added VM).
[0092] In step 320, the CMT is updated based on the VM reconfiguration. In one or more embodiments, the OS agent of the production host updates the CMT using the log information. The log information may specify the VM identifier associated with the VM being reconfigured. The log information may further specify the component identifiers or component slot identifiers associated with components being reconfigured to be allocated to the VM corresponding to the VM identifier. The OS agent may update the allocated VM identifier for all entries associated with component identifiers and / or component slot identifiers specified by the log information. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.).) with the CMT information contained in the protocol information discussed above to the host controller or other entity (e.g., service, server, processor, etc.) not included in . Fig. 1A and is capable of updating the CMT.
[0093] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) and deployed to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide protocol information to the host controller (see steps 210-212) including the CMT information to update the initial CMT, and the host controller may update the CMT as discussed below. Alternatively, the user may update and deploy the updated CMT based on the VM reconfiguration directly via the user interface.The updated CMT may include updated allocated VM identifiers for all entries associated with component identifiers and / or component slot identifiers associated with the VM reconfiguration.
[0094] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the log information. The log information may specify the VM identifier associated with the VM being reconfigured. The log information may further specify the component identifiers or component slot identifiers associated with components being reconfigured to be allocated to the VM corresponding to the VM identifier. The host controller may update the allocated VM identifier for all entries associated with component identifiers and / or component slot identifiers specified by the log information.In one or more embodiments, the host controller may update the initial CMT using the _DSM method defined in BIOS and the user configuration to update the initial CMT.
[0095] BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), trigger a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The _DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0096] The CMT may be updated based on the VM reconfiguration via other and / or additional methods without departing from the embodiments disclosed herein.
[0097] In one or more embodiments disclosed herein, the method may continue after step 320 with step 316 in Fig. 3A can be continued.
[0098] In step 322, a determination is made as to whether the VM change is associated with an added VM. The log information associated with the VM change event may specify whether a VM was added, removed, or reconfigured (assigned to other components installed on the production host). In one or more embodiments, the OS agent may analyze the log information to determine whether the change event is associated with an added VM. In one or more embodiments disclosed herein, if the log information specifies that the change event is associated with an added VM, the OS agent may determine that a VM was added.In one or more embodiments disclosed herein, if the log information specifies that the change event is not associated with an added VM, the OS agent may determine that a VM was not added (a VM was removed). Determining whether the VM change is associated with an added VM may be performed via other and / or additional methods without departing from the embodiments disclosed herein.
[0099] In one or more embodiments disclosed herein, if it is determined that the VM change event is associated with an added VM, the method continues with step 324. In one or more embodiments disclosed herein, if it is determined that the change event is not associated with an added VM (if it is associated with a removed VM), the method continues with step 328.
[0100] In step 324, a determination is made as to whether the added VM is a previous VM. In one or more embodiments, the VM may be a VM that was previously removed from the production host. The OS agent may compare a VM identifier included in the log information with VM identifiers included in the CMT entries. In one or more embodiments disclosed herein, if the VM identifier included in the log information matches a VM identifier included in the CMT, the OS agent may determine that the VM is a previous component. In one or more embodiments disclosed herein, if the VM identifier included in the log information does not match a VM identifier included in the CMT, the OS agent may determine that the VM is not a previous component.The determination of whether the added VM is a previous VM may be made via other and / or additional methods without departing from the embodiments disclosed herein.
[0101] In one or more embodiments disclosed herein, if it is determined that the added VM is a previous VM, the method continues with step 326. In one or more embodiments disclosed herein, if it is determined that the added VM is not a previous VM, the method continues with step 330.
[0102] In step 326, the CMT is updated to indicate that a previous VM has been added. In one or more embodiments, the production host's OS agent updates the CMT using the log information. The OS agent may update the configuration status of all entries associated with the previous VM, from allocated VM removed to active. The log information may specify the VM identifier associated with the added VM. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.) with the CMT information included in the log information discussed above to the host controller or other entity (e.g., service, server, processor, etc.) not included in Fig. 1A and is capable of updating the CMT.
[0103] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) based on the addition or creation of a previous VM and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the protocol information (e.g., similar to the methods discussed above; see steps 210-212) including the CMT information to update the CMT, and the host controller may update the CMT as discussed below.Alternatively, the user can update and deploy the updated CMT based on the addition or creation of the previous VM directly through the user interface. The updated CMT may include the component slot identifier and configuration status associated with the added component. Additionally, if the component is allocated to a new VM, as specified by the log information, the updated CMT may include the updated allocated VM identifier associated with the entry.
[0104] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the log information. The host controller may update the configuration status of all entries associated with the previous VM, from allocated VM removed to active. The log information may specify the VM identifier associated with the added VM. In one or more embodiments, the host controller may update the CMT using the _DSM method defined in BIOS and the log information.
[0105] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0106] The CMT may be updated to indicate that a previous VM was added via different and / or additional methods without departing from the embodiments disclosed herein.
[0107] In one or more embodiments disclosed herein, the method continues after step 326 with step 316 of Fig. 3A continued.
[0108] In step 328, the CMT is updated to indicate that a VM has been removed. In one or more embodiments, the production host's OS agent updates the CMT using the log information. The OS agent may update the configuration status of each entry with the VM identifier associated with the removed VM to indicate that the allocated VM has been removed. The log information may specify the VM identifier associated with the removed VM. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.) with the CMT information included in the log information discussed above to the host controller or other entity (e.g., service, server, processor, etc.) not included in Fig. 1A and is capable of updating the CMT.
[0109] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) based on the VM's removal and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the protocol information (e.g., similar to the methods discussed above. See steps 210-212) including the CMT information to update the CMT, and the host controller may update the CMT as discussed below. Alternatively, the user may update and provide the updated CMT based on the VM's removal directly via the user interface.The updated CMT may include the updated configuration status in the entries associated with the removed VM to indicate that the allocated VM has been removed.
[0110] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the log information. The host controller may update the configuration status of each entry with the VM identifier associated with the removed VM to indicate that the allocated VM has been removed. The log information may specify the VM identifier associated with the removed VM. In one or more embodiments, the host controller may update the CMT using the _DSM method defined in BIOS and the log information.
[0111] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0112] The CMT may be updated to indicate that a VM was removed via different and / or additional methods without departing from the embodiments disclosed herein.
[0113] In one or more embodiments disclosed herein, the method continues after step 328 with step 316 of Fig. 3A continued.
[0114] In step 330, the CMT is updated to indicate that a new VM is being added. In one or more embodiments, the production host's OS agent updates the CMT using the log information. The OS agent may update the CMT by changing the allocated VM identifier from one or more entries associated with component slot identifiers or component identifiers specified by the log information associated with the newly added VM to the VM identifier associated with the new VM. The log information may specify the VM identifier associated with the newly added VM. The OS agent may update the CMT by making any suitable application programming interface (API) calls (e.g., Redfish API calls, REST API calls, etc.).) with the CMT information contained in the protocol information discussed above to the host controller or other entity (e.g., service, server, processor, etc.) not included in . Fig. 1A and is capable of updating the CMT.
[0115] In alternative embodiments, the CMT associated with the production host may be manually updated by a user (e.g., a system administrator) based on the addition (or creation) of the new VM and provided to the host controller via a user interface associated with the host controller and the user. As discussed above, the host controller may communicate directly with a user via any suitable type of user interface and an out-of-band network. The user may provide the host controller with the protocol information (e.g., similar to the methods discussed above; see steps 210-212) including the CMT information to update the CMT, and the host controller may update the CMT as discussed below.Alternatively, the user can update and deploy the updated CMT based on the addition or creation of the new VM directly through the UI. The updated CMT can include updated allocated VM identifiers, which include the VM identifier of the newly added or created VM for entries associated with components and / or component slots allocated to the newly added or created VM.
[0116] In yet further alternative embodiments disclosed herein, the host controller directly updates the initial CMT using the protocol information. The host controller may update the CMT by changing the allocated VM identifier from one or more entries associated with component slot identifiers or component identifiers specified by the protocol information associated with the newly added VM to the VM identifier associated with the new VM. The protocol information may specify the VM identifier associated with the newly added VM. In one or more embodiments, the host controller may update the CMT using the _DSM method defined in BIOS and the protocol information.
[0117] As discussed above, BIOS can be firmware (e.g., computer instructions) executed by the host controller or other processor(s) of the production host to provide hardware management (e.g., boot-up processes, hardware initialization, etc.) to the production host. The VMs, hypervisor, OS, and / or OS agent can access the CMT, make requests (e.g., API calls), initiate a system management mode (SMM) (e.g., an operating mode used to suspend the normal execution of the production host's processors to allow unhindered and uninterrupted access to the CMT), and / or obtain information (e.g., CMT information) from the CMT that is contained or otherwise managed via BIOS by the host controller.The DSM method may refer to a user-defined function, process, or routine included in BIOS to generate, update, maintain, and provide access to the CMT or to provide CMT information from the CMT.
[0118] The CMT may be updated to indicate that a new VM was added via different and / or additional methods without departing from the embodiments disclosed herein.
[0119] In one or more embodiments disclosed herein, the method continues after step 330 with step 316 of Fig. 3A continued.
[0120] In one or more alternative embodiments disclosed herein, steps 300-306, 318, and 322-324 may be performed by the host controller without departing from the embodiments disclosed herein.
[0121] As discussed above, embodiments of the invention may be implemented using computing devices. Fig.4 shows a diagram of a computing device according to one or more embodiments of the invention. The computing device (400) may include one or more computer processors (402), non-persistent memory (404) (e.g., volatile memory such as random access memory (RAM), cache memory), persistent memory (406) (e.g., a hard drive, an optical drive such as a compact disk (CD) or digital versatile disk (DVD) drive, flash memory, etc.), a communications interface (412) (e.g., a Bluetooth interface, an infrared interface, a network interface, an optical interface, etc.), input devices (410), output devices (408), and numerous other elements (not shown) and functions. Each of these components is described below.
[0122] In one embodiment of the invention, the computer processor(s) (402) may be an integrated circuit for processing instructions. The computer processor(s) may, for example, be one or more cores or micro-cores of a processor. The computing device (400) may also include one or more input devices (410), such as a touch screen, a keyboard, a mouse, a microphone, a touchpad, an electronic pen, or any other type of input device. Furthermore, the communication interface (412) may be an integrated circuit for connecting the computing device (400) to a network (not shown) (e.g.a local area network (LAN), a wide area network (WAN) such as the Internet, a mobile network, or any other type of network) and / or with another device, such as another computing device.
[0123] In one embodiment of the invention, the computing device (400) may include one or more output devices (408), such as a display (e.g., a liquid crystal display (LCD), a plasma display, a touch screen, a cathode ray tube (CRT) monitor, a projector, or other display device), a printer, external memory, or other output device. One or more of the output devices may be the same as or different from the input device(s). The input and output device(s) may be connected locally or remotely to the computer processor(s) (402), the non-persistent memory (404), and the persistent memory (406). There are many different types of computing devices, and the aforementioned input and output device(s) may also take other forms.
[0124] As used herein, the term operatively connected or operatively connected means that a direct or indirect connection exists between elements / components / devices that enables the elements to interact with each other in some way. The term 'operatively connected' may refer, for example, to a direct connection (e.g., directly between two devices or components via a wired connection) or an indirect connection (e.g., wired and / or wireless connections between any number of devices or components connecting the operatively connected devices). Thus, any path by which information can be transferred may be considered an operative connection.
[0125] As used herein, an identifier may refer to a unique combination of alphanumeric characters associated with an entity that specifies that particular entity. The identifier may be local (usable by a single component) or global (usable by all components).
[0126] As used herein, a unit programmed or configured to perform a function (e.g., step, action, etc.) refers to one or more hardware devices (e.g., processors, digital signal processors, field-programmable gate arrays, application-specific integrated circuits, etc.) that provide the function. The hardware devices may be programmed to execute, for example, computer instructions (e.g., computer code) that cause the hardware devices to provide the function. In another example, the hardware device may be programmed to include circuitry adapted (e.g., modified) to perform the function. A unit programmed to perform a function does not include computer instructions isolated from hardware devices.Computer instructions can be used to program a hardware device which, when programmed, provides the function.
[0127] The problems discussed above should be understood as examples of problems solved by embodiments of the invention, and the invention should not be limited to solving the same / similar problems. The disclosed invention is broadly applicable to address a range of problems beyond those discussed herein.
[0128] One or more embodiments of the invention may be implemented using instructions executed by one or more processors of a computing device. Furthermore, such instructions may correspond to computer-readable instructions stored on one or more non-transitory computer-readable media.
[0129] While the invention has been described above with respect to a limited number of embodiments, those skilled in the art, having the benefit of this disclosure, will recognize that other embodiments may be devised that do not depart from the scope of the invention as defined by the invention. Therefore, the scope of the invention should be limited only by the appended claims.
Claims
[1] A method for configuring components, comprising: Identifying a first change event by an operating system (OS) agent of a production host, where: the production host includes a variety of components and the plurality of components are used by a plurality of virtual machines (VMs) running on the production host; making a first determination that the first change event is associated with a component of the plurality of components; Updating a component allocation table based on the first change event in response to making the first determination; Identifying a second change event; making a second determination that the second change event is associated with a VM of the plurality of VMs; Updating the component allocation table based on the second change event in response to making the second determination; and Providing updated component allocations to an OS of the production host and the plurality of VMs, the component allocations enabling the plurality of VMs to use the plurality of components to perform computer-implemented services. [2] The method of claim 1, wherein the plurality of components comprise peripheral devices operatively connected to the production host via Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) connections. [3] The method of claim 2, wherein the component allocation table includes entries for each component of the plurality of components specifying: a component slot identifier, Bus Device Function (BDF) information, a component type of component types, an assigned VM identifier and a status. [4] The method of claim 3, wherein the allocated VM identifier comprises one selected from a group consisting of: a VM identifier associated with the VM of the plurality of VMs assigned to a corresponding component of the plurality of components; and an indicator that the corresponding component of the plurality of components is not assigned to any one of the plurality of VMs. [5] The method of claim 3, wherein the status specifies whether the component is active or inactive. [6] The method of claim 3, wherein the component types include: a network interface controller, a host bus adapter, a graphics card and a semiconductor drive. [7] The method of claim 1, wherein updating the component allocation table based on the first change event comprises: Making a third determination that the first change event is linked to an addition; Making a fourth determination that the component is not specified in the component allocation table in response to the third determination; and Generating a new entry in the component allocation table associated with the component in response to the fourth determination. [8] The method of claim 1, wherein updating the component allocation table based on the first change event comprises: Making a third determination that the first change event is linked to an addition; Making a fourth determination that the component is specified in the component allocation table in response to the third determination; and Updating an entry associated with the component in the component allocation table to change a status associated with the component from inactive to active in response to the fourth determination. [9] The method of claim 1, wherein updating the component allocation table based on the second change event comprises: Making a third provision that the second change event is accompanied by a VM reconfiguration associated with a second component of the plurality of components; and Updating an entry associated with the second component to include a newly allocated VM identifier in response to the third determination. [10] The method of claim 1, further comprising: before identifying the first change event and after an initial boot of the production host: Generate an initial component allocation table linked to the production host; Obtaining configuration information associated with the production host; Making a third determination that the configuration information is linked to a standard configuration; Updating the component allocation table based on the default configuration in response to the third determination; and Providing initial component allocations to the OS of the production host and the plurality of VMs, wherein the initial component allocations enable the plurality of VMs to use the plurality of components to perform computer-implemented services. [11] A non-transitory computer-readable medium comprising computer-readable program code that, when executed by a computer processor, enables the computer processor to perform a method of configuring components, the method comprising: Identifying a first change event by an operating system (OS) agent of a production host, where: the production host includes a variety of components and the plurality of components are used by a plurality of virtual machines (VMs) running on the production host; making a first determination that the first change event is associated with a component of the plurality of components; Updating a component allocation table based on the first change event in response to making the first determination; Identifying a second change event; making a second determination that the second change event is associated with a VM of the plurality of VMs; Updating the component allocation table based on the second change event in response to making the second determination; and Providing updated component allocations to an OS of the production host and the plurality of VMs, the component allocations enabling the plurality of VMs to use the plurality of components to perform computer-implemented services. [12] The non-transitory computer-readable medium of claim 11, wherein the plurality of components comprise peripheral devices operatively connected to the production host via Peripheral Component Interconnect (PCI) and Peripheral Component Interconnect Express (PCIe) connections. [13] The non-transitory computer-readable medium of claim 12, wherein the component allocation table includes entries for each component of the plurality of components specifying: a component slot identifier, Bus Device Function (BDF) information, a component type of component types, an assigned VM identifier and a status. [14] The non-transitory computer-readable medium of claim 13, wherein the allocated VM identifier comprises one selected from a group consisting of: a VM identifier associated with the VM of the plurality of VMs assigned to a corresponding component of the plurality of components; and an indicator that the corresponding component of the plurality of components is not assigned to any one of the plurality of VMs. [15] The non-transitory computer-readable medium of claim 13, wherein the status specifies whether the component is active or inactive. [16] The non-transitory computer-readable medium of claim 13, wherein the component types include: a network interface controller, a host bus adapter, a graphics card and a semiconductor drive. [17] The non-transitory computer-readable medium of claim 11, wherein updating the component allocation table based on the first change event comprises: Making a third determination that the first change event is linked to an addition; Making a fourth determination that the component is not specified in the component allocation table in response to the third determination; and Generating a new entry in the component allocation table associated with the component in response to the fourth determination. [18] The non-transitory computer-readable medium of claim 11, wherein updating the component allocation table based on the first change event comprises: Making a third determination that the first change event is linked to an addition; Making a fourth determination that the component is specified in the component allocation table in response to the third determination; and Updating an entry associated with the component in the component allocation table to change a status associated with the component from inactive to active in response to the fourth determination. [19] The non-transitory computer-readable medium of claim 11, wherein updating the component allocation table based on the second change event comprises: Making a third determination that the second change event is associated with a VM reconfiguration associated with a second component of the plurality of components; and Updating an entry associated with the second component to include a newly allocated VM identifier in response to the third determination. [20] The non-transitory computer-readable medium of claim 11, further comprising: before identifying the first change event and after an initial boot of the production host: Generate an initial component allocation table linked to the production host; Obtaining configuration information associated with the production host; Making a third determination that the configuration information is linked to a standard configuration; Updating the component allocation table based on the default configuration in response to the third determination; and Providing initial component allocations to the OS of the production host and the plurality of VMs, wherein the initial component allocations enable the plurality of VMs to use the plurality of components to perform computer-implemented services.