Patching operating system code during a live migration

Abstract

A process of an operating system is detected as having undergone a live migration, where the live migration involves a change in a hardware feature of the computer system on which the process is executing. A first message is transmitted to a group of processors, the first message causing each processor in the group of processors to enter a wait state. While each of the group of processors is in the wait state, a portion of a set of program instructions of the operating system is modified.

Description

Technical field

[0001] The present invention relates generally to a method, a system, and a computer program for performing a live migration of a virtual machine. In particular, the present invention relates to a method, a system, and a computer program product for patching operating system code during a live migration. BACKGROUND

[0002] A virtual machine (VM) is an emulation of a physical computer system. A hypervisor is computer software that creates and manages VMs. A physical computer system on which a hypervisor runs one or more VMs is also called a host machine, and each VM is also called a guest machine. Using VMs allows multiple different operating systems (OSs) to utilize the same set of physical hardware, as each OS can run its own VM.

[0003] To adapt to changing hardware resource availability and data processing requirements, VMs must be migrated from one physical machine to another. A live migration is the process of moving a running virtual machine (VM), including its memory, storage, and network configurations, to a different physical machine without restarting the operating system or any applications that may be running on the migrating VM, and minimizing the time interval during which the VM is stopped for the migration. BRIEF SUMMARY OF THE INVENTION

[0004] The illustrative embodiments provide a method, a system, and a computer program product. One embodiment comprises a method that detects, for an operating system process, that a live migration has occurred, wherein the live migration involves a change in a hardware feature of a computer system on which the process is running. One embodiment transmits a first message to a group of processors, the first message causing each processor in the group to enter a wait state. One embodiment modifies a section of a set of program instructions of the operating system while each processor in the group is in the wait state.

[0005] One embodiment comprises a computer-usable program product. The computer-usable program product comprises one or more computer-readable memory units and program instructions stored on at least one of the one or more memory units.

[0006] One embodiment comprises a computer system. The computer system comprises one or more processors, one or more computer-readable memory units, and one or more computer-readable storage units and program instructions stored on at least one of the one or more storage units for execution by at least one of the one or more processors via at least one of the one or more memory units.

[0007] According to one aspect, a computer-implemented procedure is provided which includes: detecting that a live migration has taken place for a process of an operating system, wherein the live migration involves a change in a hardware feature of the computer system on which the process is running; transmitting an initial message to a group of processors, wherein the initial message causes each processor in the group of processors to enter a wait state; and modifying a section of a set of program instructions of the operating system while each of the group of processors is in the wait state.

[0008] According to another aspect, a computer-usable program product is provided, comprising one or more computer-readable memory units and program instructions stored on at least one of the one or more memory units, wherein the stored program instructions comprise: program instructions for detecting that a live migration has occurred for a process of an operating system, wherein the live migration involves a change in a hardware feature of the computer system on which the process is executed; program instructions for transmitting an initial message to a group of processors, wherein the initial message causes each processor in the group of processors to enter a wait state;and program instructions for modifying a section of a set of operating system program instructions while each of the group of processors is in the wait state.

[0009] According to another aspect, a computer system is provided that has one or more processors, one or more computer-readable memory units, and one or more computer-readable storage units and program instructions stored on at least one of the one or more storage units for execution by at least one of the one or more processors via at least one of the one or more memory units, wherein the stored program instructions include: program instructions for detecting that a live migration has taken place for a process of an operating system, wherein the live migration involves a change in a hardware feature of a computer system on which the process is executed;Program instructions for transmitting an initial message to a group of processors, wherein the initial message causes each processor in the group of processors to enter a wait state; and program instructions for modifying a section of a set of operating system program instructions while each of the group of processors is in the wait state. List of characters

[0010] Preferred embodiments of the present invention are described below for illustrative purposes only and with reference to the following drawings: Fig. Figure 1 represents a block diagram of a network of data processing systems in which illustrative embodiments can be implemented; Fig. Figure 2 represents a block diagram of a data processing system in which illustrative embodiments can be implemented; Fig. Figure 3 presents a block diagram of an exemplary configuration for patching operating system code during a live migration according to an illustrative embodiment; Fig. Figure 4 shows a block diagram of an exemplary configuration for patching operating system code during a live migration according to an illustrative embodiment; Fig. Figure 5 presents an exemplary time diagram for message flows during a patching of operating system code during a live migration according to an illustrative embodiment; Fig. Section 6 presents a flowchart of an exemplary process for patching operating system code during a live migration according to an illustrative embodiment; and Fig. Figure 7 presents a flowchart of an exemplary process for patching operating system code during a live migration according to an illustrative embodiment. DETAILED DESCRIPTION

