Reducing downtime caused by incompatibility issues resulting from 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 specifically to maintaining and operating a virtualized computing system to properly run enterprise solutions.

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

[0003] According to one aspect of the present invention, there exists a method, computer program product, or system or a combination thereof that performs the following operations (not necessarily in the following order): (i) identifying a first set of updates required by a first virtualized computing system; (ii) comparing the first virtualized computing system with a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have performed updates equivalent to the first set of updates required by the first virtualized computing system; (iii) in response to the comparison, determining an estimated time to complete the first set of updates, at least in part, based on a set of performance characteristics of the first virtualized computing system; (iv) identifying a first set of errors that occurred during the updates of the set of similar virtualized computing systems; and (v) in response to the identification of the first set of errors, proactively applying configuration changes to the first virtualized computing system. [Brief explanation of the drawing]

[0004] [Figure 1] This is a block diagram of a first embodiment of the system according to the present invention. [Figure 2] This flowchart shows the method of the first embodiment, at least partially performed by the system of the first embodiment. [Figure 3] This is a block diagram showing the mechanical logic (e.g., software) portion of the system according to the first embodiment. [Figure 4] This is a block diagram of a first embodiment of the system according to the present invention. [Figure 5] This is a flowchart showing a first embodiment of the method according to the present invention. [Figure 6] This is a flowchart showing a second embodiment of the method according to the present invention. [Figure 7] This is a flowchart showing a third embodiment of the method according to the present invention. [Figure 8] This is a flowchart showing a fourth embodiment of the method according to the present invention. [Figure 9] This is a block diagram showing a second embodiment of the system according to the present invention. [Modes for carrying out the invention]

[0005] The section on embodiments for carrying out this invention is divided into the following subsections: (i) hardware and software environment, (ii) exemplary embodiments, (iii) further supplementary explanations or embodiments or both, and (iv) definitions.

[0006] I. Hardware and Software Environment The present invention may be a system, method, or computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or a set of mediums) having computer-readable program instructions for causing a processor to execute an aspect of the present invention.

[0007] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, but is 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 enumeration 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 disks (DVDs), memory sticks (R), floppy disks (R), mechanically encoded devices such as punched cards or grooved structures on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through 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 external 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 fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. The network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0009] The computer-readable program instructions for performing the operation 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 code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk(R) and C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may run entirely on the user's computer, partially on the user's computer, as a standalone 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 to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can be personalized by executing computer-readable program instructions by utilizing state information of computer-readable program instructions in order to perform aspects of the present invention.

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

[0011] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to create a machine, such that instructions executed via the processor of a computer or other programmable data processing device create means for performing functions / operations specified in one or more blocks of a flowchart or block diagram, or both. These computer-readable program instructions may also be stored on a computer-readable storage medium on which the instructions are stored, so as to include a product containing instructions that perform modes of functions / operations specified in one or more blocks of a flowchart or block diagram, or both, and can be used to instruct a computer, a programmable data processing device, or other device or a combination thereof to function in a particular manner.

[0012] Computer-readable program instructions may also be loaded into a computer, another programmable device, or another device to create a process that is implemented by the computer, another programmable device, or another device, so that the instructions executed by the computer, another programmable device, or another device implement a function / operation specified in one or more blocks of a flowchart or block diagram, or both, causing the computer, another programmable device, or another device to execute a series of operational steps.

[0013] The flowcharts and block diagrams in the drawings 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 a flowchart or block diagram may represent a module, segment, or part of an instruction, which contains one or more executable instructions for performing a specified logical function. In some alternative implementations, the functions described in a block may occur out of the order shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order depending on the functions they relate to. It should also be noted that each block in a block diagram or flowchart, or both, and combinations of blocks in a block diagram or flowchart, or both, may be implemented by a dedicated hardware-based system that performs a specified function or operation, or performs a combination of dedicated hardware and computer instructions.

