Method and system for a vBMC for a composed server instance

1 . A method for managing a logically composed system (LCS), comprising:

sending a request to a microvisor kernel (MK) of a microvisor to provision the LCS on a first information handling system (IHS), wherein the request comprises a configuration template (CT), wherein the microvisor executes on the first IHS to provision a plurality of LCSs comprising the LCS;

initiating provisioning of the LCS based on the CT, wherein the provisioning of the LCS comprises an initiation of a guest basic input/output system (BIOS) of the LCS;

receiving a notification, from the MK, specifying that the LCS has been provisioned;

after the notification has been received:

sending a second request to a system control processor (SCP) of the first IHS to generate a virtual baseboard management controller (vBMC) on the first IHS, wherein the vBMC is configured to manage at least a portion of the LCS;

receiving a second notification, from the SCP, specifying that the vBMC is generated on the SCP;

after the second notification has been received:

making a determination that the vBMC could not manage at least the portion of the LCS;

obtaining, based on the determination, first metadata (FM) associated with a second IHS and second metadata (SM) associated with a third IHS;

analyzing the FM and the SM to extract relevant data, wherein the relevant data comprises first information in relation to a first hardware resource set (HRS) of the second IHS and second information in relation to a second HRS of the third IHS;

inferring, based on the relevant data, that the second IHS has at least a required amount of hardware resources to execute a runtime instance of the vBMC (RIvBMC);

sending, in response to the inferring, a third request to a second SCP of the second IHS to execute the RIvBMC;

receiving a third notification, from the second SCP, specifying that the RIvBMC is ready to execute on the second SCP;

upon receiving the third notification and while maintaining execution of the vBMC on the first IHS, generating a secure data transfer path, wherein the secure data transfer path comprises a tunneling protocol, between the vBMC and the RIvBMC, wherein the vBMC and the RIvBMC communicate over the secure data transfer path; and

initiating a display notification of an administrator about the RIvBMC using a graphical user interface (GUI).

2 . The method of claim 1 , further comprising:

after receiving the third notification from the second SCP:

receiving an additional memory resource deployment request (AMRDR) from the runtime instance of the vBMC, wherein the AMRDR has been received by the runtime instance of the vBMC, via the secure data transfer path, from the LCS;

making a second determination that the AMRDR is within a memory resource deployment policy limit;

sending, based on the second determination, a confirmation in relation to the AMRDR to the runtime instance of the vBMC; and

deploying an additional memory resource to the LCS.

3 . The method of claim 1 , wherein the secure data transfer path utilizes a tunneling protocol.

4 . The method of claim 1 , wherein, prior to sending the second notification, the SCP receives a cybersecurity attestation in relation to the vBMC from the microvisor, wherein the cybersecurity attestation specifies at least a security status of the vBMC.

5 . The method of claim 1 ,

wherein a physical BMC of the first IHS is not aware of the vBMC executing on the SCP of the first IHS and of the LCS,

wherein the physical BMC of the first IHS is not aware of the microvisor and the runtime instance of the vBMC executing on the second SCP of the second IHS,

wherein the LCS is not aware of the physical BMC of the first IHS and of the runtime instance of the vBMC, and

wherein the vBMC is logically separated from hardware and software resources of the LCS.

6 . The method of claim 1 , further comprising:

prior to sending the CT to the MK:

sending a fourth request to a processor of the first IHS to initiate the microvisor,

wherein, upon receiving the fourth request, the processor initiates the microvisor via a BIOS microvisor loader.

7 . The method of claim 6 , further comprising:

prior to sending the fourth request:

receiving a vendor key that is assigned to the first IHS from the processor to initiate a bi-directional trust establishment process;

in response to receiving the vendor key, sending a second vendor key to the processor to complete bi-directional trust establishment process; and

notifying the administrator about the completed bi-directional trust establishment process,

wherein the bi-directional trust establishment process is required in order to allow the processor of the first IHS to initiate the microvisor.

8 . The method of claim 1 ,

wherein the CT specifies at least one HRS, wherein the at least one HRS comprises:

a third HRS of a third IHS;

a fourth HRS of a fourth IHS; and

a fifth HRS of an external resource,

wherein the first IHS, the third IHS, and the fourth IHS are distinct devices operably connected to each other and the external resource over a network.

9 . The method of claim 8 , wherein the third HRS specifies at least one selected from a group consisting of a minimum user count, a maximum user count, a central processing unit (CPU) count per-LCS, a speed select technology configuration, an LCS hardware virtualization configuration, and an LCS IO memory management unit configuration.

10 . The method of claim 8 , wherein the fourth HRS specifies at least one selected from a group consisting of a minimum user count, a maximum user count, a swap space configuration per-LCS, a reserved memory configuration, and a memory ballooning configuration.

11 . The method of claim 8 , wherein the fifth HRS specifies at least one selected from a group consisting of a minimum user count, a maximum user count, a graphics processing unit (GPU) count per-LCS, a type of a GPU scheduling policy, and a type of a GPU virtualization approach that needs to be implemented.

12 . The method of claim 8 , wherein the third HRS comprises hardware resources that are distinct from hardware resources of the fourth hardware resource set.

13 . The method of claim 1 ,

wherein the runtime instance of the vBMC is a proxy variant of the vBMC,