[0011] The illustrative embodiments acknowledge that hardware differences can exist between the physical source machine and the physical target machine when a virtual machine and its operating system are live-migrated from one physical machine to another. In a non-restrictive example of such hardware differences, the processors may be different versions, even though the processors in the source and target machines belong to the same family and run the same operating system and application code without recompilation. For example, the source machine might have a Power 8 processor, while the target machine might have a Power 9 processor, or the source and target machines might have different processors within the x86 processor family.In another non-restrictive example of such hardware differences, the number of sockets, chips, or cores in the system might have changed, indicating that a VM migration has occurred. A third non-restrictive example involves a system's non-uniform memory access (NUMA) topology, which specifies a grouping of processors according to memory access speed and informs the operating system which processors are located near the same memory, allowing workloads to be grouped to take advantage of memory location. Some changes in the NUMA topology (e.g., the number of generations) also indicate that a VM migration has occurred.

[0012] The illustrative examples also acknowledge that in some cases, operating system modification is required for correct operation when performing a live migration between physical machines with different hardware characteristics. As a non-restrictive example, different versions of Power processors monitor and report processor time, which is used differently by processes.For example, if both Power-8 and Power-9 processors use the Process Utilization Resource Register (PURR) to perform process monitoring, Power-8 processors report a scaled PURR value for each thread based on how much actual runtime the thread received on the processor over a period of time, while some Power-9 processors report a PURR value that reflects the actual time elapsed for each running thread without any scaling. Consequently, if a VM on a host with Power-8 processors is live-migrated to a host with Power-9 processors, and the operating system reads PURR values ​​to determine process monitoring, the PURR values ​​will be incorrectly scaled, leading to erroneous results. Erroneous results also occur when a VM on a host with Power-9 processors is live-migrated to a host with Power-8 processors.As a result, the illustrative embodiments recognize that there is an unmet need to correct various hardware characteristics during a live migration.

[0013] The illustrative embodiments acknowledge that currently available tools or solutions do not address these requirements or provide adequate solutions. The illustrative embodiments used to describe the invention generally address and solve the problems described above and other problems related to patching operating system code during a live migration.

[0014] An embodiment can be implemented as a software application. The application implementing an embodiment can be configured as a modification of an existing live migration or operating system, as a separate application working in conjunction with an existing live migration or operating system, as a standalone application, or as a combination thereof.

[0015] In particular, some illustrative embodiments provide a method for an operating system process to detect that a live migration has occurred, involving a change in a hardware feature of the computer system on which the process is running. While all other processors are in a wait state, the method modifies a section of the operating system to accommodate the change in the hardware feature.

[0016] An operating system kernel is software that provides OS services, such as starting, stopping, and managing the execution of processes or threads, managing subsystems like memory and storage, and providing services to user applications running on the OS. A kernel process is a process that runs as part of the OS kernel and has trusted access to parts of the system on which the OS runs. If the OS is running on a physical machine, a kernel process has access to physical system hardware. If the OS is running on a virtual machine, a kernel process has access to a virtual or emulated version of physical system hardware. A user-level process, or user process, is an OS process that is not a kernel process.

[0017] One embodiment detects that a change has occurred in a hardware feature of a computer system on which a process is running. In other words, a live migration has taken place, and the embodiment is now running on a different host. One embodiment runs a kernel process of the operating system. Another embodiment runs a user-level process of the operating system. One embodiment also determines that, due to the change in the hardware feature, a portion of the operating system code must be modified to accommodate the change in the hardware feature. For example, the live migration might have occurred from a Power 8 system to a Power 9 system, or vice versa, and as a result, the operating system's process monitoring must be modified to support the handling of PURR values ​​of the current processors.

[0018] One implementation transmits a message to all other processors installed in the migrated system. In a message handler on a receiving processor, the receiving processor acknowledges the message and starts a loop while waiting for a second message. While waiting for the second message, a receiving processor is thus in a wait state, does not execute any user processes, and is therefore prevented from accessing other parts of the operating system that might be undergoing modification.

