Reduce downtime caused by incompatibility issues with firmware and software upgrades

Abstract

A method and system for estimating upgrade time and mitigating errors when updating a virtualized computing system, the operations of the method including, but not necessarily limited to, (i) identifying updates required by the system, (ii) comparing the system to be updated with other systems to determine similar systems that have already had similar updates performed, (iii) forecasting the time to complete the update based on performance characteristics of the system to be updated, performance characteristics of the similar systems that have already been updated, and the time it will take to update the similar systems, (iv) identifying errors encountered when updating the similar systems and corresponding error remedies, and (v) preemptively applying configuration changes or other error remedies to the system to be updated (and not necessarily in this order).

Description

[Technical field]

[0001] The present invention relates generally to the field of virtualized computing systems, and more particularly to maintaining and operating virtualized computing systems to properly perform enterprise solutions.

[0002] The Wikipedia entry for "hypervisor" (as of February 13, 2022) states: "A hypervisor (or virtual machine monitor, VMM, virtualizer), similar to an emulator, is computer software, firmware, or hardware that creates and runs virtual machines. The computer on which the hypervisor runs one or more virtual machines is called the host machine, and each virtual machine is called a guest machine. The hypervisor presents a virtual operating platform to the guest operating systems and manages their execution. Multiple instances of different operating systems may share virtualized hardware resources. ... This contrasts with operating system-level virtualization, where guest operating systems may differ in terms of user space... but have the same kernel... but all instances (usually called containers) must share a single kernel." Summary of the Invention

[0003] According to one aspect of the invention, there is a method, computer program product, and / or system that performs the following operations (not necessarily in the following order): (i) identifying a first plurality of updates required by a first virtualized computing system; (ii) comparing the first virtualized computing system to a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have updates corresponding to the first plurality of updates required by the first virtualized computing system; (iii) in response to the comparison, determining an estimated time to complete the first plurality of updates based at least in part on the set of performance characteristics of the first virtualized computing system; (iv) identifying a first plurality of errors that occurred during the updates of the set of similar virtualized computing systems; and (v) in response to identifying the first plurality of errors, preemptively applying a configuration change to the first virtualized computing system. [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 is a block diagram of a first embodiment of a system according to the present invention. [Diagram 2] 4 is a flowchart illustrating a method of the first embodiment that is performed at least in part by a system of the first embodiment. [Diagram 3] FIG. 2 is a block diagram showing the machine logic (eg, software) portion of the system of the first embodiment. [Figure 4] FIG. 1 is a block diagram of a first embodiment of a system according to the present invention. [Diagram 5] 1 is a flow chart illustrating a first embodiment of a method according to the invention; [Figure 6] 4 is a flow chart illustrating a second embodiment of the method according to the invention. [Figure 7] 4 is a flow chart illustrating a third embodiment of the method according to the invention. [Figure 8] 4 is a flow chart illustrating a fourth embodiment of the method according to the present invention. [Figure 9] FIG. 2 is a block diagram showing a second embodiment of a system according to the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] This Detailed Description section is divided into the following subsections: (i) Hardware and Software Environment; (ii) Exemplary Embodiments; (iii) Further Supplementary Description and / or Embodiments; and (iv) Definitions.

[0006] I. Hardware and Software Environment The present invention may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0007] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved structures on which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be interpreted as a transitory signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over electrical wires.

[0008] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in the computer readable storage medium within the respective computing / processing device.

[0009] The computer readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Smalltalk®, C++, and traditional procedural programming languages ​​such as the “C” programming language, or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions to individualize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the invention.

[0010] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0011] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored on a computer readable medium, such that the computer readable storage medium on which the instructions are stored comprises an article of manufacture including instructions implementing aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams, and can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0012] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0013] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or a combination of dedicated hardware and computer instructions.