[0014] Next, embodiments of possible hardware and software environments for the software or method or both 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 representative in many respects of the various computer subsystems in the present invention. Therefore, some parts of subsystem 102 will be 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), smartphone, or any programmable electronic device capable of communicating with the client subsystem via network 114. Program 300 is a collection of machine-readable instructions and / or data used to create, manage, and control specific software functions, which are described in detail below in the Exemplary Embodiments subsection of the Modes for Carrying Out the Invention.

[0017] Subsystem 102 can communicate with other computer subsystems via network 114. Network 114 can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and can include wired, wireless, or fiber optic connections. In general, network 114 can be any combination of connections and protocols that support communication between server subsystems 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 communication fabric that provides communication between the various components of subsystem 102. This communication fabric can be implemented using any architecture designed to pass data or control information, or both, between processors (microprocessors, communication and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, the communication fabric can be implemented using at least partially one or more buses.

[0019] Memory 208 and persistent storage 210 are computer-readable storage media. Generally, memory 208 may include any suitable volatile or non-volatile computer-readable storage media. Furthermore, it should be noted that, currently, in the near future, or both, (i) an external device 214 may supply some or all of the memory to subsystem 102, or (ii) a device outside subsystem 102 may provide memory to subsystem 102, or both.

[0020] The program 300 is stored in persistent storage 210, typically for access or execution, or both, by one or more of the respective computer processors 204, via one or more of the memories 208. The persistent storage 210 (i) is more persistent than signals in transmission, (ii) stores the program (including its soft logic and / or data) in 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 or permanent or both than the type of storage provided by persistent storage 210.

[0021] The program 300 may include both machine-readable and executable instructions, substantial data (i.e., types of data stored in a database), or both. In this specific embodiment, the persistent storage 210 comprises a magnetic hard disk drive. To list some possible variations, the persistent storage 210 may comprise a solid-state hard drive, a semiconductor memory 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] Furthermore, the medium used by the persistent storage 210 may be removable. For example, a removable hard drive may be used for the persistent storage 210. Other examples include optical disks, magnetic disks, thumb drives, and smart cards, which are inserted into a drive for transfer to another computer-readable storage medium that also forms part of the persistent storage 210.

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

[0024] The I / O interface set 206 enables data input and output with other devices that may be locally connected to the server computer 200 for 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, keypad, touchscreen, or any other suitable input device or combination thereof. The external device set 214 may also include portable computer-readable storage media such as a thumb drive, portable optical or magnetic disk, and memory card. Software and data used to practice embodiments of the present invention, such as program 300, may be stored on such portable computer-readable storage media. In these embodiments, the relevant software may be loaded (or not loaded) entirely or partially onto the persistent storage device 210 via the I / O interface set 206. The I / O interface set 206 also connects to the display device 212 for data communication.

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

[0026] The programs described herein are identified based on the application in which they are intended to be implemented in particular embodiments of the present invention. However, it should be understood that the nomenclature of specific programs herein is used merely for convenience, and therefore the present invention should not be limited to use only in the specific application identified, implied, or both by such nomenclature.

[0027] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be exhaustive or limitful to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used herein have been selected to best describe the principles, practical applications, or technical improvements to the technologies available on the market of the embodiments, or to enable those else skilled in the art to understand the embodiments disclosed herein.

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

[0029] The process begins in operation S255, when the update identification module ("mod") 305 identifies a set of updates required by the virtualized computing system.

[0030] The process proceeds to operation S260, in which the comparison virtualization computing system mod310 compares the virtualization computing system (as described in relation to operation S255 above) with a set of virtualization computing systems (which may be referred to herein as a set of benchmark virtualization computing systems) that have been previously used, previously identified, or both. In some embodiments of the present invention, this comparison is performed to determine a set of virtualization computing systems that have made updates similar to those identified as needing to be made by the virtualization computing system (as described in relation to operation S255 above).

[0031] The process proceeds to operation S265, where the update time estimate mod315 determines an estimated amount of time to complete the identified update. In some embodiments of the present invention, the update time estimate mod315 records a first estimated amount of time so that it can be used as a baseline time for future updates. For example, if a 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 performed in an efficient manner.

