WO2012079886A1

WO2012079886A1 - A method computer program and system for managing cooperation between virtual machine applications

Info

Publication number: WO2012079886A1
Application number: PCT/EP2011/070081
Authority: WO
Inventors: Giuseppe Ciano; Luigi Pichetti; Marcin Mirecki
Original assignee: International Business Machines Corporation
Priority date: 2010-12-14
Filing date: 2011-11-14
Publication date: 2012-06-21

Abstract

A method for automatically performing configuration actions on a virtual machine running a first application by collecting information from one system running in production mode a second application the configuration action allowing the first and second application to cooperate, said method comprising creating a publishing surrogate socket on behalf of the production system by importing the socket model of the virtual machine and completing with all the necessary system information. The virtual machine having a plug role for the published socket uses the published socket information to perform the configuration actions as described in the corresponding VM plug.

Description

D E S C R I P T I O N

A METHOD COMPUTER PROGRAM AND SYSTEM FOR MANAGING COOPERATION BETWEEN VIRTUAL MACHINE APPLICATIONS

Field of Invention

This invention generally relates to virtual machine management and in particular to a method and system for automatically configuring virtual machines for installation of virtual appliances in a virtual environment.

Background Art

Virtual appliances are Virtual Machine images comprising at least one software application and at least one Virtual Machine (VM) . A virtual appliance can be directly installed on a Virtual Machine Monitor operating on a physical machine. Virtual appliance is a new way of deploying software applications .

From a software packaging and distribution point of view, virtual appliance allow software developers to create a single platform, reducing the cost and complexity of software development and management. Virtual appliances are provided to the user or customer as files, via either electronic downloads or physical distribution. By distributing virtual appliances, the software application manufacturers deliver a turnkey software service to the end user.

Over the past decades, virtual appliances has become more and more complex. On the other hand, whereas current virtual appliances contain a single VM, modern enterprise applications implement a service oriented architectures (SOA) model with multiple tiers, where each tier contains one or more machines. A single VM model is thus not sufficient to distribute a multi-tier service as virtual appliance. For example, a typical web application may consist of three tiers: a web tier that implements the presentation logic, an application server tier that implements the business logic and a back-end database tier. A straightforward implementation would divide this into 3 virtual machines, one for each tier. In this way, the application can scale from the fraction of a single physical host to 3 physical hosts.

As a consequence of the complexity of virtual appliances, the deployment of these virtual appliances has turned to be even more complex. Indeed, in a virtual datacenter, the deployment and the dismissal of complex appliances require multiple configuration steps to be executed in order to make the virtual appliance up and running. These configuration steps include:

- Reconfiguration needed to assign OS specific parameters like for example network information: IP, hostname ...

Reconfiguration to establish/remove the communication between :

o different components of the same product running in different Virtual Machines

o different products running in different Virtual Machines

Today vertical software stack reconfiguration is performed manually or by invoking predefined scripts with static values in input using the API provided by the Virtual Machine Monitor to manage the Virtual Machines. One example of such API is VIX API for communicating with the VMware Virtual Machine Monitor (VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other juridictions) .

The problem of automatic configuration of the application components or applications to allow their cooperation becomes more complex if a virtual appliance is installed in a complex virtual environment in which existing virtual machines in production need also to be reconfigured, or the virtual appliance is installed and it has to be connected to an existing system (virtual or physical) without changing it, in a way which is not intrusive. For instance, it is not possible to install a new software for handling automatic configuration changes in virtual machines which are production virtual machines.

Summary of the Invention

It is an object of the present invention to provide a method and system for allowing cooperation between the application components or applications included in virtual machines at installation or removal of a virtual appliance and in systems running in production mode without modifying the software stacks of said production systems.

The object is reached, according to claim 1 with a method for automatically allowing configuration actions to be performed on a virtual machine running a first application, the first application cooperating with a second application running on a system said method comprising:

retrieving from the virtual machine a socket model for cooperation between said first and second applications, said socket model describing configuration information to be collected from the system;

- publishing said socket model on a repository; updating the socket model by adding configuration information concerning the system.

The object is also reached, according to claim 2, with the method of claim 1 further comprising

retrieving the published updated socket model from the repository;

retrieving from the virtual machine a plug model corresponding to the retrieved socket model; and,

- performing on the virtual machine the configuration actions described in the retrieved plug model using the added configuration information concerning the system.

The object is also reached, according to claim 3, with the method of claim 1 or 2 wherein the updating step comprises previously receiving said configuration information concerning the system from a user