[0014] Next, embodiments of possible hardware and software environments for the software and / or methods according to the present invention will be described in detail with reference to the drawings. Figure 1 is a functional block diagram showing various parts of a networked computer system 100, including a server subsystem 102, client subsystems 104, 106, 108, 110, 112, a communication network 114, a server computer 200, a communication unit 202, a processor set 204, an input / output (I / O) interface set 206, a memory device 208, a persistent storage device 210, a display device 212, an external device set 214, a random access memory (RAM) device 230, a cache memory device 232, and a program 300.

[0015] Subsystem 102 is in many respects representative of various computer subsystems in the present invention, and therefore several portions of subsystem 102 are described in the following paragraphs.

[0016] Subsystem 102 may be a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, personal digital assistant (PDA), smart phone, or any programmable electronic device capable of communicating with a client subsystem over network 114. Program 300 is a collection of machine-readable instructions and / or data used to create, manage, and control certain software functions described in detail below in the Exemplary Embodiments subsection of the Detailed Description of the Invention section.

[0017] Subsystem 102 may communicate with other computer subsystems via network 114. Network 114 may be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and may include wired, wireless, or fiber optic connections. In general, network 114 may be any combination of connections and protocols that support communication between server and client subsystems.

[0018] Subsystem 102 is shown as a block diagram with many double-headed arrows. These double-headed arrows (without individual reference numbers) represent a communications fabric that provides communication between various components of subsystem 102. This communications fabric may be implemented using any architecture designed to pass data and / or control information between processors (such as microprocessors, communications and network processors), system memory, peripheral devices, and any other hardware components in the system. For example, the communications fabric may be implemented, at least in part, using one or more buses.

[0019] Memory 208 and persistent storage 210 are computer-readable storage media. In general, memory 208 may include any suitable volatile or non-volatile computer-readable storage media. Additionally, it should be noted that, currently or in the foreseeable future, or both, (i) external devices 214 may be able to provide some or all of the memory to the subsystem 102, and / or (ii) devices external to the subsystem 102 may be able to provide memory to the subsystem 102.

[0020] The program 300 is stored in persistent storage 210 for access and / or execution by one or more of the respective computer processors 204, typically via one or more of the memories 208. Persistent storage 210 (i) is at least more persistent than signals in transmission, (ii) stores the program (including its soft logic and / or data) on a tangible medium (such as a magnetic or optical domain), and (iii) is substantially less persistent than permanent storage. Alternatively, data storage may be more persistent and / or permanent than the type of storage provided by persistent storage 210.

[0021] The program 300 may include both machine-readable and executable instructions and / or substantive data (i.e., the type of data stored in a database). In this particular embodiment, persistent storage 210 includes a magnetic hard disk drive. To name a few possible variations, persistent storage 210 may include a solid-state hard drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0022] The media used by persistent storage 210 may also be removable. For example, a removable hard drive may be used for persistent storage 210. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer to another computer-readable storage medium that is also part of persistent storage 210.

[0023] The communications unit 202, in these examples, provides for communication with other data processing systems or devices external to the subsystem 102. In these examples, the communications unit 202 includes one or more network interface cards. The communications unit 202 may provide for communication using either or both physical and wireless communications links. Any software modules described herein may be downloaded to a persistent storage device (such as persistent storage device 210) via a communications unit (such as communications unit 202).

[0024] The I / O interface set 206 allows input and output of data to and from the server computer 200 and other devices that may be locally connected in data communication. For example, the I / O interface set 206 provides a connection to an external device set 214. The external device set 214 typically includes devices such as a keyboard, a keypad, a touch screen, or any other suitable input device or combination thereof. The external device set 214 may also include portable computer-readable storage media, such as thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the invention, such as the program 300, may be stored on such portable computer-readable storage media. In these embodiments, the associated software may (or may not) be loaded in whole or in part onto the persistent storage device 210 via the I / O interface set 206. The I / O interface set 206 also connects in data communication with a display device 212.