[0032] The process proceeds to operation S270, where error identification mod320 identifies a set of errors that occurred during the update process of a 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, identification mod320 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, a future update with a higher number of errors than the original may be considered less accurate than a future update with a lower number of errors than the original.

[0033] Finally, the process proceeds to operation S275, in which the configured virtualized computing system mod325 preemptively applies the configuration changes to the virtualized computing system (as described in relation to operations S255 and S260 above).

[0034] III. Further Supplementary Descriptions or Embodiments, or both. Embodiments of the present invention generally relate to updating system firmware and operating systems in a virtualized environment within a data center. The server / system is virtualized using a hypervisor and supported by a special type of virtual machine called a virtual I / O server (VIOS). A hypervisor is computer software or firmware that enables the creation of multiple virtual machines (VMs) running a given operating system and allows 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 acts as a hosting VM, responsible for sharing physical I / O resources, namely storage adapters 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. These virtual I / O resources are then used by the virtual machines to perform I / O operations. Given the above context, embodiments of the present invention will be further described below using this terminology.

[0035] In virtualized environments as described above, when firmware updates, VIOS updates, or OS updates are performed, there is always a possibility that newer updates, levels, or features may not be compatible with the existing configuration of the virtualized environment. In such scenarios, incompatibilities may exist across the entire stack after the update, and downtime may be required to change settings and make configuration changes. Furthermore, the time required for an update varies depending on (i) the number of subsystems in the stack that need updating, (ii) the calculation of the total time required for all these updates, and (iii) the maintenance time plan relative to the exact total time required (it becomes problematic if it is longer than required).

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

[0037] Embodiments of the present invention provide an algorithm for parsing a README file and certain command output associated with a corresponding component or subsystem to check prerequisites. This algorithm also checks compatibility between different levels of these subsystems. While a management console may be able to perform this check for firmware updates, OS and VIOS updates initiated via the management console require an additional mechanism for the OS / VIOS to interact with the management console via the hypervisor to perform verification operations before proceeding with the update or upgrade.

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

[0039] The solution involves documenting the number of systems reporting a particular configuration. Furthermore, if a system has a problem, the configuration of the system reporting the problem should be documented and remembered. If a system has a problem with a certain configuration, this problem should be noted as a negative value for that configuration when calculating the best recommended configuration. Information regarding the time required for updates or upgrades should be transmitted via call home data, and this information will be used to improve the baseline data for update / upgrade times for each subsystem. Furthermore, this baseline data will be used to improve the accuracy of update time calculations.

[0040] In some embodiments, the management console fetches necessary information and new versions of existing configurations and performs appropriate validation. These validations and results are fed into a learning model, and data on failures after updates is collected and fed back into the model, allowing for continuous improvement of the validation process. When proposing 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 configurations.

[0041] In some embodiments, data collected as part of call home or telemetry is enhanced to transmit information such as configuration level, issues observed in the environment, SRC indicating the issue, and the time required for updates or upgrades or both.

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

[0043] (1) Management console: When updating the management console, in addition to checking the prerequisites at the management console level, the firmware, VIOS, OS, and any management consoles within the HA configuration or pool model are also checked.

[0044] (2) Firmware / Hypervisor: The management console performs a configuration compatibility check with the new level.

[0045] (3) Virtual I / O server: When a VIOS update is initiated, VIOS begins communicating with the management console via the hypervisor to check for compatibility.

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

[0047] Embodiments of the present invention provide a method for estimating upgrade time and mitigating errors when updating a computing system. The operation of this method includes, but is not limited to, (i) identifying the updates required by the system; (ii) comparing the system to be updated with other systems to determine similar systems that have already undergone similar updates; (iii) predicting the time required to complete the update based on the performance characteristics of the system to be updated, the performance characteristics of similar systems that have already been updated, and the time it takes to update the similar systems; (iv) identifying errors that occurred when updating similar systems and corresponding error solutions; and (v) proactively applying configuration changes or other error solutions to the system to be updated (and not necessarily in this order).

