Patent Description:
In a data center, servers come with different vendors, models, and configurations. In many cases, the servers are configured with numerous add-on cards such as different Network Interface Controllers (NICs), Host Bus Adapters (HBAs), disk controllers and more. To maintain the firmware (FW) versions of such add-on cards to match the different versions of operating system (OS) types (e.g., CentOS, RedHat LINUX, MS Windows, VMWare ESXi, and more) is a very costly task. System admins need to use the specific utilities provide by the add-on card vendors to update the FW. However, the utilities provided form the add-on card vendors are only available for limited OSs.

In related art implementations, system admins need to manually reboot each of the servers to a specific OS supported by the card vendors and apply the add-on card utilities to apply the FW update process. Further, system admins need to find out the hardware information of the servers before the FW update process can be started. Collecting hardware information on different platforms with different OS types can be challenging. In the data center, the system admins can face such issues constantly, and can involve data centers with hundreds of servers. For example, in <CIT>, a system and a method for automatically updating firmware of components of a server is disclosed by which an OS image file from a vendor is to be downloaded, mounted to the server system via a first virtual media and used to generate a universal serial bus read/write image containing a firmware image for a second virtual media use, followed by a command for setting a boot disk via the first virtual media, rebooting the server and enabling an update service to automatically mount updated firmware image to the second virtual media.

Related art implementations utilize the Baseboard Management Controller (BMC) virtual media to reboot the server with the add-on cards vendor support OS and carry out the FW update. However, such implementations can be server vendor-specific, and require application programming interface (APIs) from the vendor or tools to create the virtual media mount for the PC reboot to the different OS. Another related art implementation involves utilizing the Preboot Execution Environment (PXE) boot to allow the selected server to reboot to a specific OS for the FW update. Such solutions can address the limitation of vendor specific servers, but creates another issue of colliding the production PXE servers and Dynamic Host Configuration Protocol (DHCP) servers. Related art implementations add extra NIC to isolate the DHCP servers and PXE which, increases the complexity of the network and operation cost.

Example implementations described herein involve systems and methods for a set of API endpoints which allow any applications to integrate with a deployment manager to perform the hardware information collection and add-on cards FW update, seamlessly.

Aspects of the present disclosure can include a method for upgrading one or more of add-on firmware and disk firmware for a server, the method involving connecting a port of the server to an isolated network; caching onto cache memory of the server, an operating system received through the isolated network; booting the operating system on the server from the cache memory; conducting a Network File System (NFS) mount on the server to determine hardware information associated with the upgrading of the one or more of the add-on firmware and the disk firmware; and upgrading the one or more of the add-on firmware and the disk firmware based on the hardware information.

Aspects of the present disclosure can further include a computer program, storing instructions for upgrading one or more of add-on firmware and disk firmware for a server, the instructions involving connecting a port of the server to an isolated network; caching onto cache memory of the server, an operating system received through the isolated network; booting the operating system on the server from the cache memory; conducting a Network File System (NFS) mount on the server to determine hardware information associated with the upgrading of the one or more of the add-on firmware and the disk firmware; and upgrading the one or more of the add-on firmware and the disk firmware based on the hardware information. The instructions may be stored on a non-transitory computer readable medium and configured to be executed by one or more processors.

Aspects of the present disclosure can further include a management node configured to upgrade one or more of add-on firmware and disk firmware for a server, the management node involving a processor, configured to connect a port of the server to an isolated network; cache onto cache memory of the server, an operating system received through the isolated network; boot the operating system on the server from the cache memory; conduct a Network File System (NFS) mount on the server to determine hardware information associated with the upgrading of the one or more of the add-on firmware and the disk firmware; and upgrade the one or more of the add-on firmware and the disk firmware based on the hardware information.

Aspects of the present disclosure can further include a system for upgrading one or more of add-on firmware and disk firmware for a server, the system involving means for connecting a port of the server to an isolated network; means for caching onto cache memory of the server, an operating system received through the isolated network; means for booting the operating system on the server from the cache memory; means for conducting a Network File System (NFS) mount on the server to determine hardware information associated with the upgrading of the one or more of the add-on firmware and the disk firmware; and means for upgrading the one or more of the add-on firmware and the disk firmware based on the hardware information.

The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.