[0025] Display device 212 provides a mechanism for displaying data to a user and may be, for example, a computer monitor or a smart phone display screen.

[0026] The programs described herein are identified based on the application for which they are implemented in a particular embodiment of the invention, however, it should be understood that the nomenclature of specific programs herein is used merely for convenience, and thus the invention should not be limited to use only with the particular application identified and / or implied by such nomenclature.

[0027] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many changes and modifications will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable other skilled in the art to understand the embodiments disclosed herein.

[0028] II. Exemplary Embodiments Figure 2 shows a flow chart 250 depicting a method according to the present invention. Figure 3 shows a program 300 for performing at least some of the method operations of flow chart 250. Throughout the following paragraphs, the method and associated software will be described with extensive reference to Figure 2 (for method operation blocks) and Figure 3 (for software blocks).

[0029] Processing begins at operation S255 where an update identification module ("mod") 305 identifies a set of updates required by the virtualized computing system.

[0030] Processing continues at operation S260, where the comparison virtualized computing system mod 310 compares the virtualized computing system (described in connection with operation S255 above) to a set of previously utilized and / or previously identified virtualized computing systems (sometimes referred to herein as a set of benchmark virtualized computing systems). In some embodiments of the present invention, this comparison is performed to determine a set of virtualized computing systems that have made updates similar to the updates identified as needing to be made by the virtualized computing system (described in connection with operation S255 above).

[0031] Processing continues to operation S265 where the update time estimate mod 315 determines an estimated amount of time to complete the identified update. In some embodiments of the present invention, the update time estimate mod 315 records the first estimated amount of time so that it can be used as a baseline time for future updates. For example, if the second virtualized computing system requires a future update that is essentially similar to the original update made to the first virtualized computing system, this baseline amount of time can be used to determine whether the update made to the second virtualized computing system was made in an efficient manner.

[0032] Processing continues to operation S270, where the error identification modulus 320 identifies a set of errors that occurred during the update process of the set of benchmark virtualized computing systems. In some embodiments of the present invention, when the number of errors that occurred during the update process is recorded, the identification modulus 320 is further used to determine whether the number of errors is below or above an error threshold. In some embodiments, the error threshold is used to determine the accuracy of the update process. That is, if more errors are identified, future updates having a higher number of errors than the original number of errors may be considered less accurate than future updates having a lower number of errors than the original number of errors.

[0033] Finally, processing proceeds to operation S275, where the configure virtualized computing system mod 325 preemptively applies the configuration changes to the virtualized computing system (as described in connection with operations S255 and S260 above).

[0034] III. Further Supplementary Description and / or Embodiments SUMMARY OF THE PRESENT EMBODIMENTS The present invention generally relates to updating system firmware and operating systems in a virtualized environment in a data center. A server / system is virtualized using a hypervisor and is backed by a special type of virtual machine called a Virtual IO Server (VIOS). A hypervisor is computer software or firmware that allows the creation of multiple Virtual Machines (VMs) running a given operating system and allows the resources allocated to the server to be shared among the VMs. In a virtualized setup, the sharing (or virtualization) of I / O resources is delegated to the VIOS. This VIOS behaves like any other VM running on the server, but it takes on the role of the hosting VM and is responsible for sharing the physical I / O resources, i.e. storage and network adapters, among other client VMs on the system. This is achieved by the VIOS owning the I / O resources and connecting them to virtual (or software equivalent) I / O resources. The virtual I / O resources are then used by the virtual machines to perform I / O operations. With the above context in mind, the following uses this terminology to further describe the present invention embodiments.

[0035] When a firmware update, VIOS update, or OS update is performed in a virtualized environment as described above, there is always the possibility that the newer update, level, or feature may not be compatible with the existing configuration of the virtualized environment. In such a scenario, after the update, there may be incompatibilities across the stack and downtime may be required to change settings and make configuration changes. Furthermore, the time it takes to update will vary depending on (i) the number of subsystems in the stack that need to be updated, (ii) calculating the total time it will take for all these updates, and (iii) planning the maintenance time for the exact total time required (which becomes problematic if it is longer than required).