wherein, when the LCS sends an inquiry to the vBMC, the runtime instance of the vBMC analyzes the inquiry and sends a response, via the secure data transfer path, to the LCS in relation to the inquiry on behalf of the vBMC, and

wherein the vBMC is external to a physical BMC of the first IHS.

14 . A method for managing a logically composed system (LCS), comprising:

sending a request to a microvisor kernel (MK) of a microvisor to provision the LCS on a first information handling system (IHS), wherein the request comprises a configuration template (CT), wherein the microvisor executes on the first IHS to provision a plurality of LCSs comprising the LCS;

initiating provisioning of the LCS based on the CT, wherein the provisioning of the LCS comprises an initiation of a guest basic input/output system (BIOS) of the LCS;

receiving a notification, from the MK, specifying that the LCS has been provisioned;

after the notification has been received:

sending a second request to a system control processor (SCP) of the first IHS to generate a virtual baseboard management controller (vBMC) on the first IHS;

receiving a second notification, from the SCP, specifying that the vBMC is generated on the SCP;

after the second notification has been received:

making a determination that the vBMC could not manage at least a portion of the LCS;

obtaining, based on the determination, first metadata (FM) associated with a second IHS and second metadata (SM) associated with a third IHS;

analyzing the FM and the SM to extract relevant data, wherein the relevant data comprises first information in relation to a first hardware resource set (HRS) of the second IHS and second information in relation to a second HRS of the third IHS;

inferring, based on the relevant data, that the second IHS has at least a required amount of hardware resources to execute a runtime instance of the vBMC (RIvBMC);

sending, in response to the inferring, a third request to a second SCP of the second IHS to execute the RIvBMC;

receiving a third notification, from the second SCP, specifying that the RIvBMC is ready to execute on a second microvisor of the second IHS;

upon receiving the third notification and while maintaining execution of the vBMC on the first IHS, generating a secure data transfer path, wherein the secure data transfer path comprises a tunneling protocol, between the vBMC and the RIvBMC, wherein the vBMC and the RIvBMC communicate over the secure data transfer path; and

initiating a display notification of an administrator about the RIvBMC using a graphical user interface (GUI).

15 . The method of claim 14 , further comprising:

after receiving the third notification from the second SCP:

receiving an additional memory resource deployment request (AMRDR) from the runtime instance of the vBMC, wherein the AMRDR has been received by the runtime instance of the vBMC, via the secure data transfer path, from the LCS;

making a second determination that the AMRDR is within a memory resource deployment policy limit;

sending, based on the second determination, a confirmation in relation to the AMRDR to the runtime instance of the vBMC; and

deploying an additional memory resource to the LCS.

16 . The method of claim 14 ,

wherein a physical BMC of the first IHS is not aware of the vBMC executing on the microvisor and of the LCS,

wherein the physical BMC of the first IHS is not aware of the microvisor and the runtime instance of the vBMC executing on the second SCP of the second IHS,

wherein the LCS is not aware of the physical BMC of the first IHS and of the runtime instance of the vBMC, and

wherein the vBMC is logically separated from hardware and software resources of the first IHS.

17 . The method of claim 14 ,

wherein the CT specifies at least one HRS, wherein the at least one HRS comprises:

a third HRS of a third IHS;

a fourth HRS of a fourth IHS; and

a fifth HRS of an external resource,

wherein the first IHS, the third IHS, and the fourth IHS are distinct devices operably connected to each other and the external resource over a network.

18 . The method of claim 17 , wherein the third HRS specifies at least one selected from a group consisting of a minimum user count, a maximum user count, a central processing unit (CPU) count per-LCS, a speed select technology configuration, an LCS hardware virtualization configuration, and an LCS IO memory management unit configuration.

19 . The method of claim 17 , wherein the fourth HRS specifies at least one selected from a group consisting of a minimum user count, a maximum user count, a swap space configuration per-LCS, a reserved memory configuration, and a memory ballooning configuration.

20 . A method for managing a logically composed system (LCS), comprising:

sending a request to a microvisor kernel (MK) of a microvisor to provision the LCS on a first information handling system (IHS), wherein the request comprises a configuration template (CT), wherein the microvisor executes on the first IHS to provision a plurality of LCSs comprising the LCS;

initiating provisioning of the LCS based on the CT, wherein the provisioning of the LCS comprises an initiation of a guest basic input/output system (BIOS) of the LCS;

receiving a notification, from the MK, specifying that the LCS has been provisioned;

after the notification has been received:

obtaining first metadata associated with the first IHS and second metadata associated with a second IHS;

analyzing the first metadata and the second metadata to extract relevant data, wherein the relevant data comprises at least first information in relation to a first hardware resource set of the first IHS and second information in relation to a second hardware resource set of the second IHS;

inferring, based on the relevant data, that the first IHS has at least a required amount of hardware resources to execute a virtual baseboard management controller (vBMC) associated with the first IHS;

sending, based on the inferring, a second request to a system control processor (SCP) of the first IHS to generate the vBMC on the first IHS;

receiving a second notification, from the SCP, specifying that the vBMC is generated on the SCP and is ready to interact with the LCS, wherein the SCP presents to LCS hardware resources specified by the CT as bare-metal resources comprising hardware resources from the first IHS and the second IHS; and

upon receiving the second notification, initiating a display notification of an administrator about the vBMC using a graphical user interface (GUI).