The object is also reached, according to claim 4, with the method of claim 1 or 2, wherein the updating step comprises previously collecting said information from the production system by executing a pre-defined script.

The object is also reached, according to claim 5, with the method of claim 1 or 2, wherein the updating step comprises previously collecting the information from a database repository.

The object is also reached, according to claim 6, with the method of any one of claims 1 to 5 wherein it further comprises generating a VM event to notify each publication of an updated socket model for the system and wherein said updating step previously comprises collecting at the virtual machine the VM events to check if an updated socket model for the socket model has been already published on the repository.

The object is also reached, according to claim 7, with the method of any one of claims 1 to 6 wherein :

- the publishing step further comprises tagging the published socket model with the configuration environment associated in the virtual machine to the plug and socket models; and,

- the updating step comprising an initial step of selecting the information from the system associated to the same configuration environment.

The object is also reached, according to claim 8, with the method of any one to claim 1 to 7 wherein the steps are performed by an external automation using a command line interface .

The object is also reached, according to claim 9, with the method of any one to claim 1 to 8 wherein the steps are performed through a user interface.

The object is also reached, according to claim 10, with the method of any one of claims 1 to 9 wherein the system is a virtual machine running in production mode.

The object is also reached, according to claim 11, with the method of any one of claims 1 to 9 wherein the system is a physical machine running in production mode. The object is also reached, according to claim 12, with a system comprising means adapted to carry out the steps of the method according to any one of the preceding claims. The object is also reached, according to claim 13, with a computer program comprising instructions for carrying out the steps of the method according to any one of claims 1 to 10 when said computer program is executed on a computer.

Reference to the drawings

Figure 1 illustrates the automatic management cooperation between software application components applications located in new virtual machines;

Figure 2 illustrates a second embodiment of the automatic management of cooperation between software application components or applications located in virtual machines;

Figure 3 illustrates the automatic maintenance cooperation between software application components applications when virtual machines are in production mode;

Figure 4 shows one example of socket and plug parameters used to manage cooperation between application components or applications located in new virtual machines and production mode systems according to the method of the preferred embodiment ;

Figure 5 is the general flowchart of the method of the invention according to the preferred embodiment.

Detailed description of the preferred embodiment

There is thus a need for automatically configuring the virtual machines coming from installation or removal of virtual appliances. The not yet published international patent application EP2010/067592 describes a way to automatically starts cooperation between components of a same software application provided in different virtual machines or cooperation between different software application running in different virtual machines. This is done by a cooperation engine provided with software application virtual machines which uses a socket-plug protocol to automatically allows cooperation between application components or applications. Once the application components or applications have been activated in their respective virtual machines the cooperation engine publishes socket and plug information in an external cooperation repository. The repository is also used to maintain the current status of the different VM sockets and plugs during the VM cycle life. The already existing solution allows to automatically manage cooperation between application components or applications in new virtual machines when a new virtual appliance is installed or when VMs are activated or desactivated in the virtual data center. This is done by establishing between the new virtual machines a (socket-plug based) communication to transmit between them configuration operations to allow cooperation betwen the applications or application components running on these virtual machines. The solution is implemented on each VM by a cooperation engine and an input file containing pre-modeled socket-plug role descriptions, the cooperation engine preparing and publishing socket information in an external cooperation repository. The same engine looks also for a published socket in the cooperation repository which corresponds its VM plug role in order to execute its configuration operations.

This pre-existing solution cannot allow already existing systems running applications in production mode to participate in this socket publication. The existing solution uses a cooperation engine included in the VM shipped image as well as a pre-modeled cooperation socket and plug role description. This solution is intrusive and not convenient if extended to existing systems running in production mode, the brownfield systems such as back-end servers already existing in the customer environment, like an LDAP or a database server.

With the solution of the invention a socket information is created and published in the cooperation repository on behalf of the production systems in order to allow new VMs or VM newly activated to retrieve configuration actions to be performed for allowing cooperation between applications or application components running on these VMs and the production systems. The cooperation UI which was optional in the existing solution is used in the solution of the invention to import a pre-modeled socket from the a image cooperation input file and instantiate the pre-modeled socket by collecting parameters of the selected production system environment; the parameters are provided either by an administrator or automatically from a local CMBD repository.