[0036] The addition of VIOS further complicates the complexity of compatibility across the stack, and any changes to the VIOS may cause incompatibilities that may impact workloads running on operating systems within such virtualized environments. Embodiments of the present invention provide a mechanism to perform stack compatibility checks prior to the actual update, ensuring that the configuration of the virtualized environment remains compatible after the update.

[0037] An embodiment of the present invention provides an algorithm to parse README files and certain command outputs associated with corresponding components or subsystems and check prerequisites. The algorithm also checks compatibility between different levels of these subsystems. While the management console may be able to perform this check for firmware updates, OS updates and VIOS updates, if initiated via the management console, require an additional mechanism for the OS / VIOS to interact with the management console via the hypervisor to perform validation operations before proceeding with the update or upgrade.

[0038] The README / command output based compatibility stack should be considered a baseline level, but is improved by having a specific known configuration. Currently, these systems can upload their existing configuration as part of a call home update. These updates are configured to report the current configuration at regular intervals, in some embodiments, these updates occur once a week.

[0039] The solution involves documenting the number of systems reporting a particular configuration. Additionally, if a system has an issue, the configuration of the system reporting the issue should be documented and stored. If a system with a certain configuration has an issue, this issue should be noted as a negative value for that configuration when calculating the best configuration recommendation. Information regarding the time it takes to update or upgrade should be sent via call home data, and this information will be used to improve the baseline data of how long it takes for each subsystem to update / upgrade. Additionally, this baseline data will be used to improve the accuracy of the update time calculations.

[0040] In some embodiments, the management console fetches the necessary information of existing configurations and new versions and performs appropriate validations. These validations and results are fed into a learning model so that the validations can be continuously improved, and data on failures is also collected and fed back into the model after updates. When suggesting a configuration, the management console should select a configuration based on the number of systems reporting a particular configuration that also matches the extracted valid configuration.

[0041] In some embodiments, data collected as part of call home or telemetry is enhanced to send information regarding configuration levels, issues seen in the environment, SRCs that indicate issues, time taken for updates and / or upgrades, etc.

[0042] The components involved can be broadly grouped into the following categories:

[0043] (1)Administration Console: In case of a Management Console update, apart from checking the prerequisites at the Management Console level, the firmware, VIOS, OS, and any Management Console in the HA configuration or pool model are also checked.

[0044] (2) Firmware / Hypervisor: The Administration Console performs a check of the configuration's compatibility with the new level.

[0045] (3) Virtual IO Server: When a VIOS update is initiated, the VIOS will communicate with the management console via the hypervisor to check compatibility.

[0046] (4) Operating System: When an OS update or upgrade is initiated, the OS checks for compatibility through the hypervisor with the management console. In some embodiments, the management console checks the configuration of the systems and different subsystems in the stack before the update is performed and uses readme / command output information along with learnings gained from call home information to determine the best configuration.

[0047] An embodiment of the present invention provides a method for estimating upgrade time and mitigating errors when updating a computing system, the operations of which may include, but are not necessarily limited to, (i) identifying updates required by the system, (ii) comparing the system to be updated with other systems to determine similar systems that have already had similar updates performed, (iii) forecasting the time to complete the update based on performance characteristics of the system to be updated, performance characteristics of the similar systems that have already been updated, and the time it will take to update the similar systems, (iv) identifying errors encountered when updating the similar systems and corresponding error resolutions, and (v) preemptively applying configuration changes or other error resolutions to the system to be updated (and not necessarily in this order).

[0048] Embodiments of the present invention provide a cognitive upgrade process that estimates an adjustment for upgrade time and upgrade risk. In some embodiments, the upgrade process includes N updates, each of which may take a certain amount of time and carries a certain amount of risk of failure that may cause significant disruptions and downtime.