[0019] One implementation waits for other processors installed in the migrated system to acknowledge the transmitted message. A processor's acknowledgment indicates that the processor is in a wait state and is prevented from accessing other parts of the operating system that might be undergoing modification.

[0020] Once all notified processors have been placed in a standby state, it is safe for one embodiment to modify operating system code, and one embodiment modifies operating system code to accommodate the change in the hardware feature. For example, if live migration from a Power 8 system to a Power 9 system or vice versa could have occurred, operating system program instructions that perform process monitoring are modified to support the handling of PURR values ​​of the current processors.

[0021] Once the OS modification is complete, one implementation transmits a second message to the processors in the wait state. In a message handler on a receiving processor that is waiting for its second message, the message handler receives the second message and exits this message handler process, thus leaving the wait state. The receiving processor is now in normal operation, and the operating system has been modified to reflect the change in the hardware feature: live migration.

[0022] The method of patching operating system code during a live migration described herein is not available in currently available methods in the technological field of virtual machine implementation efforts. A method of an embodiment described herein, when implemented to run on a unit or data processing system, offers significant improvements in the operation of that unit or data processing system in detecting that a live migration has occurred, involving a change in a hardware feature of a computer system on which a process is running. While other processors are in a standby state, the method modifies a section of the operating system to accommodate the change in the hardware feature.

[0023] The illustrative embodiments are described for illustrative purposes only with respect to certain types of migrations, processes, kernels, message handlers, messages, modifications, hardware features, process monitoring, responses, units, data processing systems, environments, components, and applications. All specific manifestations of these and other similar artifacts are not to be construed as limiting the invention. Any suitable manifestation of these and other similar artifacts may be selected within the scope of protection of the illustrative embodiments.

[0024] Furthermore, the illustrative embodiments can be implemented with respect to any type of data, data source, or access to a data source via a data network. Any type of data storage unit can provide the data for an embodiment of the invention within the scope of protection of the invention, either locally on a data processing system or via a data network. In cases where an embodiment is described by using a mobile unit, any type of data storage unit suitable for use with the mobile unit can provide the data for such an embodiment within the scope of protection of the illustrative embodiments, either locally on the mobile unit or via a data network.

[0025] The illustrative embodiments are described using specific code, designs, architectures, protocols, layouts, schematics, and tools for illustrative purposes only and are not limited to these illustrative embodiments. Furthermore, in some cases, the illustrative embodiments are described using specific software, tools, and data processing environments for illustrative purposes only. The illustrative embodiments may be used in conjunction with other comparable or similarly designed structures, systems, applications, or architectures. For example, other comparable mobile units, structures, systems, applications, or architectures may be used in conjunction with such an embodiment of the invention within the scope of protection of the invention.An illustrative embodiment can be implemented in hardware, software, firmware, or a combination thereof.

[0026] The examples in this disclosure are used only to clarify the description and do not limit the illustrative embodiments. Additional data, operations, actions, tasks, activities, and manipulations are conceivable based on this disclosure, and these are considered within the scope of protection of the illustrative embodiments.

[0027] All advantages listed herein are merely examples and are not to be construed as limiting them to the illustrative embodiments. Further or different advantages may be realized through specific illustrative embodiments. Furthermore, a particular illustrative embodiment may exhibit some, all, or none of the advantages listed above.

[0028] With reference to the characters and in particular with reference to Fig. 1 and Fig. 2. These figures are exemplary representations of data processing environments in which illustrative embodiments can be implemented. Fig. 1 and Fig. The two examples are merely examples and are not intended to establish or imply any limitation regarding the environments in which different embodiments can be implemented. A specific implementation may lead to many modifications to the depicted environments based on the following description.

[0029] Fig. Figure 1 represents a block diagram of a network of data processing systems in which illustrative embodiments can be implemented. A data processing environment 100 is a network of computers in which the illustrative embodiments can be implemented. The data processing environment 100 comprises a network 102. The network 102 is the medium used to provide data transmission links between different units and computers connected to each other in the data processing environment 100. The network 102 can include connections such as wired, wireless data transmission links, or fiber optic cables.

[0030] Clients or servers are merely exemplary roles of specific data processing systems connected to network 102 and should not be interpreted as excluding other configurations or roles for these data processing systems. A server 104 and a server 106, along with a storage unit 108, are connected to network 102. Software applications can run on any computer in the data processing environment 100. Clients 110, 112, and 114 are also connected to network 102. A data processing system, such as server 104 or 106, or client 110, 112, or 114, can contain data and can have software applications or software tools running on it.