Figure 1 illustrates the automatic management of cooperation between software application components or applications located in new virtual machines. Figure 1 shows a certain number of virtual machines (VM1 to VMn) running on one or more virtual machine monitors which may be installed on different physical machines. The virtual machine monitors and the virtual machines forming the virtual data center (110) are managed by a virtual data center manager (120) . The virtual data center manager creates a virtual machine management flow (125) . Being part of the management flow, are VM events (130) of the VM life cycle such VM start, VM stop and shut down.... The virtual data center management software goes along with the virtual machine monitor software such as the VMware (VMware is a trademark of VMware Inc.) hypervisor. It may be installed on a remote server communicating through a network with the virtual machine monitors. In Figure 1, a virtual appliance is deployed to install a multi-tier application comprising a certain number of application components such as the web server (143) . This solution considers only automatic application component or application configuration when activating new virtual machines.

It should be noted that instead of having different application components in the VMs, there may be an entire application instead of one application component, which needs to cooperate with the other application components. To simplify, the description of fig. 1 is based on different components of a same software application spread over different virtual machines, the web server component (143) being included in the virtual machine VM1 (100) .

The solution of figure 1 applies to virtual machines comprising a cooperation engine (140) and a cooperation input file (141) . When the operating system and application virtual disks of a VM have been mounted, the VM is instantiated and the application software is activated. The last step of the activation phase, is the automatic starting of the cooperation engine: the cooperation engine will allow the application components (143) which have been activated in each virtual machine (100) to be able to cooperate. It is not sufficient to have the different components of an application each activated in a virtual machine to make the entire application activated: some configuring operations are necessary to be done on each virtual machine to allow the application components to cooperate together. The automatic cooperation management of the solution avoids tedious manual configuration operations to be performed by the administrator from the virtual data center manager (120) . A socket-plug protocol is used to allow two virtual machines to cooperate. The cooperation engine (140) located on a virtual machine to which is assigned a socket role publishes the socket information on an external cooperation repository (145) using a pre-modeled socket description stored in a cooperation input file (141) . Optionally the cooperation repository can be accessed from a console (150) including a repository user interface or a command line interface; the console can access the VMs, the plug and socket information and display their relationships. The cooperation engine, when the VM on which it is located is assigned a role of plug, reads the plug information in the cooperation input file and check if the socket corresponding to the plug is published. If it is published, the cooperation is established between the two applications components in the socket and plug VM by the cooperation engine executing the scripts in the published socket desciption to retrieve the parameters from the socket VM and executes the script in the plug description to process the socket information. The cooperation is established by the cooperation engines between all the application components in different Vms . This is the last activation step of the virtual appliance deployment. The cooperation engines are also active after deployment phase, acting as a background task in each VM, intercepting the VM events from the virtual data center manager and updating the VM cooperation information in the repository for the other engines: the cooperation engines update the plug and socket status by noting in the cooperation repository if a plug or a socket has become active or inactive because a VM has been released or a new VM have been activated .

The cooperation engine thus forms a software entity pre^¬ loaded in the virtual machines of a virtual appliance to process assigned roles according to the information expressed in the cooperation input file. The cooperation engine is also able to process VM events, like for example the deployment of a new VM or the removal of an already existing VM, in order to take proper configuration action.

For instance, when installing a three-tier web application, a VM engine may declare to the repository that it is has a plug role for a web server and it needs to communicate with a VM socket for an application server. One other VM engine may declare to the repository that it has a plug role as an application server and it needs to communicate with a VM having a socket role for a database server. The same VM engine may declare to the repository that it is an application server socket for any communication with a web server plug.

The socket describes the information that needs to be provided by an entity to establish cooperation with another entity. When a virtual machine is assigned a socket role in a particular environment, which is a parameter of the engine provided in the virtual machine, it publishes the information required by the socket definition. The plug describes the actions that need to be executed by an entity in a virtual machine to establish cooperation with another entity running in a different virtual machine. When a virtual machine is assigned a plug role in a particular environment, it locates an entry in the cooperation repository pointing to a socket description corresponding to its plug role in the same environment, retrieves the published socket information and executes the action described in the plug definition.

As an example, the following pre-modeled socket and plug description are provided in the cooperation input file of the cooperation engine :

<CooperationID>CooperationIDK/CooperationID>

<Description>OPR Automatic Reconfiguration</Description>

<Description>TWS UI Server</Description>

<Description>Description</Description>

<Trigger>Deployment</Trigger>

<ActionType>script</ActionType>

</ConfigurationParameters>

<Operation>/pino/driver4/scripts/OPRUI . sh</Operation> </ActionDetail>

</Action>

</ConfigurationAction>

</ConfigurationActions>