[0048] Embodiments of the present invention provide a cognitive upgrade process for estimating upgrade time and upgrade risk adjustments. 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 failure risk that may result in significant interruptions and downtime.

[0049] To perform appropriate estimations, 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 actions (not necessarily in the following order):

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

[0052] (2) For the stack to be upgraded, the “difference” between the current state and the desired state is determined by considering the complete set.

[0053] (3) Remove the differences that have been resolved, and for each difference, identify peer groups that have similar properties to the stack of interest. The nearest neighbor algorithm is used to identify peer groups at each step. Similarity is based on the complete set of packages.

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

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

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

[0057] (6) Using supervised machine learning techniques, an ensemble of ML algorithms is constructed to predict the estimated time required to upgrade TCP from version 1 to version 2 at regular intervals (e.g., 30 minutes + / - 2 minutes). The features used in supervised learning consist of the performance characteristics of each stack within the peer group and the upgrade time for each stack for each difference.

[0058] (7) Repeat the above steps for each difference, and generate an upgrade time prediction for each step.

[0059] (8) Use a similar method, but consider all differences at once to predict the total time. In this case, the peer group will have successfully received all stack upgrades.

[0060] (9) Create aggregated forecasts based on individual differences.

[0061] (10) Use an ensemble of ML algorithms to predict the upgrade time for each step and the time for the entire upgrade process.

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

[0063] Some embodiments of the present invention use methods 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 this end, some embodiments utilize historical data in system log format available to peer groups, and customer support ticket information available to relevant proprietary entities. In some embodiments, text mining techniques are used to identify the causes of failure and recommend mitigation measures. Furthermore, 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 the following order): (i) providing an overview of what to expect, including the total estimated time and possible recommendations for improving the time (e.g., temporarily purchasing more computing resources via Capacity on Demand (COD)), risk assessment and risk mitigation recommendations, and a detailed breakdown of each step, including upgrade time and risk; (ii) proceeding with each action based on user confirmation; and (iii) forecasting the 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 utilize a cognitive upgrade assistant. The cognitive upgrade assistant includes (i) a chatbot that guides the administrator through the upgrade process, and (ii) input to the chatbot. The input to the chatbot includes (a) a README file created using a template for registering dependencies, (b) command-line output (for chatbots running on a server), (c) stack history service data, and (d) service data from other clients having similar configurations and already performing 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) collecting necessary contextual data stored locally on the stack; (ii) integrating relevant external information for the stack from “peer groups” in a contextual manner; (iii) displaying missing prerequisites and risks; (iv) displaying estimated times along with confidence levels; and (v) guiding the administrator through the upgrade process using the information already collected and through interaction 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] Figure 400, a virtualization environment diagram, provides a graphical representation of the virtualization environment used in embodiments of the present invention. Figure 400 includes the following components: a management console 402, a system / server 404, a hypervisor 406, a virtual machine 1 (VM1) 408, a virtual machine 2 (VM2) 410, and a VIOS 412.

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

[0069] Flowchart 600 in Figure 6 provides a graphical representation of the stack-level recommendation upgrade assistant model. Figure 600 includes input 602, the upgrade assistant 604, and the stack-level recommendation 608. Regarding input 602, there are two types of inputs: static input 608 and dynamic input 610. The static input (608) includes a readme file (612) with a specific template format and versioning, and test results (614) containing information indicating version compatibility. The dynamic input (610) includes SRC, call home data, configuration information from cases, and configuration-related issues (616), service data (618) from different clients with similar virtualization environments, and stack history service data (620). A stack level recommendation (606) includes the level (or tier) to be updated (622), suggestions such as N, N-1, N-2 (624), an estimated update time (626), the update order (628), the number of customers using the stack in the field (630), and the duration for which the level (or tier) was used in the environment.