Today's system admins are facing a difficult task to maintain production servers with supported/certified up-to-date software, FW for server hardware and FW for the add-on devices (i.e., NICs, HBAs, disk controllers, and disks) for reliability, performance and security requirements. Updating FW for the add-on cards are not straight forward. It involves finding the correct upgrade path and using proper utilities provided by the add-on card vendors. These utilities can only be used in a small list of supported OSs. This solution offers a server vendor-agnostic automated mechanism to perform a seamless add-on card FW update. In this solution, a dedicated Firmware Update Network (FUN) will be automatically created in the layer-<NUM> network, only single port on the switch will be configured with specific native VLAN ID for the FUN and it will be restored back to the original setting upon the completion of the add-on cards FW update. A customized PXE image with NFS root volume (a highly modified CentOS with a very small footprint) boots from a dedicated PXE server reside on Deployment Manager withing the dedicated. The combination of PXE boot and root volume through NFS mount enable us to update add-on cards FW bundles without creating any ISO image for PXE boot that allows us change FW and process on-the-fly. IPMI Tool and RedFish protocol will be used to control the boot sequence on the selected server for FW update and hardware information will be collected during the process, as well. To further secure the communication between the server being updated and the Deployment Manager, the server's unique MAC addresses will be registered with the Deployment Manager DHCP on the PXE server. The Deployment Manager PXE server will only answer the registered MAC addresses. This PXE server is managed by the Deployment Manager in a docker container to reduce overhead and harden security.

Example implementations involve an automated process to construct a dedicated Firmware Update Network (FUN) for add-on cards FW update and hardware information collection. This network provides a secured layer-<NUM> network environment to eliminate the disruption on the production environment. Since all the changes are done in the layer-<NUM> network, it makes the solution highly scalable and server vendor agnostic. Furthermore, the PXE server in the FUN is one of the many docker containers with the deployment manager (DM) that provides a tightly integrated microservice for less overhead. With all these measurements, the example implementations described herein facilitate a highly secured and non-disruptive solution with the production PXE servers and DHCP servers.

Through the example implementations described herein, any server connected to the network can undergo appropriate add-on cards/disk FW upgrades, thereby allowing the data center to be vendor agnostic with respect to the servers that are connected. The example implementations can be applied to any server regardless of the underlying configuration, and does not need any extra equipment to facilitate the add-on cards/disk FW upgrades.

Example implementations also facilitate APIs such as network file system (NFS) mounts that facilitate the hardware information collection as well as the add-on cards/disk FW update. In an example, the APIs of the NFS mount can facilitate hardware information collection such as, but not limited to, the type of add-on card in the server, the type of disk drive(s), the type of servers, the server configuration (e.g., processors or memory used), the slots in the server, and so on in accordance with the desired implementation.

Example implementations utilize an isolated network to facilitate the firmware update as will be described herein. Through utilizing an isolated network separate from the production network, example implementations thereby safeguard the Deployment Manager PXE server and DHCP server in the production environment from unwanted internet protocol address assignments to the production environment. Further, the isolated network maintains security by safeguarding the PXE operating system used to boot up the server and to execute add-on cards/disk FW update through restricting the access through the deployment manager of the management node, which manages access to the docker container. In example implementations as described herein, the PXE server will be facilitated by docker containers to provide portability, security and reduce the dedicated resources overhead. In example implementations involving clusters of production environments, multiple instances of the docker container as described herein can be spawned for each cluster to facilitate the desired implementation.

Example implementations can be applied to a single server update (e.g., single server in a production environment to avoid significant downtime) or multiple servers update concurrently (e.g., non-production environment rapid deployment).

<FIG> illustrates an example configuration for a firmware update network, in accordance with an example implementation. In the example of <FIG>, a server operating in a production environment is being updated. Through the DM interface, the user can select the servers need to be updated. Since this is a production server, the server will be put in the maintenance mode first to avoid the total disruption for its corresponding cluster. The DM starts to configure the FUN in the background automatically. During the process to configure the FUN, the DM establishes a secure shell (SSH) to the switch (e.g., in this example, a switch made by VendorX), conducts a backup of the paired ports configuration, changes the default virtual local area network (VLAN) on the ports, and then creates the VLAN. <FIG> illustrates an example of configuring a FUN with VLAN ID <NUM>.

<FIG> illustrates an example system, in accordance with an example implementation. In an example implementation, there is a server <NUM> or multiple servers that are to have firmware updates to the add-on cards or disks. Such servers are connected to a switch <NUM> and can be connected to a production network <NUM> and interacting with the DHCP server <NUM> of the production environment. When the management node <NUM> is instructed to conduct firmware updates, management node <NUM> initiates the configuration as illustrated in <FIG> to create FUN <NUM>, which connects the server <NUM> to the PXE boot server <NUM>. PXE boot server <NUM> may involve one or more containers <NUM> that can include a DHCP server <NUM> for the FUN <NUM>, a trivial file transfer protocol (TFTP) server <NUM>, a Network File System (NFS) server <NUM>, and a Hypertext Transfer Protocol (HTTP) server. Each of the one or more containers <NUM> can correspond to a particular cluster of servers in a production environment as managed by switch <NUM> or another switch depending on the desired implementation. Management node <NUM> executes DM to configure switch <NUM> as illustrated in <FIG>. Depending on the desired implementation, PXE boot server <NUM>, and container <NUM> can be provided via a virtual machine (VM) spanning over a plurality of servers on a cloud. In such an example implementation, the VM and the DM can both be managed by management node <NUM>.

