Patching of virtual machines within sequential time windows

A method and associated system for patching virtual machines in L redundancy groups in accordance with a patching schedule. The patching schedule is generated by scheduling, in W sequential time windows, P patches applicable to the virtual machines. Each redundancy group includes virtual machines and independently belongs to a respective software application x of X software applications, wherein P≧1, L≧1, Rm≧1, and X≧1. The L redundancy groups collectively comprise at least 2 virtual machines. The scheduling determines xwmk for T tuples (w, m, k) defined by (w=1, . . . , W) and (m=1, . . . , L) and (k=1, . . . , Rm), by maximizing an objective function subject to constraints. Determining xwmk includes setting xwmk=1 if virtual machine k in redundancy group m is to be patched in time window w or setting xwmk=0 otherwise.

TECHNICAL FIELD

The present invention relates generally to scheduling patches and in particular, to scheduling patches, in sequential time windows, applicable to virtual machines within redundancy groups.

BACKGROUND

Current practice for patching software is inefficient and prone to error.

SUMMARY

The present invention provides a method, and associated system and computer program product, for patching virtual machines in L redundancy groups in accordance with a patching schedule.

A processor of a computer system generates the patching schedule applicable for patching the virtual machines in the L redundancy groups.

Generating the patching schedule includes scheduling, in W sequential time windows, P patches applicable to one or more virtual machines in the L redundancy groups, each redundancy group m (m=1, . . . , L) comprising Rmvirtual machines, each redundancy group m (m=1, . . . , L) independently belonging to a respective software application x of X software applications, wherein P≧1, L≧1, Rm≧1, and X≧1, wherein the L redundancy groups collectively comprise at least 2 virtual machines.

The scheduling of the patching schedule includes determining, by the processor, xwmkfor T tuples (w, m, k) defined by (w=1, . . . , W) and (m=1, . . . , L) and (k=1, . . . , Rm), by maximizing an objective function (F) subject to one or more constraints, wherein determining xwmkcomprises setting xwmk=1 if virtual machine k in redundancy group m is to be patched in time window w or setting xwmk=0 otherwise,

The objective function F is a linear combination of N objective function components Fn(n=1, . . . , N) expressed as F=Σn=1NαnFnsubject to N≧1,

wherein Bxdenotes a business criticality of software application x,

wherein nwmis a total number of virtual machines in redundancy group m assigned to time window w,

wherein nwm=Σk=1Rmxwmk, and

wherein A(x, m, nwm) denotes a residual availability of redundancy group m belonging to software application x when the nwmvirtual machines in redundancy group m are not available in time window w.

DETAILED DESCRIPTION

A virtual machine (VM) is configured to a specific software application in a platform independent manner. In one embodiment, a virtual machine is a server.

A redundancy group comprises one or more virtual machines. Each virtual machine in a given redundancy group is configured to execute the same software application with potentially different configuration. Thus, each given redundancy group is said to belong to the software application that the virtual machines in the given redundancy group are configured to execute.

The present invention schedules, in sequential time windows, patches applicable to one or more virtual machines in one or more redundancy groups. The patching schedule generated in accordance with the present invention is characterized by maximization, subject to one or more constraints, of an objective function. The objective function may differ in different executions of the method of the present invention and reflects business objectives and criticalities.

FIG. 1illustrates scheduling of patching virtual machines of redundancy groups into time windows, in accordance with embodiments of the present invention. Three redundancy groups (group1, group2, group3), which may have its members started and stopped in the right order required for the workload to function properly by a plan10(e.g., a management plan), comprises three VMs in group1, four VMs in group2, and two VMs in group3.

The resultant schedule assigns each VM for placement in (i.e., for being patched within) one time window of the depicted W time windows which are denoted as time window1, time window2, . . . , time window W, wherein W=3 inFIG. 1.

The redundancy groups1,2and3belong to software applications x1, x2and x3, respectively. In one embodiment, software applications x1, x2and x3are different software applications. In one embodiment, two or more software applications of software applications x1, x2and x3are a same software application (e.g., software applications x1, x2and x3may be a same software application; software applications x2and x3may be a same software application differing from software application x1, etc.). Thus, although all VMs in a given redundancy group are configured to execute a same single software application that the given redundancy group belongs to, in some embodiments two or more redundancy groups may belong to a same software application.