[0031] Just as an example, and without implying any limitations on such architecture, it presents Fig. 1. Specific components are presented that can be used in an exemplary implementation of an embodiment. For example, servers 104 and 106 and clients 110, 112, and 114 are shown as servers and clients only for illustrative purposes and not to imply a restriction to a client-server architecture. As another example, an embodiment can be distributed across multiple data processing systems and a data network, as shown, whereas another embodiment can be implemented on a single data processing system within the scope of protection of the illustrative embodiments. Data processing systems 104, 106, 110, 112, and 114 also represent example nodes in a cluster, partitions, and other configurations suitable for implementing an embodiment.

[0032] A Unit 132 is an example of a unit described herein. For example, the Unit 132 may take the form of a smartphone, a tablet computer, a laptop computer, a Client 110 in a fixed or portable form, a portable data processing unit, or any other suitable unit. Any software application that is considered to be in another data processing system in Fig. The operation described in section 1 can be configured to run similarly in unit 132. All operations in another data processing system in Fig. 1. Stored or generated data or information can be configured to be stored or generated in Unit 132 in a similar manner.

[0033] Application 105 implements an embodiment described herein. Application 105 is executed on each of the servers 104 and 106, the clients 110, 112, and 114, and the unit 132. Application 105 modifies operating system code during a live migration from one system to another, for example, from server 104 to server 106.

[0034] Servers 104 and 106, storage unit 108, clients 110, 112, and 114, and unit 132 can be connected to network 102 using wired connections, wireless data transmission protocols, or other suitable data connectivity. Clients 110, 112, and 114, for example, can be PCs or network computers.

[0035] In the example shown, server 104 can provide data such as boot files, operating system images, and applications to clients 110, 112, and 114. Clients 110, 112, and 114 can be clients of server 104 in this example. Clients 110, 112, and 114, or a combination thereof, can contain their own data, boot files, operating system images, and applications. The data processing environment 100 can contain additional servers, clients, and other entities not shown.

[0036] In the example shown, the data processing environment 100 can be the Internet. The network 102 can represent a collection of networks and gateways that use the Transmission Control Protocol / Internet Protocol (TCP / IP) or other protocols to exchange data. The core of the Internet is a backbone of data transmission links between main nodes or host computers, encompassing thousands of commercial, governmental, educational, and other computer systems that relay data and messages. Of course, the data processing environment 100 can also be implemented as a number of different types of networks, such as an intranet, a local area network (LAN), or a wide area network (WAN). Fig. Figure 1 is intended as an example and not as an architectural limitation for the various illustrative embodiments.

[0037] Among other uses, Data Processing Environment 100 can be used to implement a client-server environment in which the illustrative embodiments can be implemented. A client-server environment allows software applications and data to be distributed over a network, so that an application functions by utilizing the interactivity between a client data processing system and a server data processing system. Data Processing Environment 100 can also use a service-oriented architecture in which interoperable software components distributed over a network are packaged together as coherent business applications.The data processing environment 100 can also take the form of a cloud and use a cloud computing service delivery model to enable seamless, on-demand network access to a shared pool of configurable data processing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider.

[0038] With reference to Fig. Figure 2 represents a block diagram of a data processing system in which illustrative embodiments can be implemented. A data processing system 200 is an example of a computer, such as servers 104 and 106 or clients 110, 112, and 114 in Fig. 1 or another type of unit which may contain computer-usable program code or instructions for the illustrative embodiments, which implements the processes.

[0039] The data processing system 200 is also representative of a data processing system or a configuration therein, such as the data processing system 132 in Fig. 1, in which program code or instructions usable by a computer may or may be located, which implement the processes of the illustrative embodiments. The data processing system 200 is described for illustrative purposes only as a computer, without being limited to that. Implementations in the form of other units, such as unit 132 in Fig. 1. The data processing system 200 can be modified, for example, by adding a touch interface, and even certain components shown in the data processing system 200 can be eliminated without deviating from the general description of the operations and functions of the data processing system 200 described herein.