After the FUN <NUM> has been created, the DM will discover the corresponding paired media access control (MAC) address of the NIC of the server selected for the firmware update and register the MAC to the DHCP server <NUM> in PXE boot server <NUM> to ensure that the DHCP server <NUM> will not provide an Internet Protocol (IP) address to any production server that is not intended to be involved with the add-on cards FW update. DM then initiates a reset (e.g., such as an ESXi reset) with an Intelligent Platform Management Interface (IPMI) Tool. Once the targeted server <NUM> is active from reboot, the DM will start the add-on cards update process.

Upon the completion of the entire process, DM will restore the port configuration in switch <NUM>.

<FIG> illustrates an example overall flow for the add-on cards/disk firmware update by the management node <NUM>, in accordance with an example implementation. At first at <NUM>, the management node <NUM> detects a server (e.g., server <NUM>) that requires an add-on cards/disk FW update. At <NUM>, the management node <NUM> configures switch <NUM> to create a dedicated FUN <NUM> between the server <NUM>, the switch <NUM>, the management node <NUM>, and the VM/PXE server <NUM>.

At <NUM>, the management node <NUM> initiates the docker container for PXE boot server <NUM> with a selected server unique NIC MAC registered on the PXE boot server <NUM> to avoid colliding with the production PXE servers. At <NUM>, the management node <NUM> reconfigures the boot sequence on the select server <NUM> and initiates a reboot to let the server boot up with the customized PXE-LiveOS.

At <NUM>, after the server <NUM> completes the bootup process, the management node <NUM> starts the process of collecting hardware information on the server <NUM> and the corresponding add-on cards/disk FW update process. The update process is executed through the customized PXE-LiveOS. The management node <NUM> collects the hardware information and determines what version of firmware is to be used for the update.

At <NUM>, upon completion of the add-on cards FW update process, the management node <NUM> reboots the server <NUM> with the original boot sequence. At <NUM>, the management node <NUM> restores the network configuration on the switch ports of switch <NUM> that were configured in the FUN. The process then ends, and the management node <NUM> can provide a report regarding the add-on cards/disk FW update as being completed, as well as the hardware information.

<FIG> illustrates an example flow upon which example implementations can be applied. At first, the administrator selects the server(s) for add-on cards/disk FW update and HW information collection through the deployment manager interface at <NUM>. At <NUM>, the user is asked to provide the FUN VLAN ID. Once the FUN VLAN ID is provided, at <NUM>, a check is conducted to determine if the compute switch port that is connected to the Management node is configured with "trunk mode" <NUM>. If so (yes), then the flow proceeds to <NUM> to add the FUN VLAN ID to the trunk <NUM>, otherwise (No) the flow proceeds to <NUM> to reconfigure the port to "trunk mode" and FUN VLAN ID to the trunk <NUM>. At <NUM>, the process finds the MAC address of the NIC that will be used on the selected server to boot from the FUN <NUM>.

At <NUM>, the flow checks if there is a matching MAC on the compute switch ports. If not (No), then the flow provides an interface for the user to provide the switch port number at <NUM>. Otherwise (Yes) the flow proceeds to <NUM> to back up the switch port configuration. At <NUM>, the flow resets the switch port with default VLAN to the FUN VLAN ID <NUM>. At <NUM>, the flow adds the FUN VLAN ID to the Deployment Manager VM.

At <NUM>, the flow starts the PXE server docker container on the Deployment Manager VM. At <NUM>, the Deployment Manager VM configures the selected server to PXE boost from the NIC configured in FUN.

At <NUM>, the flow checks if the server is powered on. If so (Yes), then the flow proceeds to <NUM> to conduct a power reset on the server. Otherwise (No) the flow proceeds to <NUM> to conduct a power up of the server.

At <NUM>, the flow checks the server boot status. If the server is to boot up (Up) then the flow proceeds to <NUM>, otherwise (Do not boot up) the flow proceeds to <NUM> to restore the switch port configuration and to <NUM> to report that a failure has occurred and to end the flow.