In one embodiment, one customer may own, control, and/or use different software applications. In one embodiment, different customers may own, control, and/or use different software applications. In one embodiment, in a multi-tenant cloud, software applications may be hosted on a shared platform, with a single team responsible for patching the VMs of redundancy groups of the different software applications, wherein the time windows during which VMs are patched include VMs from multiple tenants.

The patch advisories received from vendors are patch notifications for selectively patching the VMs.

The freeze times are time intervals (e.g., from time1to time2) during which specifically indicated VMs must not be patched.

Inputs

The following list of symbols are inputs and associated definitions.

P=total number of patches that need to be applied; the patches are indexed by p.

W=total number of future time windows provided for patching; the time windows are indexed by w; the index w also applies to patch categories, since each patch category is applied in an associated time window w; thus the terms “patch category” and “time window” are interchangeable.

L=total number of redundancy groups; the redundancy groups are indexed by m.; may be obtained from a workload definition, may be consumer specified, or could be determined from a configuration management database (CMDB) if available.

Rm=total number of virtual machines in the redundancy group m; the virtual machines in redundancy group m are indexed by k.

ARm=minimum number of virtual machines to be available in redundancy group m for redundancy group m to be available.

Apmk=1 or 0 if the patch p is, or is not, applicable to virtual machine k in redundancy group m, respectively (for application level patches, the consumer may provide information as to whether a non-functional or functional update is applicable for a virtual machine).

Mwmk=1 or 0 if virtual machine k in redundancy group m can, or cannot, be patched in time window w, respectively (a consumer may provide freeze times that determine which time window(s) w are not possible).

f=probability of failure of a virtual machine (e.g., due to operating system).

λwmk=predicted rate of arrival of patching requests in time window w directed to virtual machine k in redundancy group m (the consumer could provide estimates for λwmk).

Rp(w)=risk (between 0 and 1 inclusive) of applying patch p in the time window w (the higher the severity of the patch, the higher the risk; also, the risk increases with the increasing value of w; for application level updates, the risk may be provided by the consumer).

Cw=maximum number of virtual machines that can be patched in time window w.

X=total number of software applications; the software applications are indexed by x.

Bx=business criticality of software application x.

Sxm=1 or 0 if redundancy layer m belongs, or does not belong, to software application x, respectively.

Dmskj=1 or 0 if virtual machine k in redundancy group m should, or should not, be patched in an earlier time window than virtual machine j in redundancy group s, respectively (e.g., patch “test” before “production”). Alternatively, Dmskj=1 or 0 if virtual machine j in redundancy group s should be stopped before virtual machine k in redundancy group m is patched, respectively.

Bmskj(relevant only if Dmskj=1)=minimum time interval (e.g., minimum number of days) between patching virtual machine k in redundancy group m and virtual machine j in redundancy group s.

Outputs

The following list of symbols (also called decision variables) are outputs with associated definitions.

xwmk=1 or 0 if virtual machine k in redundancy group m is, or is not, in time window w, respectively.

cw=1 or 0 if the patch window w is used, or is not used, by any virtual machine in any redundancy group, respectively.

zmk=1 or 0 if virtual machine k in redundancy group m is to be patched, respectively.

Summation Abbreviations

Unless otherwise stated, the following summation abbreviations are defined as follows.Σp=Σp=1PΣw=Σw=1WΣm=Σm=1LΣk=Σk=1RmΣx=Σx=1X

FIG. 2is a flow chart of a method for patching virtual machines, in accordance with embodiments of the present invention. The method ofFIG. 2includes steps21-24.

Step21receives, by a processor of a computer system, inputs, which may include some or all of the inputs identified supra.

The inputs may reflect patch applicability to a particular VM, which may be determined, for example, by running a script to determine if the patch is applicable.