[0040] In the example shown, the data processing system 200 uses a hub architecture with a northbridge and memory controller hub (NB / MCH) 202 and a southbridge and input / output (I / O) controller hub (SB / ICH) 204. A processing unit 206, a main memory 208, and a graphics processor 210 are connected to the northbridge and the controller hub (NB / MCH) 202. The processing unit 206 can contain one or more processors and can be implemented using one or more heterogeneous processor systems. The processing unit 206 can be a multi-core processor. In certain implementations, the graphics processor 210 can be connected to the NB / MCH 202 via an accelerated graphics port (AGP).

[0041] In the example shown, a local area network (LAN) adapter 212 is connected to the southbridge and I / O controller hub (SB / ICH 204). An audio adapter 216, a keyboard and mouse adapter 220, a modem, a read-only memory (ROM) 224, a universal serial bus (USB), and other connectors 232 and PCI / PCIe units 234 are connected to the southbridge and I / O controller hub 204 via a bus 238. A hard disk drive or solid-state drive (SSD) 226 and a CD-ROM drive 230 are connected to the southbridge and I / O controller hub 204 via a bus 240. The PCI / PCIe units 234 can include, for example, Ethernet adapters, add-in cards, and PC cards for notebook computers. PCI uses a card bus controller, while PCIe does not. The ROM 224 can, for example, be a binary flash input / output system (BIOS).The hard disk drive 226 and the CD-ROM drive 230 can, for example, use an Integrated Drive Electronics (IDE) or Serial Advanced Technology Attachment (SATA) interface, or variants such as External SATA (eSATA) and Micro-SATA (mSATA). A Super I / O (SIO) unit 236 can be connected to the Southbridge and the I / O controller hub (SB / ICH) 204 via a bus 238.

[0042] Random Access Memory (RIM), such as Main Memory (RAM) 208, ROM 224, or Flash Memory (not shown), are some examples of storage units usable by a computer. Hard disk drive or solid-state drive (SSD) 226, or other similarly usable units, are some examples of storage units usable by a computer, comprising a storage medium usable by a computer.

[0043] An operating system runs on processing unit 206. The operating system coordinates various components and provides their control within the data processing system 200. Fig. 2. The operating system can be a commercially available operating system for any type of data processing platform, including but not limited to server systems, PCs, and mobile units. An object-oriented programming system, or another type of programming system, can run alongside the operating system and provides calls to the operating system from programs or applications running on the data processing system 200.

[0044] Instructions for the operating system, the object-oriented programming system, and applications or programs, such as application 105 in Fig. 1, are located on storage units, such as in the form of a code 226A on a hard disk drive 226, and can be loaded into at least one of one or more working memories, such as a main working memory 208, for execution by a processing unit 206. The processes of the illustrative embodiments can be executed by the processing unit 206 using instructions implemented by the computer, which may be located in a working memory such as the main working memory 208, the ROM 224, or in one or more peripheral units 226 and 230.

[0045] Furthermore, in one case, code 226A can be downloaded via network 201A from a remotely located system 201B, on which a similar code 201C is stored on a storage unit 201D. In another case, code 226A can be downloaded via network 201A to the remotely located system 201B, on which a similar code 201C is stored on a storage unit 201D.

[0046] The hardware in the Fig. 1 to Fig. 2 may vary depending on the implementation. Other internal hardware or peripheral units such as flash memory, equivalent non-volatile memory, or optical disk drives, and the like, may be used in addition to or instead of the hardware specified in the Fig. 1 to Fig. Figure 2 is shown. Furthermore, the processes of the illustrative embodiments can be applied to a multi-processor data processing system.

[0047] In some illustrative examples, the Data Processing System 200 could be a Personal Digital Assistant (PDA), generally configured with flash memory to provide non-volatile storage for operating system files and / or user-generated data. A bus system can consist of one or more buses, such as a system bus, an I / O bus, and a PCI bus. Naturally, the bus system can be implemented using any type of communication structure or architecture that provides data transfer between different components or units connected to that structure or architecture.

[0048] A data transmission unit can comprise one or more units used to transmit and receive data, such as a modem or a network adapter. A memory unit can be, for example, the main memory (208) or a cache memory, such as the cache memory found in the Northbridge and the memory controller hub (202). A processing unit can comprise one or more processors or CPUs.

[0049] The examples shown in the Fig. 1 to Fig. 2 and the examples described above should be understood as implying no restrictions on the architecture. For example, in addition to having a mobile or wearable form, the data processing system 200 could also be a tablet computer, a laptop computer, or a telephone unit.