</PlugSection>

<Description>OPR Master</Description>

<SocketID>OPR_SERVER</SocketID>

</ConfigurationParameter> <ConfigurationParameter>

<ConfigurationValue>opr-istributed</ConfigurationValue> </ConfigurationParameter>

</ConfigurationParameter>

</PublishedParameters>

</SocketSection

These inputs are read by the cooperation engine on the VM of the OPR_UI application component which is assigned a role of plug: the OPR_UI plug needs to cooperate with an OPR_SERVER socket, retrieves these configuration parameters and invokes the script /pino/driver4/scripts/OPRUI . sh passing the values as argument, so activating:

/pino/driver4/scripts/OPRUI . sh ncl25050.lab.it.ibm.com 31117 opr-istributed opr85mdm.

The steps performed when the engine starts at the end of the new virtual machines activation phase:

1. The engine checks in the VM registry information entered at deployment time concerning the environment (Host name, virtual machine name etc..) and the possible VM roles. A VM role may be a socket or rule role assigned to the virtual machine. The engine retrieves also the cooperation input file name in the VM registry.

2. For all the socket roles in the cooperation input file: if the socket role is equal to one of the VM roles, the cooperation engine retrieves the socket attributes as described in the cooperation input file (using script files) , publishes in the repository the socket attributes and the information that the socket is now active; 3. For all the plug roles in the cooperation input file, if the plug role is equal to one of the VM roles, the cooperation engine retrieves the related socket information (role, ...) described in the cooperation input file, discovers the socket published by the VM in the cooperation repository and that belongs to the same environment. For all the VMs discovered, the engine :

decides based on the rules defined in the cooperation input file which VM to select if multiple VMs have been discovered; - retrieves the published socket attributes if the status of socket is active;

invokes the configuration actions passing as parameter the information retrieved;

publishes the information that the plug is now active describing also the information to which socket is connected to; - put the plug in a cooperation active table specifying also the information to which socket is connected to;

4. For all the plug roles in the cooperation input file, if no VM is available or the VM is available but the socket is not active, the engine puts the plug role in a cooperation working queue for processing specifying also the roles and test environment needed.

The steps which are performed when the cooperation engine dynamically intercepts VM events received from the virtual data center manager are as follows: 1. The engine collects periodically VM related events (VM deployment, VM dismissal, ...) for VMs with specific roles and belonging to; 2. for all the plug roles in the cooperation working queue :

2a. if a new VM has been discovered and it publishes an active requested socket, the engine:

- retrieves the published socket attributes if the status of socket is active;

- publishes the information the plug is now active describing also the information to which socket is connected to;

removes the plug from the Cooperation working queue ;

puts the plug in the Cooperation active table specifying also the information to which socket is connected to;

2b. if a VM is removed from the datacenter and it publishes a socket currently used by a plug saved in the cooperation active table, the engine:

- invokes the remove configuration actions passing as parameter the information related to the socket;

- removes the plug from the cooperation active table;

- puts the plug in the cooperation working queue;

- publishes the information the plug is now inactive and disconnected.

Figure 2 illustrates a second embodiment of the automatic management of cooperation between software application components or applications located in new virtual machines. Based on the virtualization vendor technology available, it would be possible also to have just one engine running on a separate management system or VM that will be able to configure all the virtual machines. Fig. 2 illustrates this second embodiment of the automatic management of cooperation between software application components or applications located in new virtual machines. The new virtual machines (100, 101) at the end of the activation phase, start activation of an external cooperation engine program (160) accessing the cooperation input files, located in one different system (or in a virtual machine running on the same virtual machine monitor) . So there is a program inside the VM image distributed in the virtual appliance allowing this automatic program to access the engine and provide system parameters to fill the pre-modeled socket and plug socket and plug information from the cooperation input file.

It should be noted that both embodiments of the existing solution to establish cooperation between application components or applications running in different VMs, comprise pre-loaded software in the VMs which are the cooperation engine and the cooperation input file in the first embodiment and one more limited program automatically activated in the second embodiment. Both solutions do not apply if it is needed to create cooperation between application components or applications running in virtual machines which operate in production mode.

Figure 3 illustrates the automatic maintenance of cooperation between software application components or applications when virtual machines are in production mode. Starting from the solution of prior art, this solution allows automatic configuration of application components or applications which are running on virtual machine in production mode. In fig. 3 the VM1 virtual machine includes an application component OPR_UI (143) which needs to cooperate with an OPR_SERVER application (330) running on VM2, a different virtual machine in production mode. Assuming the OPR_UI component needs to cooperate with the OPR_SERVER, some operations are necessary to be performed when installing or removing virtual machines or when including those already installed and in production mode (VM2) on which no cooperation engine can be installed.