Determining the inputs may use discovery systems (e.g., Tivoli Application Dependency Discovery Manager (TADDM), Configuration Management Database (CMDB)) and/or and asset discovery systems (e.g., IBM Endpoint Manager (IEM) for structure of software applications application and/or patching metadata.

Inputs may be obtained from human specification of high-level parameters and metadata related to patching/upgrade (such as if an upgrade is applicable to software within a VM); humans may also provide missing structure information.

In addition, the inputs may reflect a change in patch categories' metadata, new advisory or approval received for patching a virtual machine and/or a change in software applications and metadata.

The input number of patching windows/categories (W) may depend on the user input on categories dates on which the patching cannot be done; i.e., the matrix Mwmk. The patching will also be governed by the service provider in terms of what is the latest date by which all the patches in the current patch list must be complete. The service provider may introduce new patch categories depending on the backlog of VMs to be patched. In general, there is no limit to the number W and could be chosen as large as is required to optimize the cost function with respect to the constraints including risk of not patching.

Step22generates, by the processor, a patching schedule. Generating the patching schedule comprises scheduling, in W sequential time windows, P patches applicable to one or more virtual machines in L redundancy groups. Each redundancy group m (m=1, . . . , L) comprises Rmvirtual machines. Each redundancy group m (m=1, . . . , L) independently belongs to a respective software application x of X software applications, wherein P≧1, L≧1, Rm≧1, and X≧1, wherein the L redundancy groups collectively comprise at least 2 virtual machines.

Scheduling the patching schedule comprises determining xwmkfor T tuples (w, m, k) defined by (w=1, . . . , W) and (m=1, . . . , L) and (k=1, . . . , Rm), by maximizing an objective function (F), wherein said determining xwmkcomprises setting xwmk=1 if virtual machine k in redundancy group m is to be patched in time window w or setting xwmk=0 otherwise.

In one embodiment, the objective function is maximized subject to one or more constraints, so that the determined values of xwmkare those values of xwmkthat maximize the objective function F subject to the one or more constraints.

In one embodiment, the one of more constraints comprise a freeze time constraint of setting xwmk=0 for t tuples of the T tuples independent of maximizing F, subject to t<T.

Maximizing the objective function (F) subject to one or more constraints may be implemented by any mathematical or numerical technique known in the art for maximizing a function subject to constraints.

The mathematical form(s) of the objective function (F) and maximizing the objective function will be discussed infra.

Step23stores, by the processor, the determined xwmk, for the T tuples, in a data store of the computer system.

Step24patches the virtual machines according to the patching schedule.

FIG. 3is a system diagram for patching virtual machines, in accordance with embodiments of the present invention.

A consumer31provides, to a stop/start scripts database32and a configuration management database (CMDB)33, constraints (e.g., changing freeze times, patch-to-VM applicability, application structure, software start stop scripts, etc.).

Scripts accessed from the stop/start scripts database32are provided to a management environment35for performing orchestrated start and stop of software in virtual machines.

The management environment35provides, to the CMDB, structure of application estimated from monitored and discovered data.

Patch Optimization Problem Generator monitors historical data36.

A service provider34provides, to the CMDB, patch categories, constraints (e.g. number of patches that can be performed per category), weights for the objective functions, etc.

Inputs are provided, from the CMDB to a Patch Optimization Problem Generator37, to generate the optimization problem.

Data obtained from a historical database36(e.g., VM failure probability, request arrival rates to components, etc.) is provided to the Patch Optimization Problem Generator37.

The Patch Optimization Problem Generator37provides inputs to a Schedule Generator38(step21ofFIG. 2).

The Schedule Generator38generates the patching schedule for patching the virtual machines (step22ofFIG. 2).

The patching schedule generated by the Schedule Generator38is used in the Patch Execution Workflow39which is described in more detail inFIG. 4.

Output from the Patch Execution Workflow39(e.g., patches, metadata) may feed back to the Patch Optimization Problem Generator37.

FIG. 4is a flow chart describing a patch execution workflow for patching virtual machines, in accordance with embodiments of the present invention. The flow chart ofFIG. 4describes Patch Execution Workflow39ofFIG. 3in more detail.FIG. 4comprises steps40-49.

Step40obtains the health of VMs in the redundancy group comprising the VM to be patched. The health of a VM determines whether the VM can be executed.

Step41determines whether the redundancy group comprising the VM to be patched is available.

If step41determines that the redundancy group comprising the VM to be patched is available (YES branch), then step42is next executed; otherwise (NO branch) step46is next executed.

Step42determines whether the VM to be patched is the only VM in the redundancy group containing the VM to be patched.

If step42determines that the VM to be patched is the only VM in the redundancy group containing the VM to be patched (YES branch), then step44is next executed; otherwise (NO branch) step43is next executed.

Step43determines whether the minimum availability of the redundancy group comprising the VM to be patched is below a specified or predetermined availability threshold.

If step43determines that the minimum availability of the redundancy group comprising the VM to be patched is below a specified or predetermined availability threshold (YES branch), then step46is next executed; otherwise (NO branch) step44is next executed.

Step46stops patching of the VM to be patched, notifies the owner of the VM to be patched that the minimum availability of the redundancy group comprising the VM to be patched is below the specified availability threshold, and seeks approval from the owner to patch further.

If the owner does not approve patching further, then the process ends; otherwise (owner approves further patching), step44is next executed.

Step44executes stop software workflow for stopping the patching of the VM to be patched.

Step45execute failover to a secondary VM to be patched if a primary VM is being patched and if the secondary VM is required to be patched.

Step47patches the VM to be patched.

Step48executes start software workflow if available.

Step49performs post-patch configuration steps (including fallback to primary VM); then the process ends.

In accordance withFIG. 4, the Patch Execution Workflow includes: (a) an ability to “halt” patching (step46) if the minimum availability is below a specified or determined threshold value (YES branch from step43), (b) automatic stopping of dependent software (step44), and (c) execute failover to a secondary VM if the secondary VM is required to be patched (step45).

The objective function F to be maximized is a linear combination of N objective function components Fn(n=1, . . . , N), wherein N≧1, Thus, the objective function F is of the form:
F=Σn=1NαnFn(1)
wherein αn(n=1, . . . , N) are constants satisfying αn(n=1, . . . , N)≧0 such that at least one of the αnvalues (αn1) is a positive (i.e., αn1>0). The constants αnare weights for the respective objective function components Fn(n=1, . . . , N). The weights αn(n=1, . . . , N) can be adjusted to meet the business requirements. In one embodiment, the weights αnare normalized as follows:
Σn=1Nαn=1  (2)

The present invention may utilize, inter alia, objective function components (Fn) relating to: residual availability decrease (FRAD), unused patch categories (FUPC), fraction of lost patch requests (FFLR) and/or risk due to the patching schedule (FRPS). Thus, the objective function components Fnin Equation (1) may include any or all of FRAD, FUPC, FFLRand FRPS.

Objective Function Component Relating to Residual Availability Decrease (FRAD)

Availability of a redundancy group m belonging to software application x, when nwmVMs are not available, is given by:
A(x, m, nwm)=(1−SxmΣi=ARmRm-nwm(iRm)fi(1−f)Rm-i)  (3)

As VMs are patched in a given redundancy group m, the residual availability of the group m is A(x, m, nwm), wherein nwmis the number of VMs in redundancy group m assigned to the time window w.

The customer defined acceptable availability for redundancy layer m belonging to application x is:
A(x, m,0)=(1−SxmΣi=ARmRm(iRm)fi(1−f)Rm-i).  (4)

The decrease in the availability of application x below an acceptable availability of application x is defined as minw(Πm=1LA(x, m, nwl)−Πm=1LA(x, m, 0)).

Accordingly, the objective function component relating to the residual availability, and also to business criticality Bx, of each application x is:
FRAD=ΣxBxminw(Πm=1LA(x, m, nwm)−Πm=1LA(x, m,0))  (5)
Objective Function Component Relating to Unused Patch Categories (FUPC)

Each patch may require attention of operators so that, in case of an issue with a particular VM being patched occurs (e.g., a VM not rebooting/restarting, etc.), the operator can intervene and remediate. Unused patch categories (i.e., unused time windows) are defined as: (W−Σw=1Wcw).

Accordingly, the objective function component relating to unused patch categories is:
FUPC=W−Σw=1Wcw(6)

As defined supra, cw=1 or 0 if the patch window w is used, or is not used, by any virtual machine in any redundancy group, respectively. It is noted that a patch category w is identified with time window w.

Objective Function Component Relating to Fraction of Lost Patch Requests (FFLR)

If one or more VMs of an application are patched simultaneously, then the capacity of the application decreases. The capacity of the application also depends on which patch categories (i.e., time windows) the VMs are patched in, because if a VM is patched in a patch category where the arrival rate of patches is expected to be higher, then the patch requests potentially lost is also higher.

The fraction of lost patch requests due to patch category w (i.e., time window w) is defined as:
Iw=Σm=1LΣk=1Rmxwmkλwmk/Σw=1WΣm=1LΣk=1Rmλwmk(7)

Thus the fraction of patch requests that are “served” (i.e., not lost) is: Σw=1W(1−Iw).

Accordingly, the objective function component relating to fraction of lost patch requests is:
FFLR=Σw=1W(1−Iw)  (8)
Objective Function Component Relating to Risk Due to the Patching Schedule (FRPS)

If all patches were to be applied in the last patch category w=W (i.e., last time window W), then the total risk would be maximum: ΣxBxΣp,m,kSxmApmkxWmkRp(W)

On the other hand, any other configuration would result in a risk which is less than the maximum risk and is given by: ΣxBxΣp,w,m,kSxmApmkxwmkRp(w). Accordingly, the objective function component relating to risk due to the patching schedule is:

Note that FRPSrelates the business criticality Bxof a software application x to the risk of patching of a VM k of software application x. Thus, higher business criticality of a software application carries higher overall risk for a given p and w.

Constraints

Any or all of the following constraints may be imposed on the process of maximizing the objective function F. All imposed constraints must be satisfied.

A freeze time constraint is setting xwmk=0 for t tuples of the T tuples independent of maximizing F, subject to t<T.

A redundancy group size constraint is:
nwm=Σk=1Rmxwmk(10)

wherein nwmis the number of members of redundancy group m assigned to the patch window w.

A capacity constraint on the number of virtual machines that can be patched in a given window w is:
Cw≧Σm=1Lnwm(11)

If a particular time window w1is not to be used then Cw1is set to 0.

The capacity constraint sets an upper limit of Cwon a number of virtual machines that can be patched in time window w (w=1, . . . , W).

An only one applicable patch category constraint is that virtual machine k of redundancy group m is assigned to one and only one applicable patch window and only if virtual machine k requires patching:
Σw=1WMwmkxwmk=zmk(12)
Σp=1PApmk≧zmk≧Σp=1PApmk/P(13)

A workload only constraint is that a patch window w is considered for a workload only (i.e., software application only) if there is at least one VM assigned to the software application:
cw≧Σm=1Lnwm/Rm(14)

A fraction of lost requests constraint is that the fraction of lost requests Iw(see Equation (7)) must be less than a specified or predetermined fraction of lost quests threshold (Iw-th):
Iw<Iw-th(15)

A patch dependencies constraint is that, for every w, m, k for which there is at least one entry of 1 in Dmskj, which ensures that patch dependencies represented by Dmskjare honoured, is:

A patching between two VMs constraint is that patching between two VMs should be ≧Bmskj:
Σv,u(uxusj−vxvmk)Dmskj≧Bmskj(17)

A minimum objective function constraint is that the objective function F must be equal to or greater than a specified or predetermined minimum F threshold (Fth):
F≧Fth(20)

A computing time constraint is that a total computer time, for determining xwmkthat maximizes the objective function, exceeds a specified or predetermined maximum computer time threshold tmax-th.

EXAMPLE

This example determines a patching schedule (i.e., determining xwmk) using the following inputs.P=2, number of patchesW=2, number of patch windowsL=2, number of redundancy groupsR1=R2=2 (i.e., 2 VMs in each redundancy group)AR1=1, AR2=1 (minimum number virtual machines in each redundancy group that need to be running for the redundancy group to be available)A111=1, A112=1, A121=1, A221=1, A222=1 (applicability of patches to the virtual machines in a redundancy group)M111=1, M211=1, M112=1, M212=1, M221=1, M222=1; remaining elements of Mwmkare 0 (constraints on which virtual machines in a redundancy group can be patched in a window)f:=0.05λ111:=10, λ211:=5, λ112:=5, λ212:=5, λ121:=1, λ221:=10, λ122:=0, λ222:=10R1(1):=0.5, R1(2):=1, R2(1):=0, R2(2):=0.1; the risk of applying a patch p in a window wC1:=1, C2:=10: the number of patches that can be processed in a windowB1:=1, B2:=0.1: the business criticality of application xS11:=1, S22:=1, remaining elements of Sxmare 0: which redundancy group belongs to which applicationDlskj:=0 . . . ; i.e., no dependency between the members of the redundancy group in terms of patching orderBlskj:=0 . . . ; i.e., no constraint on the minimum time interval between patching any two virtual machines

The objective function for this example is the objective function component relating to fraction of lost patch requests (FFLR)—see Equation (8).

This example uses two constraints, namely a capacity constraint (Equation (11)) and an only one applicable patch category constraint (Equations (12)-(13)).

In this example, the scheduling is performed by: (i) determining five potential solution vectors xwmk; (ii) applying the constraints to eliminate some of the potential solution vectors; and (iii) determining which of the remaining solution vectors has the highest value of the objective function.

The five potential solution vectors xwmkare determined by Monte Carlo randomly sampling from a uniform probability distribution in in domain {0,1}; i.e., if the random number is between 0 and 0.5 inclusive xwmk=1; otherwise xwmk=0. The resulting five potential solution vectors xwmk, which are denoted as (a), (b), (c), (d), and (e), are as follows:

The capacity constraint of Cw≧Σm=1Lnwmeliminates potential solution vectors (a) and (b), because C1=1 and in both vectors (a) and (b), and the number of assigned patches to time window1is greater than C1=1, namely 4 for potential solutions (a) and 3 for potential solutions (b).

The only one applicable patch category constraint of Σw=1WMwmkxwmk=zmkand Σp=1PApmk≧zmk≧Σp=1PApmk/P eliminates potential solutions (d), due to restraint imposed by Mwlkon the patching of redundancy group2in time window2.

The next step is to determine which of the remaining potential solution vectors, (c) and (e), maximizes the objective function for this example, which is the objective function FFLRrelating to fraction of lost patch requests; i.e.,
Iw=Σm=1LΣk=1Rmxwmkλwmk/Σw=1WΣm=1LΣk=1RmλwmkandFFLR=Σw=1W(1−Iw).

The following inputs are relevant to this determination: λ111:=10, λ211:=5, λ112:=5, λ212:=5, λ121:=1, λ221:=10, λ122:=0, λ222:=10. If virtual machine1in redundancy group1is patched in window1(potential solution vector (c)) as opposed to virtual machine2in redundancy group1being patched in window1(potential solution vector (e)), then more requests are lost from the users potential solution vector (e) than for potential solution vector (c). Thus, the objective function is smaller for solution (e) than for solution (c). Thus, solution (c) maximizes the objective function for this example.

Various variations of the preceding example are within the scope of the present invention.

In a variation of the preceding example, the three potential solution vectors eliminated by the constraints could be replaced by three additional randomly selected vectors, followed by a determination of whether application of the constraints eliminates any of the three additional randomly selected vectors. Any of the three additional randomly selected vectors eliminated by the constraints would be replaced in the same manner (i.e., by random selection). The preceding iterations would end when five remaining potential solution vectors satisfy all of the constraints. Then the potential solution vector, of the five remaining potential solution vectors, that results in the highest value of the objective function is deemed to be the actual solution vector.

In a variation of the preceding example, an iterative process could be employed. In each iteration, a potential solution vector is randomly chosen, tested against the constraints, and used to compute the value of the objective function if all of the constraints are satisfied. The iterations end upon elapse of a computation time constraint (i.e., if a total computer time for determining xwmkthat maximizes the objective function exceeds a specified or predetermined maximum computer time threshold tmax-th). The actual solution vector is the potential solution vector that has maximum the objective function value as compared with the other potential solution vectors processed during the iterations.

In a variation of the preceding example, all potential solution vectors that are possible (i.e., 16 potential solution vectors in the preceding example) are processed instead of the 5 randomly selected potential solution vectors.

Features

Features of embodiments the present invention are described next.

In one embodiment, general high-availability requirement are mapped to approach specific configuration parameters of a patching service.

In one embodiment, an optimal placement of a VM of a workload to the time windows is determined.

In one embodiment, a business criticality of a patch is included in computing the patching schedule automatically.

In one embodiment, a workload intensity is included in computing the patching schedule automatically.

In one embodiment, a redundancy in the workload is used to compute the patching schedule automatically.

In one embodiment, a patching schedule that maximizes the residual availability of the system is automatically computed.

In one embodiment, the probability of failure of a VM to application of patches is automatically computed; the probability could be estimated from the history from similar VMs.

In one embodiment, a patching decision is associated to system automation software to help in failover (if required).

In one embodiment, input on which patching schedules are not allowed for the customer's workload and the minimum time between patching of any two VMs are included.

In one embodiment, a health check of the VMs other than the VM being patched in a redundancy group is performed and the patching is stalled if all the other VMs are down; if this VM is the only VM in a redundancy group, then the patching will continue.

In one embodiment, a variable number of patch windows is allowed.

In one embodiment, a workload definition could be TOSCA, HOT, etc.

In one embodiment, the patch schedule is dynamically recomputed as the existing workload properties change or a new workload introduced.

In one embodiment, the patching schedule is determined whenever a new patch advisory is received, since an arrival of a new patch advisory may affect the optimality of the patching schedule. The computation of the patching schedule may be synchronized with the timetable of application of patches by the Patch Execution Workflow component. Whenever a new patch is added to the list of patches P, or an approval for patching a server is obtained, or the number of currently available patch windows (W) changes, or the software applications within X change, or a new software application instance is introduced, or a change in freeze times, then the following procedure is executed for X software applications.

In one embodiment, if a new patch is added to P, then: Rp(w) is updated and the matrix that holds the risk function associated with the new patch (and how the risk grows if the patch) is delayed to be applied.

In one embodiment, the present invention identifies for every software application x in X:

(i) For each new patch in P, patch applicability to x is computed; i.e., matrix A is updated based on the new advisory. The applicability of the new patch to x would be actually be computed by the existing patch automation, such as IEM. For a patch that is an application level patch then the applicability is obtained from other sources (e.g., development environments) such as the consumer itself.

(ii) Matrix Mwlkis updated based on user constraints on whether a VM should be patched or not in a patch window w.

(iii) Matrix Dmskjis updated based on new dependencies introduced.

Placement of each VM in the available patch windows is determined by solving the optimization problem of minimizing the objective function. Once the patching schedule has been computed, the patching schedule is passed to the Patch Execution Workflow engine which may further decide when to schedule the patch updates based on the patching schedule. The Patch Execution Workflow updates the data structures once a VM has been patched.

Computer System

FIG. 5illustrates a computer system90used for patching virtual machines, in accordance with embodiments of the present invention. The computer system90comprises a processor91, an input device92coupled to the processor91, an output device93coupled to the processor91, and memory devices94and95each coupled to the processor91. The input device92may be, inter alia, a keyboard, a mouse, etc. The output device93may be, inter alia, a printer, a plotter, a computer screen, a magnetic tape, a removable hard disk, a floppy disk, etc. The memory devices94and95may be, inter alia, a hard disk, a floppy disk, a magnetic tape, an optical storage such as a compact disc (CD) or a digital video disc (DVD), a dynamic random access memory (DRAM), a read-only memory (ROM), etc. The memory device95includes a computer code97which is a computer program that comprises computer-executable instructions. The computer code97includes software or program instructions that may implement an algorithm for patching virtual machines. The processor91executes the computer code97. The memory device94includes input data96. The input data96includes input required by the computer code97. The output device93displays output from the computer code97. Either or both memory devices94and95(or one or more additional memory devices not shown inFIG. 5) may be used as a computer usable storage medium (or program storage device) having a computer-readable program embodied therein and/or having other data stored therein, wherein the computer readable program comprises the computer code97. Generally, a computer program product (or, alternatively, an article of manufacture) of the computer system90may comprise said computer usable storage medium (or said program storage device).

Thus the present invention discloses a process for supporting, deploying and/or integrating computer infrastructure, integrating, hosting, maintaining, and deploying computer-readable code into the computer system90, wherein the code in combination with the computer system90is capable of performing a method for patching virtual machines.

In another embodiment, the invention provides a method that performs the process steps of the invention on a subscription, advertising, and/or fee basis. In this case, the service provider can create, integrate, host, maintain, deploy, manage, service, support, etc., a computer infrastructure that performs the process steps of the invention for one or more customers. In return, the service provider can receive payment from the customer(s) under a subscription and/or fee agreement and/or the service provider can receive payment from the sale of advertising content to one or more third parties.

A computer program product of the present invention comprises a computer readable hardware storage device having computer readable program code stored therein, said program code containing instructions executable by a processor of a computer system to implement the methods of the present invention.

A computer system of the present invention comprises a processor, a memory, and a computer readable hardware storage device, said storage device containing program code executable by the processor via the memory to implement the methods of the present invention.