[0050] In cases where a computer or data processing system is described as a virtual machine, virtual unit or virtual component, the virtual machine, virtual unit or virtual component operates in the manner of the data processing system 200 by using a virtualized appearance of some or all of the components represented in the data processing system.For example, in a virtual machine, virtual unit, or virtual component, the processing unit 206 appears as a virtualized instance of all or some of the hardware processing units available in a host data processing system; the main memory 208 appears as a virtualized instance of all or part of the main memory 208 available in the host data processing system; and the hard disk drive 226 appears as a virtualized instance of all or part of the hard disk drive 226 available in the host data processing system. In such cases, the host data processing system is represented by the data processing system 200.

[0051] With reference to Fig. Figure 3 presents a block diagram of an exemplary configuration for patching operating system code during a live migration according to an illustrative embodiment. Application 300 is an example of Application 105 in Fig. 1 and is in each of the servers 104 and 106, the clients 110, 112 and 114 and the unit 132 in Fig. 1 executed.

[0052] Application 300 runs a kernel process or a user-level process in an operating system. A migration detection module 310 detects that a change has occurred in a hardware feature of a computer system on which a process is running. In other words, a live migration has taken place, and Application 300 is now running on a different host. The migration detection module 310 also determines that, due to the change in the hardware feature, a portion of the operating system code needs to be modified to accommodate the change.

[0053] A Processor Messages Module 320 transmits a message to one or more other processors installed in the migrated system and places the receiving processors in a wait state. After transmission, the Processor Messages Module 320 waits for other processors installed in the migrated system to acknowledge the transmitted message. A processor's acknowledgment indicates that the processor is in a wait state and is prevented from accessing other parts of the operating system that might be undergoing modification.

[0054] Once all notified processors have been placed in a standby state, it is safe for application 300 to modify operating system code, and an OS modification module 330 modifies operating system code to reflect the change in the hardware feature. After the OS modification is complete, the processor messaging module 320 transmits a second message to the standby processors, returning the receiving processors to normal operation.

[0055] With reference to Fig. Figure 4 shows a block diagram of an exemplary configuration for patching operating system code during a live migration according to an illustrative embodiment. In particular, Fig. 4 more details of module 320 in Fig. 3 dar.

[0056] A 410 Waiting Module transmits a message to one or more other processors installed in the migrated system, placing the receiving processors into a wait state. After transmission, an Acknowledge Module 420 waits for other processors installed in the migrated system to acknowledge the transmitted message. A processor's acknowledgment indicates that the processor is in a wait state and is prevented from accessing other parts of the operating system that may be undergoing modification. To subsequently return the receiving processors to normal operation, a 430 Waiting Message Module transmits a second message to the wait-state processors.

[0057] With reference to Fig. Figure 5 presents an exemplary timing diagram for message flows during a patching of operating system code during a live migration according to an illustrative embodiment. Application 300 is the same as Application 300 in Fig. 3.

[0058] Application 300 is a process running on processor 502. In state 510, the application determines that a live migration has occurred, and due to a change in the hardware feature, a section of the operating system code must be modified. In state 512, application 300 begins putting all other processors in the live-migrated system into a wait state by transmitting a message 520 to them. Alternatively, application 300 sends a separate version of message 520 to each other processor to be put into a wait state. Message 520 is received by a message handler 530 running on processor 504. Processor 503 is an example of the group of other processors to be put into a wait state.Specifically, message handler 530, in state 532, receives message 520, and in state 534, message handler 530 sends message 522, an acknowledgment, back to application 300. Next, message handler 530, in state 536, waits for a second message. In state 514, application 300 receives message 522 and modifies operating system code to reflect the change in the hardware feature after all processors have acknowledged message 520. In state 516, application 300 then transmits message 524 to processor 504, where message handler 530 is waiting in state 536. Message handler 530 receives message 524 and transitions to state 536, in which message handler 530 terminates, thereby returning processor 504 to normal operation. This example should not be considered restrictive.In particular, intermediate messages can occur between messages 520 and 522, and between messages 522 and 524. Likewise, if message 522 is not sent, or is sent but not successfully received, application 300 is configurable to include an error-handling sequence (not shown) that resends message 520 or aborts the operating system modification process without sending message 524. Furthermore, the error-handling sequence can be executed on a per-processor basis or for each processor to which message 520 was originally sent.