The solution of the preferred embodiment which is described hereunder can apply to a virtual data center including virtual machines such as VM1 of a virtual appliance having a pre-loaded software stack installed (Cooperation engine and cooperation input file) and which can cooperate with virtual machines such as VM2 running an application or an application component in production mode. It is noted that the same solution also applies to managing cooperation between virtual machines of a virtual appliance and physical machines running an application or an application component in production mode. In this case the physical machines running an application or an application component in production mode are so called production systems being indifferently virtual or physical machines. It is noted also that even if the solution primarily applies to data centers in which virtual appliances are deployed, it applies also to data centers containing only physical machines, some of them having an pre-loaded additional software stack and other physical machines running applications in production mode having no possibility to have a software stack added.

The virtual machine VM1 represented in Figure 3 includes a cooperation engine and input file, which, for instance during the last step of the activation phase of the virtual appliance, has a plug role for a certain environment which is described in the cooperation engine. VM1 needs to retrieve socket information published in the cooperation repository to perform actions described in the VM1 plug allowing configuration of the applications running on VM1.

Now, because of the brownfield limitation, the virtual machine VM2 which is a VM (or real system) running applications in production mode and has no cooperation engine installed and thus is not able to publish its socket information, cannot publish socket information to allow cooperation with applications of VM1.