At <NUM>, the flow proceeds to collect HW information. At <NUM>, the flow initiates the add-on cards/disk FW update and provides a report on the progress. At <NUM>, the flow continues to monitor and report on the progress of the FW update. At <NUM>, a check is conducted to determine update completion. If completed then the flow proceeds to <NUM>, otherwise, the flow proceeds to <NUM>.

At <NUM>, the flow restores switch port configuration <NUM> and proceeds to <NUM> to report a successful FW update and restart the server with normal boost sequence.

<FIG> illustrates an example topology in the production environment, in accordance with an example implementation. In the example implementation, the production network <NUM> is managed by a compute switch <NUM>. The server <NUM> in this example is a compute node. At <NUM>, the management node <NUM> instructs the compute switch <NUM> managing the production network to temporarily change the default, native VLAN to the VLAN ID of the FUN. The FUN VLAN thereby connects the server <NUM> to the PXE server so that a server PXE boot can be executed to perform the add-on cards/disk FW update. As illustrated at <NUM> of <FIG>, compute switch <NUM> is to be configured with the trunk mode, so that the FUN VLAN ID is added. The FUN is an isolated network, which allows the compute switch <NUM> to have a port to server <NUM> that is isolated from the production network <NUM>, thereby eliminating issues with interference with the PXE or DHCP servers in the production environment.

The deployment manager VM is executed on the management node <NUM>, which provides the docker container as a PXE server and facilitates the add-on cards/FW update.

Example implementations described herein use an isolated and dedicated FUN to control a selected server to boot from a dedicated and highly secured PXE server as a docker container as managed by a management node. The PXE server provides a highly customized operating system such as CentOS PXE-LiveOS to perform add-on cards or disk FW update. Through such example implementations, it can thereby be possible to simplify the add-on cards/disk FW update and hardware management with consistency regardless of the underlying server configuration.

<FIG> illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as a management node as illustrated in <FIG> and <FIG> to facilitate the functions of the deployment manager. Computer device <NUM> in computing environment <NUM> can include one or more processing units, cores, or processors <NUM>, memory <NUM> (e.g., RAM, ROM, and/or the like), internal storage <NUM> (e.g., magnetic, optical, solid state storage, and/or organic), and/or I/O interface <NUM>, any of which can be coupled on a communication mechanism or bus <NUM> for communicating information or embedded in the computer device <NUM>. I/O interface <NUM> is also configured to receive images from cameras or provide images to projectors or displays, depending on the desired implementation.

Computer device <NUM> can be communicatively coupled to input/user interface <NUM> and output device/interface <NUM>. Either one or both of input/user interface <NUM> and output device/interface <NUM> can be a wired or wireless interface and can be detachable. Input/user interface <NUM> may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like). Output device/interface <NUM> may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface <NUM> and output device/interface <NUM> can be embedded with or physically coupled to the computer device <NUM>. In other example implementations, other computer devices may function as or provide the functions of input/user interface <NUM> and output device/interface <NUM> for a computer device <NUM>.

Examples of computer device <NUM> may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like).

Computer device <NUM> can be communicatively coupled (e.g., via I/O interface <NUM>) to external storage <NUM> and network <NUM> for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device <NUM> or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label.

I/O interface <NUM> can include, but is not limited to, wired and/or wireless interfaces using any communication or I/O protocols or standards (e.g., Ethernet, <NUM>. 11x, Universal System Bus, WiMax, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment <NUM>. Network <NUM> can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like).

Computer device <NUM> can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

Computer device <NUM> can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

Processor(s) <NUM> can execute under any operating system (OS) (not shown), in a native or virtual environment. One or more applications can be deployed that include logic unit <NUM>, application programming interface (API) unit <NUM>, input unit <NUM>, output unit <NUM>, and inter-unit communication mechanism <NUM> for the different units to communicate with each other, with the OS, and with other applications (not shown). The described units and elements can be varied in design, function, configuration, or implementation and are not limited to the descriptions provided. Processor(s) <NUM> can be in the form of hardware processors such as central processing units (CPUs) or in a combination of hardware and software units.

In some example implementations, when information or an execution instruction is received by API unit <NUM>, it may be communicated to one or more other units (e.g., logic unit <NUM>, input unit <NUM>, output unit <NUM>). In some instances, logic unit <NUM> may be configured to control the information flow among the units and direct the services provided by API unit <NUM>, input unit <NUM>, output unit <NUM>, in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled by logic unit <NUM> alone or in conjunction with API unit <NUM>. The input unit <NUM> may be configured to obtain input for the calculations described in the example implementations, and the output unit <NUM> may be configured to provide output based on the calculations described in example implementations.