[0059] With reference to Fig. Figure 6 presents a flowchart of an exemplary process for patching operating system code during a live migration according to an illustrative embodiment. A process 600 can be found in application 300 in Fig. 3 or Fig. 5 will be implemented.

[0060] In block 602, the application detects that a live migration has occurred, changing a hardware characteristic of a computer system. In block 604, the application sends an initial message to a group of processors, causing each processor in the group to enter a wait state. In block 606, the application waits until all processors have acknowledged the initial message. In block 608, the application modifies a section of a set of operating system program instructions to reflect the change in the hardware characteristic. In block 610, the application sends a second message to the group of processors, causing them to exit the wait state. The application then terminates.

[0061] With reference to Fig. Figure 7 shows a flowchart of an exemplary process for patching operating system code during a live migration according to an illustrative embodiment. A process 700 can be executed in the message handler 530 in the processor 504 in Fig. 5 will be implemented.

[0062] In block 702, the process receives an initial message that instructs a message handler to wait for a second message. In block 704, the process acknowledges the first message. In block 706, the process waits until it receives a second message. Afterward, the process terminates (path "JA" from block 706).

[0063] Thus, a computer-implemented method, system or device, and computer program product are provided in the illustrative embodiments for patching operating system code during a live migration and other related features, functions, or operations. In cases where an embodiment or part thereof is described in relation to a unit type, the computer-implemented method, system or device, and computer program product, or a part thereof, are adapted or configured to be used with a suitable or comparable manifestation of that unit type.

[0064] In cases where an embodiment is described as being implemented in an application, the provision of the application in a Software as a Service (SaaS) model is considered within the scope of protection of the illustrative embodiments. In a SaaS model, the application's ability to implement an embodiment for a user is provided by running the application in a cloud infrastructure. The user can access the application using a variety of client devices via a thin-client interface, such as a web browser (e.g., web-based email) or other lightweight client applications. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or cloud storage. In some cases, the user cannot even manage or control the functionality of the SaaS application.In some other cases, the SaaS implementation of the application may allow a possible exception to restricted user-specific settings of the application configuration.

[0065] The present invention may be a system, a method, and / or a computer program product at any possible level of technical integration. The computer program product may include a computer-readable storage medium (or media) on which computer-readable program instructions are stored to instruct a processor to execute aspects of the present invention.

[0066] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by an executing unit. For example, a computer-readable storage medium can be, but is not limited to, an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, random-access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), a portable CD-ROM, a DVD, a memory stick, a floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, shall not be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses guided by an optical fiber cable), or electrical signals transmitted by a wire.

[0067] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to individual data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routing computers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective data processing unit.

[0068] Computer-readable program instructions for executing work steps of the present invention may be assembler instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., as well as procedural programming languages ​​such as the programming language "C" or similar programming languages.The computer-readable program instructions can be executed 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 the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, via the internet using an internet service provider).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute the computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to implement aspects of the present invention.

[0069] Aspects of the present invention are described herein with reference to illustrations of flowcharts and / or block diagrams of processes, devices (systems), and computer program products according to embodiments of the invention. It should be clear that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by means of computer-readable program instructions.

[0070] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or any other programmable data processing device to create a machine such that the instructions executed by the processor of the computer or other programmable data processing device will produce a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams.

[0071] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device or other unit to cause a series of operations to be performed on the computer or other programmable device or other unit in order to produce a computer-implemented process such that the instructions executed on the computer, other programmable device or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams.

[0072] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this context, each block in the flowcharts or block diagrams can represent a module, segment, or part of instructions that includes one or more executable instructions for implementing the specific logical function(s). In some alternative implementations, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown consecutively may actually be executed essentially in parallel, or the blocks may sometimes be executed in reverse order, depending on the functionality involved.It should also be noted that each block of the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or actions, or execute combinations of special hardware and computer instructions.

Claims