[0049] To make suitable inferences, embodiments of the present invention utilize an ensemble of algorithms that employ machine learning and artificial intelligence (AI) techniques.

[0050] The main elements of this algorithm include the following operations (not necessarily in the following order):

[0051] (1) Determine the complete set of software and firmware packages contained within the stack that are candidates for upgrade.

[0052] (2) For the stack to be upgraded, consider the complete set and determine the "difference" between the current state and the desired state.

[0053] (3) For each difference, excluding the difference that is resolved, identify peer groups such that the peer group has similar characteristics to the stack of interest. A nearest neighbor algorithm is used to identify the peer group at each step. Similarity is based on the complete set of packages.

[0054] For example, if the "difference" being addressed is the upgrade of a TCP component from version 1 to version 2, then the peer group would consist of all other known stacks that have the same or very close to the stack being upgraded, except that the TCP component has already been upgraded to version 2, and the rest of the SW and FW packages are the same as or very close to the stack being upgraded.

[0055] (4) Collect the time it takes for a peer group to upgrade to TCP version 2.

[0056] (5) Collect factors that determine performance characteristics, such as computational performance and storage read / write performance, that are used as input features for machine learning algorithms.

[0057] (6) Employ supervised machine learning techniques to build an ensemble of ML algorithms to predict the expected time it will take to upgrade from TCP version 1 to version 2 at regular intervals (e.g., take 30 minutes + / - 2 minutes). The features used in supervised learning consist of the performance characteristics of each stack in the peer group, and the upgrade time for each stack per variance.

[0058] (7) Repeat the above steps for each of the differences to generate a prediction of the upgrade time for each step.

[0059] (8) Use a similar technique, but consider all the differences at once to estimate the total time, in this case the peer group has successfully undergone the full stack upgrade.

[0060] (9) Creating aggregate forecasts based on individual variances.

[0061] (10) We use an ensemble of ML algorithms to predict the upgrade time for each step, as well as the time for the entire upgrade process.

[0062] Some embodiments of the present invention determine the probability of success of each step with respect to estimates of upgrade time and upgrade risk (as explained above).

[0063] Some embodiments of the present invention use techniques similar to the algorithms described above to determine the probability of success for estimating upgrade time and upgrade risk, as well as steps that can improve this probability. To do so, some embodiments utilize historical data in the form of system logs available to the peer group, and customer support ticket information available to the relevant proprietary entity. In some embodiments, text mining techniques are used to identify causes of failure and recommend mitigation measures. Additionally, some embodiments of the present invention utilize collaborative filtering algorithms to predict the probability of success.

[0064] The overall upgrade process includes the following actions (not necessarily in this order): (i) providing an overview of what to expect, including total estimated time and possible recommendations to improve the time (e.g., temporarily purchasing more compute resources via Capacity on Demand (COD)), risk assessment and mitigation recommendations, and a detailed breakdown of each step including upgrade time and risks; (ii) proceeding with each action based on user confirmation; and (iii) forecasting upgrade time for each action and adjusting the overall process after each action is completed.

[0065] To reduce downtime, some embodiments of the present invention use a cognitive upgrade assistant that includes (i) a chatbot that guides an administrator through the upgrade process, and (ii) inputs to the chatbot that include (a) a README file that is created using templates to register dependencies, (b) command line output (for chatbots that run on a server), (c) historical service data for the stack, and (d) service data for other clients that have similar configurations and have already run upgrades.

[0066] In some embodiments of the present invention, the cognitive upgrade process includes using the cognitive upgrade assistant to perform the following actions (not necessarily in the following order): (i) collect necessary contextual data that is stored locally on the stack, (ii) contextually integrate relevant external information for the stack from a "peer group," (iii) display missing prerequisites and risks, (iv) display estimated time with confidence level, and (v) use the information already collected to guide the administrator through the upgrade process through a dialogue with the administrator where each step is confirmed. In some embodiments, the administrator is a user who is prompted to confirm by displaying relevant corroborating evidence of what the cognitive upgrade assistant is doing and the actions the upgrade assistant is taking.