Processor(s) <NUM> can be configured to facilitate the upgrading of one or more of add-on firmware and disk firmware for a server, through connecting a port of the server to an isolated network (e.g., the FUN) as illustrated at <NUM>-<NUM> of <FIG>; caching onto cache memory of the server, an operating system received through the isolated network as part of <NUM> and <NUM> of <FIG>, booting the operating system on the server from the cache memory as illustrated at <NUM>-<NUM> of <FIG>, conducting a Network File System (NFS) mount on the server to determine hardware information associated with the upgrading of the one or more of the add-on firmware and the disk firmware as illustrated at <NUM> and <NUM> of <FIG>; and upgrading the one or more of the add-on firmware and the disk firmware based on the hardware information as illustrated at <NUM>-<NUM> of <FIG>.

In example implementations, the booting the operating system involves executing a Preboot Execution Environment (PXE) boot as illustrated at <NUM> of <FIG>. The PXE boot can be legacy PXE and/or modern iPXE to facilitate the desired implementation.

As illustrated in <FIG> and <FIG>, the generating the isolated network involves changing a native Virtual Local Area Network (VLAN) of an associated switch port. The associated switch port is changed back to the native VLAN after upgrading is complete to connect the server back to the production environment.

Processor(s) <NUM> can be configured to register a media access control (MAC) address of the server to a Preboot Execution Environment (PXE) server as illustrated in <FIG> and <FIG>, and assign an internet protocol (IP) address to the registered MAC address of the server after generating the isolated network as illustrated at <NUM> to <NUM> in <FIG>. The sharing of the container <NUM>, including the APIs of the DHCP server <NUM>, the TFTP server <NUM>, and the NFS server <NUM> used for the NFS mount are then restricted to the assigned IP address. Hardware information of the server can thereby be generated by APIs from the NFS mount.

Processor(s) <NUM> can be configured to upgrade the one or more of the add-on firmware and the disk firmware based on the hardware information by comparing the hardware information with a previous bundle of the one or more of the add-on firmware and the disk firmware provided by the deployment manager. In example implementations, the management node manages in memory <NUM> the version status of all add-on cards and disk firmware for all of the servers connected to the production environment. In such example implementations, the servers in the production network can be upgraded in a sequential manner until all servers have the appropriate upgrades. Example implementations can thereby track what bundles were deployed for a particular cluster of servers and then compare the hardware information of the server to the bundle applied to that particular cluster. Such example implementations can be facilitated in any manner known to a person of ordinary skill in the art.

Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other information storage, transmission or display devices.

Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

Claim 1:
A method for upgrading one or more of add-on firmware and disk firmware for a server (<NUM>) being connected to a production network (<NUM>) for interacting with a DHCP server (<NUM>) of the production network (<NUM>), the method characterized by:
Generating, by a management node (<NUM>), an isolated network (<NUM>) being separated from the production network (<NUM>) between the server (<NUM>), a switch (<NUM>), a management node (<NUM>) and a PXE boot server (<NUM>) by configuring the switch (<NUM>);
initiating, by the management node (<NUM>), a docker container for the PXE boot server (<NUM>) with a selected server unique NIC MAC registered on the PXE boot server (<NUM>);
connecting a port of the server (<NUM>) to the isolated network (<NUM>);
caching (<NUM> - <NUM>) onto cache memory of the server (<NUM>), an operating system received through the isolated network (<NUM>);
booting (<NUM>) the operating system on the server (<NUM>) from the cache memory by reconfiguring, by the management node (<NUM>), the boot sequence on the server (<NUM>) and initiating a reboot to let the server boot up with a customized PXE-LiveOS;
collecting, by the management node (<NUM>), a process of collecting hardware information on the server (<NUM>) and starting a corresponding add-on cards/disk firmware update process by conducting (<NUM>; <NUM>) a Network File System, NFS, mount on the server (<NUM>) to determine hardware information associated with the upgrading of the one or more of the add-on firmware and the disk firmware comprising information regarding the type of add-on card in the server (<NUM>), the type of disk drives, the type of servers, the server configuration or the slots in the server (<NUM>), wherein the management node (<NUM>) collects the hardware information and determines which version of firmware is to be used for the update;
upgrading (<NUM> - <NUM>) the one or more of the add-on firmware and the disk firmware based on the hardware information comprising comparing the hardware information with a previous bundle of the one or more of the add-on firmware and the disk firmware provided by a deployment manager; and
upon completion of the upgrading process, rebooting, by the management node (<NUM>), the server (<NUM>) with the original boot sequence and restoring the network configuration on associated switch ports of the switch (<NUM>) which were configured in the isolated network (<NUM>).