[0070] Flowchart 700 in Figure 7 provides a graphical representation of the upgrade or update or both process. This process includes the user initiating an update or upgrade (702), which is then sent to the upgrade assistant (704). The upgrade assistant initiates a communication request with the management console and collects necessary contextual information from the stack (706). This contextual information is then combined with relevant external information from peer groups designed to be used with the stack (708). Through this contextual information, upgrade / update recommendations and prerequisites are obtained (710). Next, an estimated time for the update or upgrade is 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 this data is sent back to the upgrade assistant (716).

[0071] Flowchart 800 in Figure 8 provides a graphical representation of alerts and notifications for the update / upgrade process. The user configures the scheduler to check for problems in the current configuration and known problems at the desired destination level (or tier) (802). Information received from the scheduler is sent to the upgrade assistant (804). The upgrade assistant uses a machine learning model to continuously collect static and dynamic inputs (similar to, or the same as, the static and dynamic inputs described in relation to Figure 6 above) (806).

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

[0073] The block diagram 900 in Figure 9 provides a graphical representation of the power virtualization and management model. The 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, OS1 (operating system 1) 920, OS2 (operating system 2) 922, OS3 (operating system 3) 924, VIOS 926, FSP 928, PSU 930, 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 present invention, the operating system used may include a proprietary operating system (such as OS1 920, OS2 922, or OS3 924 or a combination thereof).

[0074] IV. Definition The Invention: The term "the Invention" should not be taken as an absolute indication that the subject matter described herein is subject to either the claims at the time of filing or the claims that may ultimately be issued after patent examination. While the term "the Invention" is used to facilitate readers in gaining a general sense of confidence that the disclosure herein is potentially novel, this understanding indicated by the use of the term "the Invention" is provisional and may change during the patent examination process as relevant information evolves and the claims may be amended.

[0075] Embodiments: See the definition of “the present invention” above. Similar notes apply to the term “embodiments.”

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

[0077] Includes, contains: Unless otherwise explicitly stated, this means "includes, but is not necessarily limited to."