[0067] Virtualization environment diagram 400 of Figure 4 provides a graphical representation of a virtualization environment used by embodiments of the present invention. Diagram 400 includes the following components: management console 402, system / server 404, hypervisor 406, virtual machine 1 (VM1) 408, virtual machine 2 (VM2) 410, and VIOS 412.

[0068] Flow diagram 500 of Figure 5 illustrates a first graphical representation of an upgrade model for stack-level recommendations. Diagram 500 includes inputs such as a readme file with a particular template format and versioning (502), historical service data for a given stack (504), and service data from different clients with similar virtualization environments (506). These inputs are fed to an upgrade assistant module 508, which then outputs stack-level recommendations 510.

[0069] Flow diagram 600 of FIG. 6 provides a graphical representation of the upgrade assistant model of stack level recommendations. Diagram 600 includes inputs 602, upgrade assistant 604, and stack level recommendations 608. With respect to inputs 602, there are two types of inputs: static inputs 608 and dynamic inputs 610. Static inputs (608) include readme files (612) with specific template format and versioning, and test results (614) with information indicating version compatibility. Dynamic inputs (610) include SRCs, call home data, configuration information from cases and configuration related issues (616), service data from different clients with similar virtualization environments (618), and historical service data of the stack (620). The stack level recommendations (606) include the level (or tier) to update (622), a suggestion for N, N-1, N-2, etc. (624), a time estimate for the update (626), the order of the updates (628), the number of customers using the stack in the field (630), and the length of time the level (or tier) has been used in the environment.

[0070] Flow diagram 700 of FIG. 7 provides a graphical representation of the upgrade and / or update process. The process includes a user initiating an update or upgrade (702), which is sent to the Upgrade Assistant (704). The Upgrade Assistant initiates a communication request with the management console to gather the necessary contextual information from the stack (706). This contextual information is then combined with relevant external information from the peer group designed for use with the stack (708). Through this contextual information, upgrade / update recommendations and prerequisites are obtained (710). An estimated time for the update or upgrade is then provided (712). This estimated time for the update / upgrade guides the administrator through the update / upgrade process (714). Finally, the stack is continuously monitored for issues / SRCs and sends this data back to the Upgrade Assistant (716).

[0071] Flow diagram 800 in Figure 8 provides a graphical representation of the update / upgrade process alerts and notifications. A user sets up a scheduler to check for issues in the current configuration and known issues at the level (or tier) to which the user wishes to move (802). Information received from the scheduler is sent to the Upgrade Assistant (804). The Upgrade Assistant uses machine learning models to continually gather static and dynamic inputs (similar or the same as the static and dynamic inputs described in connection with Figure 6 above) (806).

[0072] In some embodiments, the alert scheduling module sends an alert if (i) there is a known issue in the current configuration and there is information on how to fix or work around the known issue (808), (ii) there is a known issue in the planned update level (810), or (iii) there is a fix available for the known issue, whether the issue is in the current configuration or in the planned update level (812), or any combination thereof.

[0073] Block diagram 900 of Figure 9 provides a graphical representation of a power virtualization and management model. Block diagram 900 includes a dynamic AI model 902, an upgrade assistant 904, an MC domain 906, a power server 908, a logical partition 910, a power hypervisor 912, a management console 914, a storage controller 916, a SAN switch 918, an OS1 (operating system 1) 920, an OS2 (operating system 2) 922, an OS3 (operating system 3) 924, a VIOS 926, an FSP 928, a PSU 930, a SAS 932, an FC adapter 934, a NET adapter 936, an LFT adapter 938, a firmware platform 940, and a virtual L2 switch 942. In some embodiments of the invention, the operating system utilized may include a proprietary operating system (such as OS1 920, OS2 922, and / or OS3 924).