[1] A method implemented by a computer, comprising: Detecting, for a process of an operating system, that a live migration has occurred, wherein the live migration comprises a change in a hardware characteristic of a computer system on which the process is executing; Transmitting, to a group of processors, a first message, the first message causing each processor in the group of processors to enter a wait state; and Modifying, while each of the group of processors is in the wait state, a portion of a set of program instructions of the operating system. [2] The computer-implemented method of claim 1, wherein the wait state comprises a state in which a processor in the group of processors is not executing any user processes. [3] The computer-implemented method of claim 1, wherein the wait state comprises a state in which a processor in the group of processors executes a process of a message handler until the second message is received, the process of the message handler comprising a kernel process of the operating system. [4] A computer-implemented method according to claim 1, further comprising: Receiving, from the group of processors, an acknowledgment of the first message, the acknowledgment acknowledging that a processor in the group of processors is in the wait state. [5] The computer-implemented method of claim 1, wherein modifying adjusts the portion to account for the change in the hardware feature. [6] The computer-implemented method of claim 1, wherein the change in the hardware feature is a change in process accounting, and modifying adapts the portion to implement the change in process accounting. [7] A computer-implemented method according to claim 1, further comprising: Transmitting a second message to the group of processors following the change, the second message causing the group of processors to exit the wait state. [8] A computer-usable program product comprising one or more computer-readable storage units and program instructions stored on at least one of the one or more storage units, the stored program instructions comprising: Program instructions for detecting that a live migration has occurred for a process of an operating system, wherein the live migration comprises a change in a hardware characteristic of a computer system on which the process is executing; Program instructions for transmitting a first message to a group of processors, the first message causing each processor in the group of processors to enter a wait state; and Program instructions for modifying a portion of a set of program instructions of the operating system while each of the group of processors is in the wait state. [9] The computer usable program product of claim 8, wherein the wait state comprises a state in which a processor in the group of processors is not executing any user processes. [10] The computer usable program product of claim 8, wherein the wait state comprises a state in which a processor in the group of processors executes a process of a message handler until the second message is received, the process of the message handler comprising a kernel process of the operating system. [11] A computer usable program product according to claim 8, further comprising: Program instructions for receiving an acknowledgment of the first message from the group of processors, the acknowledgment acknowledging that a processor in the group of processors is in the wait state. [12] The computer usable program product of claim 8, wherein modifying adapts the portion to account for the change in the hardware feature. [13] The computer usable program product of claim 8, wherein the change in the hardware feature is a change in the process monitor, and the modifying adapts the portion to implement the change in the process monitor. [14] A computer usable program product according to claim 8, further comprising: Program instructions for transmitting a second message to the group of processors following the changing, the second message causing the group of processors to exit the wait state. [15] The computer usable program product of claim 8, wherein the stored program instructions are stored in the at least one of the one or more storage units of a local data processing system, and wherein the stored program instructions are transmitted over a network from a remote data processing system. [16] The computer-usable program product of claim 8, wherein the stored program instructions are stored in the at least one of the one or more storage devices of a server data processing system, and wherein the stored program instructions are downloaded over a network to a remote data processing system for use in a computer-readable storage device associated with the remote data processing system. [17] A computer system comprising one or more processors, one or more computer-readable memories, and one or more computer-readable storage units, and program instructions stored on at least one of the one or more storage units for execution by at least one of the one or more processors via at least one of the one or more memories, the stored program instructions comprising: Program instructions for detecting that a live migration has occurred for a process of an operating system, wherein the live migration comprises a change in a hardware characteristic of a computer system on which the process is executing; Program instructions for transmitting a first message to a group of processors, the first message causing each processor in the group of processors to enter a wait state; and Program instructions for modifying a portion of a set of program instructions of the operating system while each of the group of processors is in the wait state. [18] The computer system of claim 17, wherein the wait state comprises a state in which a processor in the group of processors is not executing any user processes. [19] The computer system of claim 17, wherein the wait state comprises a state in which a processor in the group of processors executes a process of a message handler until the second message is received, the process of the message handler comprising a kernel process of the operating system. [20] The computer system of claim 17, further comprising: Program instructions for receiving an acknowledgment of the first message from the group of processors, the acknowledgment acknowledging that a processor in the group of processors is in the wait state. [21] The computer system of claim 17, wherein modifying adapts the portion to account for the change in the hardware feature. [22] The computer system of claim 17, wherein the change in the hardware feature is a change in process monitoring, and modifying adapts the portion to implement the change in process monitoring. [23] The computer system of claim 17, wherein the stored program instructions further comprise: Program instructions for transmitting a second message to the group of processors following the changing, the second message causing the group of processors to exit the wait state. [24] A computer program comprising program code means adapted to carry out the method according to any one of claims 1 to 7 when the program is executed on a computer.

Images