[0078] User / Subscriber: This includes, but is not limited to, (i) an individual, (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 a combination thereof.

[0079] Data communication: Any type of data communication method currently known or to be developed in the future, including wireless communication, wired communication, and communication routes having both wireless and wired components. Data communication is not necessarily limited to (i) direct data communication, (ii) indirect data communication, and / or (iii) data communication in which the format, packetization status, medium, encryption status, and / or protocol remain constant throughout the entire process of data communication.

[0080] Receive / provide / send / input / output / report: Unless otherwise explicitly stated, these words should not be interpreted as implying (i) a certain degree of directness regarding the relationship between its object and subject, and / or (ii) the absence of any intermediate components, actions, and / or things intervening between its 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 performing a complex operation and a human switching the computer to an alternative power source due to a power grid outage to ensure the operation continues without interruption; (ii) a computer attempting to perform a resource-intensive operation and a human confirming that the resource-intensive operation actually needs to be started (in this case, the confirmation process requires a simple yes / no confirmation by a human, but if considered separately, it involves substantial human intervention, although the resource-intensive operation itself does not involve any substantial human intervention); and (iii) a computer using machine logic making an important decision (e.g., a decision to ground all aircraft in anticipation of bad weather), but before carrying out that important decision, the computer needs to obtain a simple yes / no confirmation from a human source.

[0082] Automatically: Without any human intervention.

[0083] Module / Submodule: Any set of hardware, firmware, or software, or any combination thereof, that is operationally configurable to perform a certain function, whether the module is (i) in a single local neighborhood, (ii) geographically distributed, (iii) in a single neighborhood 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 communications, or any combination thereof.

[0084] Computer: Any device having the capability to process significant data or read machine-readable instructions, or both, including, but not limited to, desktop computers, mainframe computers, laptop computers, field-programmable gate array (FPGA)-based devices, smartphones, personal digital assistants (PDAs), wearable or implantable computers, embedded computer devices, and application-specific integrated circuit (ASIC)-based devices.

Claims

1. A method performed by a computer, Identifying a set of first updates required by the first virtualized computing system, The first virtualized computing system is compared with a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have undergone updates equivalent to the first set of updates required by the first virtualized computing system, In response to the comparison, the estimated time to complete the first set of updates is determined, at least in part, based on the performance characteristics of the first virtualization computing system. Identifying a set of first errors that occurred during the update of the aforementioned set of similar virtualization computing systems, In response to the identification of the first plurality of errors, the configuration changes are proactively applied to the first virtualized computing system. Methods that include...

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

3. The method according to claim 1, wherein the set of performance characteristics of the first virtualized computing system includes information indicating the computational performance of the first virtualized computing system.

4. The method according to claim 1, wherein the set of performance characteristics of the first virtualized computing system includes information indicating storage read or write performance data or both of the first virtualized computing system.

5. The method according to claim 1, further comprising determining such first amount of time to proactively apply the configuration change to the first virtualization system.

6. The method of claim 5, further comprising using such first amount of time to proactively apply the configuration change in response to the decision, to determine as baseline update data for future application of the configuration change to the first virtualization system.

7. It is a computer program, The processor set includes, Identifying a set of first updates required by the first virtualized computing system, The first virtualized computing system is compared with a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have undergone updates equivalent to the first set of updates required by the first virtualized computing system, In response to the comparison, the estimated time to complete the first set of updates is determined, at least in part, based on the performance characteristics of the first virtualization computing system. Identifying a set of first errors that occurred during the update of the aforementioned set of similar virtualization computing systems, In response to the identification of the first plurality of errors, the configuration changes are proactively applied to the first virtualized computing system. A computer program that causes an action to be performed, including the action of [the specified action].

8. The computer program according to claim 7, further comprising determining, in response to the identification of the first plurality of errors occurring during the update of the set of similar virtualized computing systems, that the first plurality of errors do not exceed a first error threshold.

9. The computer program according to claim 7, wherein the set of performance characteristics of the first virtualized computing system includes information indicating the computational performance of the first virtualized computing system.

10. The computer program according to claim 7, wherein the set of performance characteristics of the first virtualized computing system includes information indicating storage read or write performance data or both of the first virtualized computing system.

11. The computer program according to claim 7, further comprising determining such first amount of time to proactively apply the configuration change to the first virtualization system.

12. The computer program according to claim 11, further comprising using such first amount of time to proactively apply the configuration change in response to the decision, to determine as baseline update data for future application of the configuration change to the first virtualization system.

13. A computer system, Processor set and Machine-readable memory devices and, Computer code stored on the machine-readable storage device, wherein the computer code is used by the processor set. Identifying a set of first updates required by the first virtualized computing system, The first virtualized computing system is compared with a set of benchmark virtualized computing systems to determine a set of similar virtualized computing systems that have undergone updates equivalent to the first set of updates required by the first virtualized computing system, In response to the comparison, the estimated time to complete the first set of updates is determined, at least in part, based on the performance characteristics of the first virtualization computing system. Identifying a set of first errors that occurred during the update of the aforementioned set of similar virtualization computing systems, In response to the identification of the first plurality of errors, the configuration changes are proactively applied to the first virtualized computing system. The computer code includes instructions and data for performing an operation including A computer system that includes [a certain feature].

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

15. The computer system according to claim 13, wherein the set of performance characteristics of the first virtualized computing system includes information indicating the computational performance of the first virtualized computing system.

16. The computer system according to claim 13, wherein the set of performance characteristics of the first virtualized computing system includes information indicating storage read or write performance data or both of the first virtualized computing system.

17. The computer system according to claim 13, further comprising determining such first amount of time to proactively apply the configuration change to the first virtualization system.

18. The computer system according to claim 17, further comprising using such first amount of time to proactively apply the configuration change in response to the decision, to determine as baseline update data for future application of the configuration change to the first virtualization system.

Images