[0074] IV. Definition The present invention: The subject matter described by the term "the present invention" should not be taken as an absolute indication that it is covered by either the claims as filed or the claims that may ultimately be issued after patent prosecution. The term "the present invention" is used to help the reader obtain a general sense of the belief that the disclosures herein are potentially new, but this understanding implied by the use of the term "the present invention" is tentative and provisional and may change during the course of patent prosecution as relevant information evolves and as the claims may be amended.

[0075] Embodiments: See definition of "present invention" above. A similar note applies to the term "embodiments".

[0076] And / or,...or...or both (combinations thereof): A non-exclusive disjunction, or for example, "A, B, or C, or combinations thereof" means that at least one of A or B or C is true and applicable.

[0077] Including, Including: Unless expressly stated otherwise, means "including but not necessarily limited to."

[0078] User / Subscriber: Includes, but is not necessarily limited to, (i) an individual person, (ii) an artificial intelligence entity with sufficient intelligence to act as a user or subscriber, or (iii) a group of related users or subscribers, or any combination thereof.

[0079] Data Communications: Any type of data communication method now known or later developed, including wireless communications, wired communications, and communications routes having wireless and wired portions. Data communications is not necessarily limited to (i) direct data communications, (ii) indirect data communications, and / or (iii) data communications in which the format, packetization status, medium, encryption status, and / or protocol remain constant throughout the course of the data communications.

[0080] Receive / Provide / Send / Input / Output / Report: Unless expressly specified otherwise, these words should not be construed as implying (i) any particular degree of directness in the relationship between the object and subject, and / or (ii) the absence of intermediate components, actions, and / or things between the object and subject.

[0081] Without Substantial Human Intervention: A process that is performed automatically (often by the operation of machine logic such as software) with little or no human input. Some examples of "without substantial human intervention" include (i) a computer is performing a complex process and a power grid outage causes a human to switch the computer to an alternate power source so that the process can continue uninterrupted; (ii) a computer is about to perform a resource-intensive process and a human determines that the resource-intensive process should actually begin (in this case, the process of determination requires a simple yes / no determination by a human, but in isolation involves substantial human intervention, but the resource-intensive process does not include any substantial human intervention); and (iii) a computer using machine logic to make a critical decision (e.g., a decision to ground all aircraft in anticipation of bad weather), but before implementing the critical decision, the computer must obtain a simple yes / no determination from a human source.

[0082] Automatically: without any human intervention.

[0083] Module / Sub-Module: Any set of hardware, firmware, or software, or any combination thereof, operable to perform a certain function, whether the module is (i) in a single local vicinity, (ii) distributed over a wide area, (iii) in a single vicinity within a larger software code, (iv) located within a single software code, (v) located within a single storage device, memory or medium, (vi) mechanically connected, (vii) electrically connected, or (viii) connected in data communication, or any combination thereof.

[0084] Computer: Any device capable of significant data processing and / or reading machine-readable instructions, including, but not limited to, desktop computers, mainframe computers, laptop computers, Field Programmable Gate Array (FPGA)-based devices, smart phones, personal digital assistants (PDAs), body worn or insertable computers, embedded device computers, and application specific integrated circuit (ASIC)-based devices.

Claims

1. 1. A computer implemented method (CIM) comprising: identifying a first plurality of updates required by a first virtualized computing system; comparing the first virtualized computing system to a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have updates corresponding to the first plurality of updates required by the first virtualized computing system; in response to the comparison, determining an estimated time to complete the first plurality of updates based at least in part on a set of performance characteristics of the first virtualized computing system; identifying a first plurality of errors that occurred during an update of the set of similar virtualized computing systems; preemptively applying configuration changes to the first virtualized computing system in response to the identification of the first plurality of errors. A computer implemented method (CIM) comprising:

2. 2. The CIM of claim 1, further comprising, in response to the identification of the first plurality of errors that occurred during the update of the set of similar virtualized computing systems, determining that the first plurality of errors does not exceed a first error threshold.

3. 2. The CIM of claim 1, wherein the set of performance characteristics of the first virtualized computing system comprises information indicative of computational performance of the first virtualized computing system.

4. 2. The CIM of claim 1, wherein the set of performance characteristics of the first virtualized computing system includes information indicative of storage read and / or write performance data of the first virtualized computing system.

5. The CIM of claim 1 , further comprising determining a first amount of time it takes to preemptively apply the configuration change to the first virtualization system.

6. 6. The CIM of claim 5, further comprising, in response to said determining, using said first amount of time taken to preemptively apply said configuration change as baseline update data for future application of said configuration change to said first virtualization system.

7. A computer program product (CPP), comprising: a machine-readable storage device; computer code stored on the machine-readable storage device, the computer code causing a processor set to: identifying a first plurality of updates required by a first virtualized computing system; comparing the first virtualized computing system to a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have updates corresponding to the first plurality of updates required by the first virtualized computing system; in response to the comparison, determining an estimated time to complete the first plurality of updates based at least in part on a set of performance characteristics of the first virtualized computing system; identifying a first plurality of errors that occurred during an update of the set of similar virtualized computing systems; preemptively applying configuration changes to the first virtualized computing system in response to the identification of the first plurality of errors. said computer code including instructions and data for carrying out operations including: A computer program product (CPP) comprising:

8. 8. The CPP of claim 7, further comprising, in response to the identification of the first plurality of errors that occurred during the update of the set of similar virtualized computing systems, determining that the first plurality of errors does not exceed a first error threshold.

9. 8. The CPP of claim 7, wherein the set of performance characteristics of the first virtualized computing system comprises information indicative of computational performance of the first virtualized computing system.

10. 8. The CPP of claim 7, wherein the set of performance characteristics of the first virtualized computing system includes information indicative of storage read and / or write performance data of the first virtualized computing system.

11. The CPP of claim 7 , further comprising: determining a first amount of time it takes to preemptively apply the configuration change to the first virtualization system.

12. 12. The CPP of claim 11, further comprising, in response to the determination, determining using the first amount of time it takes to preemptively apply the configuration change as baseline update data for future application of the configuration change to the first virtualization system.

13. A computer system (CS), A processor set; a machine-readable storage device; computer code stored on the machine-readable storage device, the computer code causing the processor set to: identifying a first plurality of updates required by a first virtualized computing system; comparing the first virtualized computing system to a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have updates corresponding to the first plurality of updates required by the first virtualized computing system; in response to the comparison, determining an estimated time to complete the first plurality of updates based at least in part on a set of performance characteristics of the first virtualized computing system; identifying a first plurality of errors that occurred during an update of the set of similar virtualized computing systems; preemptively applying configuration changes to the first virtualized computing system in response to the identification of the first plurality of errors. said computer code including instructions and data for carrying out operations including: A computer system (CS).

14. 14. The CS of claim 13, further comprising, in response to the identification of the first plurality of errors that occurred during the update of the set of similar virtualized computing systems, determining that the first plurality of errors does not exceed a first error threshold.

15. 14. The CS of claim 13, wherein the set of performance characteristics of the first virtualized computing system comprises information indicative of computational performance of the first virtualized computing system.

16. 14. The CS of claim 13, wherein the set of performance characteristics of the first virtualized computing system includes information indicative of storage read and / or write performance data of the first virtualized computing system.

17. The CS of claim 13 , further comprising: determining a first amount of time it takes to preemptively apply the configuration change to the first virtualization system.

18. 20. The CS of claim 17, further comprising, in response to the determination, determining using the first amount of time taken to preemptively apply the configuration change as baseline update data for future application of the configuration change to the first virtualization system.

Images