According to the preferred embodiment, the cooperation UI (310) which is optionally used for cooperation management in the existing solution for VM machines including cooperation engines, becomes mandatory and creates on the cooperation repository (145) a socket-plug information corresponding to production systems which cannot publish these information because they have no cooperation engine and input file included. To create this production system cooperation socket-plug description in the repository, the cooperation UI imports the pre-modeled socket- plug description from the cooperation input file (141) of VM1 having a plug role for the a certain environment. This socket- plug information is for cooperating between OPR-UI application component in VM1 (143) and OPR_SERVER application component (330) in the VM 2 production VM. The socket description is completed with parameter values of the production system which may be either provided by an Administrator (320) through the cooperation UI, automatically retrieved from a local Common Management DataBase (CMDB 300) repository, or retrieved directly by the cooperation UI in the production system. Then the cooperation UI completes this socket and set it as active while advising the data center manager (120) . The cooperation engine of VM1 when advised from the data center manager (periodic poll on VM events (300) can then use the surrogate published socket for performing configuration actions as mentioned in the plug description. Consequently, according to the preferred embodiment, the production system has no need of having a cooperation engine and input file included, the production system socket information is created separately on behalf of the production system and activated in the cooperation repository by the cooperation UI .

Figure 4 shows one example of socket and plug parameters used to manage cooperation between application components or applications located in new virtual machines and production mode systems according to the method of the preferred embodiment. The plug (420) and socket information (410) are stored (400) in the cooperation repository.

The socket information (410) stored in the cooperation repository concerns the production mode system VM2 which does not include a cooperation engine and input file. It has been imported by the cooperation UI from the cooperation input file of the VM playing a corresponding plug role for the same environment as the production system. This socket (410) is for cooperation between OPR_UI and OPR_SERVER application components in a TEST environment. VM1, a virtual machine of a virtual appliance newly activated needs to configure the OPR_UI application component using information from the OPR_SERVER application component VM information. The VM1 operation engine has checked that VM1 has a plug role for the TEST environment. The cooperation input files describes the plug role (430) applying to the cooperation between OPR_UI and OPR_SERVER. The cooperation input files describes the socket that the engine has to search in the cooperation repository which was the basis for the socket description (410) created and activated by the cooperation UI in the cooperation repository. The cooperation engine will use the socket (410) in the cooperation repository to perform the plug actions mentioned in the plug description (430) .

Finally, the cooperation UI can display all the socket plug descriptions of the virtual data center as published by the cooperation engine of a VM or as created (400) separately by the cooperation UI for the production systems.

It should be noted that a plug role for a specific environment is an information always associated to each VM and stored in an operating system file according to the preexisting solution and the solution of the preferred embodiment. In the preferred embodiment, the socket role for a specific system environment values for a production system is retrieved by the cooperation UI .

Figure 5 is the general flowchart of the method of the invention according to the preferred embodiment. The assumption is that a VM having a cooperation engine and a cooperation input file has a plug role for a specific environment for establishing cooperation between one application (or application component) running on the VM and one application (or application component) running on a system in production mode. As stated before, the production system may be a physical machine or a VM. The engine of the VM needs to locate a virtual machine playing the corresponding socket role in the same environment, retrieves the published socket information and executes the action described in the plug definition to establish cooperation. As the production system does not include a cooperation engine and input file it cannot publish sockets with the useful information. All the steps of the method are performed by the cooperation UI (310) . The interface may be an external automation of the CLI (command line interface) or performed by the administrator;

The socket-plug description is imported (500) from a cooperation input file of a VM (VM1) requesting to configure a application component using information from a production system into the cooperation repository;

During the import process, the imported socket-plug description in the repository includes (510) a unique ID (it could be a combination of plug_id and socket_id for instance) and the environment tag of the plug role of the requesting VM (VM1) ;

The socket type created in the cooperation repository is set to a specific Waiting' type as it is not complete and waits for actual info concerning the production system to be made available;

The Socket Section of the imported socket-plug description is introspected (520) by the cooperation UI for collecting the information to be retrieved and which concerns the production system;

The Socket information is retrieved (530) using 3 possible different ways based on the configuration of the cooperation UI : a . The information are automatically entered in the socket description by a cooperation UI editor (instance-info like hostname, port,

b. scripts (as an example SSH scripts) can be pushed and invoked by the cooperation UI on the production system

(VM2) for retrieving the socket information, c. Information can be retrieved from an external CMDB repository;

It should be noted that validation can be performed on the inserted information (check connection for IP address or TCP port, in general checks if information is conform to the rules set by the socket definition) ; this step is optional, may be requested by the administrator; it can be performed automatically .

Further, it should be noted that additional fields can be specified (pwds, etc) if the administrator requires additional fields or values be specified.

The Waiting' type socket-plug description is updated (540) by the cooperation UI with socket information in the cooperation repository, its type is set to Active' .

The cooperation UI advises (550) the data center manager of the availability in the cooperation repository of the production system surrogate; the cooperation engine of the requesting VM (VM1), periodically collecting the data center manager VM events in the preferred embodiment, uses the completed socket-plug description to perform (560) the configuration actions. In situations where the production system cannot publish the needed information, this allows the production system to have its same socket information published in the cooperation repository as if a cooperation engine would have done it.

The above processing which is performed by the administrator using the cooperation UI can be made available implementing drag-and-drop functionality in the cooperation UI . This allows customization of new socket-plug descriptions, like described in this example dragging the disconnected OPR_UI and dropping it to OPR_SERVER. Using the cooperation UI, the administrator selects on a screen displaying the data center systems, a first virtual image VM1 ; then, it drags it on the production system VM2 and a pop-up menu is displayed asking if the user wants to create a socket for the production system. If the answer is yes, the method as described in the flowchart described above is executed.

Claims

C L A I M S 1. A method for automatically allowing configuration actions to be performed on a virtual machine running a first application, the first application cooperating with a second application running on a system said method comprising:

- publishing said socket model on a repository;

updating the socket model by adding configuration information concerning the system.

2. The method of claim 1 further comprising

retrieving the published updated socket model from the repository;

- retrieving from the virtual machine a plug model corresponding to the retrieved socket model; and,

3. The method of claim 1 or 2 wherein the updating step comprises previously receiving said configuration information concerning the system from a user.

4. The method of claim 1 or 2, wherein the updating step comprises previously collecting said information from the production system by executing a pre-defined script.

5. The method of claim 1 or 2, wherein the updating step comprises previously collecting the information from a database repository.

6. The method of any one of claims 1 to 5 wherein it further comprises generating a VM event to notify each publication of an updated socket model for the system and wherein said updating step previously comprises collecting at the virtual machine the VM events to check if an updated socket model for the socket model has been already published on the repository.

7. The method of any one of claims 1 to 6 wherein :

8. The method of any one to claim 1 to 7 wherein the steps are performed by an external automation using a command line interface .

9. The method of any one to claim 1 to 8 wherein the steps are performed through a user interface.

10. The method of any one of claims 1 to 9 wherein the system is a virtual machine running in production mode.

11. The method of any one of claims 1 to 9 wherein the system is a physical machine running in production mode.

12. A system comprising means adapted to carry out the steps of the method according to any one of the preceding claims.

13. A computer program comprising instructions for carrying out the steps of the method according to any one of claims 1 to 10 when said computer program is executed on a computer.