Operating system code patching during live migration

By detecting changes in hardware characteristics during the dynamic migration of virtual machines and modifying operating system codes, the problem of inconsistent operating system functions in different hardware environments is solved, ensuring the correct operation of the operating system after migration.

CN114730272BActive Publication Date: 2025-08-15INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202080079878.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2019-11-13
Filing Date
2020-11-10
Publication Date
2025-08-15
Estimated Expiration
2040-11-10

AI Technical Summary

Technical Problem

During the dynamic migration of virtual machines, the existing technology cannot effectively deal with the problem of incorrect operating system functions caused by differences in different hardware characteristics, especially inconsistent process accounting caused by processor version and NUMA topology changes.

Method used

By detecting changes in hardware characteristics, broadcasting messages to the processor to enter a waiting state, and modifying a portion of the operating system code while all processors are in a waiting state to adapt to new hardware characteristics.

Benefits of technology

It realizes timely patching of operating system code during dynamic migration, ensuring that the operating system runs correctly under different hardware environments, and avoids incorrect process accounting and functional failure.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114730272B_ABST
    Figure CN114730272B_ABST
Patent Text Reader

Abstract

A process of an operating system detects a dynamic migration, the dynamic migration including a change in hardware characteristics of a computer system on which the process is executed. A first message is broadcast to a group of processors, the first message causing each processor in the group of processors to enter a wait state. While each processor in the group of processors is in the wait state, a portion of a set of program instructions of the operating system is modified.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention generally relates to methods, systems, and computer program products for performing live migration of virtual machines. More specifically, the present invention relates to methods, systems, and computer program products for patching operating system code during live migration. Background Art

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

[0003] To adapt to changing hardware resource availability and computing needs, VMs must migrate from one physical machine to another. Live migration is the process of moving a running virtual machine (VM), including its memory, storage, and network configuration, to a different physical machine without restarting the operating system or applications that may be executing on the migrated VM, while minimizing the time interval required to stop the VM for the migration. Summary of the Invention

[0004] Exemplary embodiments provide a method, system, and computer program product. Embodiments include a method for detecting that a dynamic migration has occurred for a process of an operating system, where the dynamic migration includes a change in hardware characteristics of a computer system on which the process is executed. Embodiments broadcast a first message to a group of processors, the first message causing each processor in the group of processors to enter a wait state. One embodiment modifies a portion of a set of program instructions of the operating system while each processor in the group of processors is in the wait state.

[0005] Embodiments include a computer usable program product comprising one or more computer readable storage devices and program instructions stored on at least one of the one or more storage devices.

[0006] Embodiments include a computer system comprising one or more processors, one or more computer-readable memories, and one or more computer-readable storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories.

[0007] According to one aspect, a computer-implemented method is provided, comprising: detecting that a dynamic migration has occurred for a process of an operating system, the dynamic migration comprising a change in hardware characteristics of a computer system on which the process is executed; broadcasting 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 modifying a portion of a set of program instructions of the operating system while each processor in 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 storage devices, and program instructions stored on at least one of the one or more storage devices, the stored program instructions comprising: program instructions for detecting that a dynamic migration has occurred for a process of an operating system, the dynamic migration comprising a change in hardware characteristics of a computer system on which the process is executed; program instructions for broadcasting 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 group of program instructions for the operating system while each processor in the group of processors is in the wait state.

[0009] According to another aspect, a computer system is provided, comprising one or more processors, one or more computer-readable memories, and one or more computer-readable storage devices, and program instructions stored on at least one of the one or more storage devices 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 dynamic migration has occurred for a process of an operating system, the dynamic migration comprising a change in hardware characteristics of the computer system on which the process is executed; program instructions for broadcasting 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 group of program instructions for the operating system while each processor in the group of processors is in the wait state. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings:

[0011] Figure 1 A block diagram depicts a network of data processing systems in which exemplary embodiments may be implemented;

[0012] Figure 2 depicts a block diagram of a data processing system in which the exemplary embodiments may be implemented;

[0013] Figure 3depicts a block diagram of an example configuration for operating system code patching during live migration, in accordance with an exemplary embodiment;

[0014] Figure 4 depicts a block diagram of an example configuration for operating system code patching during live migration, in accordance with an exemplary embodiment;

[0015] Figure 5 depicts an example timing diagram of message flow during operating system code patching during live migration according to an exemplary embodiment;

[0016] Figure 6 A flowchart depicting an example process for operating system code patching during live migration according to an exemplary embodiment; and

[0017] Figure 7 Depicted is a flow diagram of an example process for operating system code patching during live migration, in accordance with an illustrative embodiment. DETAILED DESCRIPTION

[0018] Exemplary embodiments recognize that when dynamically migrating a VM and its operating system from one physical machine to another, there may be hardware differences between the source physical machine and the target physical machine. In one non-limiting example of such hardware differences, even though the processors in the source and target machines are of the same family and can execute the same operating system and application code without recompilation, the processors may be of different versions. For example, the source machine may have a Power 8 processor and the target machine may have a Power 9 processor, or the source and target machines may have different processors in the x86 processor family. In another non-limiting example of such hardware differences, the number of sockets, chips, or cores in the system may have changed, indicating that a VM migration has occurred. A third non-limiting example relates to the non-uniform memory access (NUMA) topology of the system, which specifies groupings of processors based on memory access speed and informs the OS which processors are located near the same memory so that workloads can be grouped together to take advantage of memory locality. Some changes in the NUMA topology (e.g., generation count) also indicate that a VM migration has occurred.

[0019] The exemplary embodiments also recognize that, in some cases, operating system modifications are required to achieve correct functionality when performing live migration between physical machines with different hardware characteristics. As a non-limiting example, different versions of Power processors perform accounting and reporting of processor time consumed by a process differently. For example, while both Power 8 and Power 9 processors use process utilization resource registers to perform process accounting, Power 8 processors report a scaled PURR value for each thread based on the amount of actual run time received by the thread on the processor within a time period, while some Power 9 processors report a PURR value that includes the actual run time of each running thread without scaling. Therefore, if a VM on a host with a Power 8 processor is live migrated to a host with a Power 9 processor, and the operating system reads the PURR value to determine process accounting, the PURR value will be scaled incorrectly, resulting in incorrect results. If a VM on a host with a Power 9 processor is live migrated to a host with a Power 8 processor, incorrect results will also occur. Therefore, the exemplary embodiments recognize that there is an unmet need to correct for different hardware characteristics during live migration.

[0020] The illustrative embodiments recognize that currently available tools or solutions do not address these needs or provide adequate solutions to these needs.The illustrative embodiments used to describe the present invention generally address and solve the above-mentioned problems and other problems related to operating system code patching during live migration.

[0021] The embodiments may be implemented as software applications. Applications implementing the embodiments may be configured as modifications to existing live migration or operating systems, separate applications operating in conjunction with existing live migration or operating systems, standalone applications, or some combination thereof.

[0022] Specifically, some exemplary embodiments provide a method for detecting, for a process of an operating system, a dynamic migration that includes a change in hardware characteristics of a computer system on which the process is executed. The method modifies a portion of the operating system to account for the change in hardware characteristics while all other processors in the system are in a wait state.

[0023] The kernel of an operating system is the software that provides OS services, such as starting, stopping, and managing executing processes or threads, managing subsystems such as memory and storage devices, and providing services to user applications executing on the OS. Kernel processes are processes that execute as part of the OS kernel and have trusted access to the parts of the system on which the OS executes. When the OS executes on a physical machine, kernel processes can access the physical system hardware. When the OS executes on a virtual machine, kernel processes can access virtual or emulated versions of the physical system hardware. User-level or user processes are processes of the OS that are not kernel processes.

[0024] One embodiment detects that a change in the hardware characteristics of the computer system on which a process is executing has occurred. In other words, a live migration has occurred and the embodiment is now executing on a different host. One embodiment executes as a kernel process of an operating system. Another embodiment executes as a user-level process of an operating system. An embodiment also determines that due to the change in hardware characteristics, a portion of the operating system code must be modified to account for the change in hardware characteristics. For example, a live migration may be from a Power 8 system to a Power 9 system, or vice versa, and therefore the OS's process accounting must be modified to support the current processor's handling of PURR values.

[0025] One embodiment broadcasts a message to all other processors installed in the migrated system. Within the receiving processor's message handler, the receiving processor acknowledges the message and loops, waiting for a second message. Thus, while waiting for the second message, the receiving processor is in a wait state, not executing user processes, and is therefore blocked from accessing other parts of the operating system that may be modified.

[0026] One embodiment waits for the other processors installed in the system being migrated to acknowledge the broadcast message. The processor's acknowledgement indicates that the processor is in a wait state and is blocked from accessing other parts of the operating system that may be to be modified.

[0027] Once all processors receiving the message have been placed in a wait state, it is safe for one embodiment to modify the operating system code, and one embodiment modifies the operating system code to account for changes in hardware characteristics. For example, if a live migration might be from a Power 8 system to a Power 9 system, or vice versa, the operating system program instructions that perform process accounting are modified to support the current processor's handling of PURR values.

[0028] Once the OS modification has been made, an embodiment broadcasts a second message to the processor in the waiting state. Within the message handler at the receiving processor waiting for the second message, the message handler receives the second message and exits the message handler process, thereby exiting the waiting state. The receiving processor is now in normal operation, and the operating system has been modified to account for the changes in hardware characteristics caused by live migration.

[0029] The approach described herein to patch operating system code during live migration is not available in currently available methods in the art of virtual machine implementation efforts. When implemented for execution on a device or data processing system, the method of the embodiments described herein comprises a substantial advancement in the functionality of the device or data processing system to detect that a live migration has occurred, including a change in hardware characteristics of the computer system on which a process is executing. The method modifies a portion of the operating system to account for the change in hardware characteristics while other processors in the system are in a wait state.

[0030] By way of example only, the exemplary embodiments are described with respect to certain types of migrations, processes, kernels, message handlers, messages, modifications, hardware features, process counts, responses, devices, data processing systems, environments, components, and applications. Any particular representation of these and other similar artifacts is not intended to limit the present invention. Any suitable representation of these and other similar artifacts may be selected within the scope of the exemplary embodiments.

[0031] Furthermore, the exemplary embodiments may be implemented for any type of data, data source, or access to a data source over a data network. Within the scope of the present invention, any type of data storage device may provide data to the embodiments of the present invention locally at a data processing system or over a data network. Where embodiments are described using mobile devices, within the scope of the exemplary embodiments, any type of data storage device suitable for use with the mobile device may provide data to such embodiments locally at the mobile device or over a data network.

[0032] The exemplary embodiments are described using specific code, designs, architectures, protocols, layouts, schematics, and tools, which are examples only and not limitations of the exemplary embodiments. In addition, for clarity of description, specific software, tools, and data processing environments are used in some instances to describe the exemplary embodiments only as examples. The exemplary embodiments can be used in conjunction with other comparable or similar purpose structures, systems, applications, or architectures. For example, within the scope of the present invention, other comparable mobile devices, structures, systems, applications, or their architectures can be used in conjunction with such embodiments of the present invention. The exemplary embodiments can be implemented in hardware, software, or a combination thereof.

[0033] The examples in this disclosure are for clarity of description only and are not intended to limit the exemplary embodiments. Additional data, operations, actions, tasks, activities, and manipulations can be envisioned from this disclosure and can be envisioned within the scope of the exemplary embodiments.

[0034] Any advantages listed herein are merely examples and are not intended to limit the exemplary embodiments. Additional or different advantages may be achieved through specific exemplary embodiments. Furthermore, specific exemplary embodiments may have some, all, or none of the advantages listed above.

[0035] With reference to the accompanying drawings, and in particular with reference to Figure 1 and 2 , these figures are illustrative diagrams of data processing environments in which illustrative embodiments may be implemented. Figure 1 and 2 This is merely an example and is not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented. Specific implementations may make many modifications to the depicted environments based on the following description.

[0036] Figure 1 A block diagram depicts a network of data processing systems in which exemplary embodiments may be implemented. Data processing environment 100 is a computer network in which exemplary embodiments may be implemented. Data processing environment 100 includes network 102. Network 102 is a medium for providing communication links between various devices and computers connected together within data processing environment 100. Network 102 may include connections such as wired or wireless communication links or fiber optic cables.

[0037] Client or server are merely example roles for certain data processing systems connected to network 102 and are not intended to exclude other configurations or roles for these data processing systems. Server 104 and server 106 are coupled to network 102 along with storage unit 108. Software applications may be executed on any computer in data processing environment 100. Clients 110, 112, and 114 are also coupled to network 102. Data processing systems such as servers 104 or 106 or clients 110, 112, or 114 may contain data and may have software applications or software tools executing thereon.

[0038] This is for example purposes only and does not imply any limitation on such architectures. Figure 1Certain components that may be used in example implementations of the embodiments are depicted. For example, servers 104 and 106 and clients 110, 112, 114 are depicted as servers and clients only as an example and not to imply limitation to client-server architectures. As another example, one embodiment may be distributed across several data processing systems and data networks as shown, while another embodiment may be implemented on a single data processing system within the scope of the exemplary embodiments. Data processing systems 104, 106, 110, 112, and 114 also represent example nodes in clusters, partitions, and other configurations suitable for implementing the embodiments.

[0039] Device 132 is an example of a device described herein. For example, device 132 may take the form of a smartphone, a tablet computer, a laptop computer, a fixed or portable form of client 110, a wearable computing device, or any other suitable device. Figure 1 Any software application executing in another data processing system in may be configured to execute in device 132 in a similar manner. Figure 1 Any data or information stored or generated in another data processing system in may be configured to be stored or generated in device 132 in a similar manner.

[0040] Application 105 implements the embodiments described herein. Application 105 executes in any of servers 104 and 106, clients 110, 112, and 114, and device 132. Application 105 modifies operating system code during a live migration from one system to another, such as from server 104 to server 106.

[0041] Servers 104 and 106, storage unit 108, clients 110, 112, and 114, and device 132 may be coupled to network 102 using wired connections, wireless communication protocols, or other suitable data connections. Clients 110, 112, and 114 may be, for example, personal computers or network computers.

[0042] In the depicted example, server 104 can provide data, such as boot files, operating system images, and applications, to clients 110, 112, and 114. In this example, clients 110, 112, and 114 can be clients to server 104. Clients 110, 112, 114, or some combination thereof, can include their own data, boot files, operating system images, and applications. Data processing environment 100 can include additional servers, clients, and other devices not shown.

[0043] In the described example, data processing environment 100 can be the Internet. Network 102 can represent a collection of networks and gateways that use Transmission Control Protocol / Internet Protocol (TCP / IP) and other protocols to communicate with each other. At the core of the Internet is a backbone of data communication links between master nodes or host computers, which include thousands of commercial, government, educational and other computer systems that route data and messages. Of course, data processing environment 100 can also be implemented as many different types of networks, such as intranets, local area networks (LANs) or wide area networks (WANs). Figure 1 It is intended as an example, not as an architectural limitation for the different exemplary embodiments.

[0044] In addition to other purposes, data processing environment 100 can be used to realize the client-server environment in which exemplary embodiments can be realized. The client-server environment enables software applications and data to be distributed on the network so that application works by using the interactivity between the client data processing system and the server data processing system. Data processing environment 100 can also adopt a service-oriented architecture, in which the interoperable software components distributed on the network can be packaged together as consistent business applications. Data processing environment 100 can also take the form of a cloud, and adopt the cloud computing model of service delivery to realize the convenient on-demand network access to the shared pool of configurable computing resources (for example, network, network bandwidth, server, processing, memory, storage, application, virtual machine and service), which can be quickly supplied and released with minimal management effort or with the interaction of the provider of service.

[0045] refer to Figure 2 , which depicts a block diagram of a data processing system in which the exemplary embodiments may be implemented. Data processing system 200 is an example of a computer, such as Figure 1 Servers 104 and 106, or clients 110, 112, and 114, or another type of device in which computer usable program code or instructions implementing the processes may be located, may be used for exemplary embodiments.

[0046] Data processing system 200 also represents a data processing system or configuration thereof, such as Figure 1 The data processing system 132 in the embodiment may contain computer usable program code or instructions that implement the processes of the exemplary embodiments. The data processing system 200 is described as a computer only as an example and is not limited thereto. Without departing from the general description of the operation and functionality of the data processing system 200 described herein, the computer may be used in a manner such as Figure 1 Implementations in the form of other devices of device 132 may modify data processing system 200 , such as by adding a touch interface, and even removing certain depicted components from data processing system 200 .

[0047] In the depicted example, data processing system 200 employs a hub architecture including north bridge and memory controller hub (NB / MCH) 202 and south bridge and input / output (I / O) controller hub (SB / ICH) 204. Processing unit 206, main memory 208, and graphics processor 210 are coupled to north bridge and memory controller hub (NB / MCH) 202. Processing unit 206 may include one or more processors and may be implemented using one or more heterogeneous processor systems. Processing unit 206 may be a multi-core processor. In some implementations, graphics processor 210 may be coupled to NB / MCH 202 via an accelerated graphics port (AGP).

[0048] In the depicted example, local area network (LAN) adapter 212 is coupled to south bridge and I / O controller hub (SB / ICH) 204. Audio adapter 216, keyboard and mouse adapter 220, modem 222, read-only memory (ROM) 224, universal serial bus (USB) and other ports 232, and PCI / PCIe devices 234 are coupled to south bridge and I / O controller hub 204 via bus 238. Hard disk drive (HDD) or solid state drive (SSD) 226 and CD-ROM 230 are coupled to south bridge and I / O controller hub 204 via bus 240. PCI / PCIe devices 234 may include, for example, Ethernet adapters, add-in cards, and PC Cards for notebook computers. PCI uses a card bus controller, while PCIe does not. ROM 224 may be, for example, a flash binary input / output system (BIOS). Hard drive 226 and CD-ROM 230 may use, for example, an integrated drive electronics (IDE), serial advanced technology attachment (SATA) interface, or variations such as external SATA (eSATA) and micro SATA (mSATA). Super I / O (SIO) device 236 may be coupled to south bridge and I / O controller hub (SB / ICH) 204 via bus 238.

[0049] Memories, such as main memory 208, ROM 224, or flash memory (not shown), are some examples of computer-usable storage devices. Hard disk drives or solid-state drives 226, CD-ROMs 230, and other similarly available devices are some examples of computer-usable storage devices that include computer-usable storage media.

[0050] The operating system runs on the processing unit 206. The operating system coordinates and provides Figure 2The operating system controls the various components within data processing system 200. The operating system may be a commercially available operating system for any type of computing platform, including but not limited to server systems, personal computers, and mobile devices. Object-oriented or other types of programming systems may operate in conjunction with the operating system and provide calls to the operating system from programs or applications executing on data processing system 200.

[0051] for operating systems, object-oriented programming systems, and systems such as Figure 1 Instructions for an application or program, such as application 105 in FIG. 2 , are located on a storage device, such as in the form of code 226A on hard drive 226, and may be loaded into at least one of one or more memories, such as main memory 208, for execution by processing unit 206. The processes of the exemplary embodiments may be performed by processing unit 206 using computer-implemented instructions, which may be located in a memory, such as main memory 208, read-only memory 224, or in one or more peripheral devices.

[0052] Furthermore, in one embodiment, code 226A may be downloaded from remote system 201B via network 201A, where similar code 201C is stored on storage device 201D. In another embodiment, code 226A may be downloaded to remote system 201B via network 201A, where downloaded code 201C is stored on storage device 201D.

[0053] Figure 1-Figure 2 The hardware in can vary depending on the implementation. Figure 1-Figure 2 In addition to or in place of the hardware described in the drawings, other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, or optical disk drives may be used. In addition, the processes of the exemplary embodiments may be applied to a multi-processor data processing system.

[0054] In some illustrative examples, data processing system 200 may be a personal digital assistant (PDA), which is typically configured with flash memory to provide non-volatile memory for storing operating system files and / or user-generated data. A bus system may include one or more buses, such as a system bus, an I / O bus, and a PCI bus. Of course, a bus system may be implemented using any type of communication structure or architecture that provides for the transfer of data between different components or devices attached to the structure or architecture.

[0055] The communication unit may include one or more devices for sending and receiving data, such as a modem or a network adapter. A memory may be, for example, main memory 208 or a cache, such as that found in north bridge and memory controller hub 202. A processing unit may include one or more processors or CPUs.

[0056] Figure 1-Figure 2 The examples described in and above are not meant to imply architectural limitations. For example, data processing system 200 may be a tablet computer, laptop computer, or telephone device in addition to taking the form of a mobile or wearable device.

[0057] Where a computer or data processing system is depicted as a virtual machine, virtual appliance, or virtual component, the virtual machine, virtual appliance, or virtual component uses virtualized representations of some or all of the components depicted in data processing system 200 to operate in the manner of data processing system 200. For example, in the virtual machine, virtual appliance, or virtual component, processing unit 206 is represented as a virtualized instance of all or some number of hardware processing units 206 available in the host data processing system, main memory 208 is represented as a virtualized instance of all or some portion of main memory 208 available in the host data processing system, and disk 226 is represented as a virtualized instance of all or some portion of disk 226 available in the host data processing system. In this case, the host data processing system is represented by data processing system 200.

[0058] refer to Figure 3 , which depicts a block diagram of an example configuration for operating system code patching during live migration according to an exemplary embodiment. Application 300 is Figure 1 An example of application 105, and in Figure 1 Executed in any one of the servers 104 and 106, the clients 110, 112 and 114, and the device 132.

[0059] Application 300 executes as a kernel or user-level process within an operating system. Migration detection module 310 detects that a change has occurred in the hardware characteristics of the computer system on which the process is executing. In other words, a live migration has occurred, and application 300 is now executing on a different host. Migration detection module 310 also determines that due to the change in hardware characteristics, a portion of the operating system code must be modified to account for the change in hardware characteristics.

[0060] The processor message module 320 broadcasts a message to one or more other processors installed in the migrated system, causing the receiving processors to enter a wait state. After the broadcast, the processor message module 320 waits for the other processors installed in the migrated system to acknowledge the broadcast message. The processor's acknowledgement indicates that the processor is in a wait state and is blocked from accessing other parts of the operating system that may be modified.

[0061] Once all message handlers have been placed in a wait state, it is safe for the application 300 to modify the operating system code, and the OS modification module 330 modifies the operating system code to account for the change in hardware characteristics. Once the OS modification has been made, the processor message module 320 broadcasts a second message to the processors in the wait state, causing the receiving processors to return to normal operation.

[0062] refer to Figure 4 , which depicts a block diagram of an example configuration for operating system code patching during live migration according to an exemplary embodiment. In particular, Figure 4 Described Figure 3 More details on module 320 in .

[0063] The enter wait state module 410 broadcasts a message to one or more other processors installed in the migrated system, causing the receiving processor to enter a wait state. Following the broadcast, the confirmation module 420 waits for the other processors installed in the migrated system to acknowledge the broadcast message. The processor's acknowledgement indicates that the processor is in a wait state and is blocked from accessing other parts of the operating system that may be modified. Then, to return the receiving processor to normal operation, the exit wait state message module 430 broadcasts a second message to the processor in the wait state.

[0064] refer to Figure 5 , which depicts an example timing diagram of message flows during operating system code patching during live migration according to an exemplary embodiment. Figure 3 The same as in application 300.

[0065] Application 300 is a process executing in processor 502. In state 510, application 300 determines that a live migration has occurred and that a portion of the operating system code must be modified due to a change in hardware characteristics. In state 512, application 300 begins placing all other processors in the system undergoing the live migration into a wait state by broadcasting message 520 to the other processors. Alternatively, application 300 sends a separate version of message 520 to each other processor to be placed into a wait state. Message 520 is received by message handler 530 executing in processor 504. Processor 504 is an example of a group of other processors to be placed into a wait state. Specifically, in state 532, message handler 530 receives message 520, and in state 534, message handler 530 sends message 522, an acknowledgment, back to application 300. Next, in state 536, message handler 530 waits for a second message. In state 514, application 300 receives message 522 and, once all processors have acknowledged message 520, modifies the operating system's code to account for the change in hardware characteristics. Then, in state 516, application 300 broadcasts message 524 to processor 504, where message handler 530 waits in state 536. Message handler 530 receives message 524 and proceeds to state 536, where message handler 530 exits the message handler, returning processor 504 to normal operation. This example is not intended to be limiting. In particular, intermediate messages may occur between messages 520 and 522, and between messages 522 and 524. Similarly, if message 522 is not sent, or is sent but not successfully received, application 300 may be configured 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 may be executed on a per-processor basis, or for each processor that initially sent message 520.

[0066] refer to Figure 6 , which depicts a flow chart of an example process for patching operating system code during live migration according to an exemplary embodiment. Process 600 may be performed at Figure 3 or Figure 5 The application 300 is implemented in FIG.

[0067] In block 602, the application detects that a dynamic migration has occurred that changes the hardware characteristics of the computer system. In block 604, the application broadcasts a first 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 first message. In block 608, the application modifies a portion of a set of program instructions in the operating system to account for the change in hardware characteristics. In block 610, the application broadcasts a second message to the group of processors, causing them to exit the wait state. The application then terminates.

[0068] refer to Figure 7 , which depicts a flow chart of an example process for patching operating system code during live migration according to an exemplary embodiment. Process 700 may be performed at Figure 5 The message processing program 530 executed by the processor 504 is implemented in the message processing program 530.

[0069] In block 702, the process receives a first message instructing the message handler to wait for a second message. In block 704, the process acknowledges the first message. In block 706, the process waits until the second message is received. Then ("Yes" path of block 706), the process ends.

[0070] Thus, in exemplary embodiments, computer-implemented methods, systems or apparatus, and computer program products are provided for operating system code patching and other related features, functions, or operations during live migration. Where embodiments, or portions thereof, are described with respect to one type of device, the computer-implemented methods, systems or apparatus, computer program products, or portions thereof, are adapted or configured for use with appropriate and comparable representations of that type of device.

[0071] Where embodiments are described as being implemented in an application, delivery of the application in a Software as a Service (SaaS) model is contemplated within the scope of the exemplary embodiments. In a SaaS model, the ability to implement the application of the embodiments is provided to users by executing the application in a cloud infrastructure. Users can access the application using a variety of client devices through a thin client interface such as a web browser (e.g., web-based email) or other lightweight client applications. Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage of the cloud infrastructure. In some cases, users may not even manage or control the capabilities of the SaaS application. In some other cases, a SaaS implementation of an application may allow for limited possible exceptions to user-specific application configuration settings.

[0072] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon, the computer-readable program instructions being used to cause a processor to perform various aspects of the present invention.

[0073] A computer-readable storage medium can be a tangible device that can retain and store instructions used by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card or a raised structure in a groove on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (e.g., a light pulse by an optical fiber cable), or an electrical signal transmitted by a wire.

[0074] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0075] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or 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.) and procedural programming languages (such as "C" programming language 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 an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter case, 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 can be connected to an external computer (for example, using an Internet service provider through the Internet). In some embodiments, in order to perform various aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions.

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

[0077] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct the computer, programmable data processing device, and / or other equipment to operate in a specific manner, such that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0078] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0079] Flowchart and block diagram in the figure illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in flow chart or block diagram can represent the module, segment or part of instruction, which includes one or more executable instructions for realizing the specified logical function.In some alternative embodiments, the function noted in the frame may not occur in the order noted in the figure.For example, the two frames shown in succession can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of the frames in each frame of block diagram and / or flow chart illustration and block diagram and / or flow chart illustration can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special-purpose hardware and computer instructions.

Claims

1. A computer-implemented method comprising: detecting, for a process of an operating system, that a live migration has occurred, the detection being performed by detecting a change in a processor version of a computer system on which the process is executed; After detecting, broadcasting a first message to a group of processors, the first message causing each processor in the group of processors to enter a wait state; as well as While each processor in the set of processors is in the wait state, a portion of a set of program instructions of the operating system is modified. 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 a user process.

3. The computer-implemented method of claim 1 , wherein the wait state comprises a state in which a processor in the set of processors executes a message handler process until a second message is received, the message handler process comprising a kernel process of the operating system.

4. The computer-implemented method of claim 1 , further comprising: An acknowledgement of the first message is received from the set of processors, the acknowledgement confirming that a processor in the set of processors is in the wait state. The computer-implemented method of claim 1 , wherein the modifying adjusts the portion to account for the change in the processor version.

6. The computer-implemented method of claim 1, wherein the change in the processor version includes a change in process accounting, and the modifying adjusts the portion to implement the change in process accounting.

7. The computer-implemented method of claim 1 , further comprising: A second message is broadcast to the set of processors after the modification, the second message causing the set of processors to exit the wait state.

8. A computer-usable program product comprising program instructions, the program instructions comprising: Program instructions for detecting, for a process of an operating system, that a live migration has occurred, said detecting being performed by detecting a change in a processor version of a computer system on which said process is executing; program instructions for, after detecting, broadcasting a first message to a group of processors, the first message causing each processor in the group of processors to enter a wait state; as well as Program instructions for modifying a portion of a set of program instructions of the operating system while each processor in the set 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 set of processors is not executing a user process.

10. The computer usable program product of claim 8, wherein the wait state comprises a state in which a processor in the set of processors executes a message handler process until a second message is received, the message handler process comprising a kernel process of the operating system.

11. The computer usable program product of claim 8, further comprising: Program instructions for receiving an acknowledgment of the first message from the set of processors, the acknowledgment confirming that a processor in the set of processors is in the wait state.

12. The computer usable program product of claim 8, wherein said modifying adjusts said portion to account for changes in said processor version.

13. The computer usable program product of claim 8, wherein the change in processor version includes a change in process accounting, and the modifying adjusts the portion to implement the change in process accounting.

14. The computer usable program product of claim 8, further comprising: Program instructions for broadcasting a second message to the set of processors after the modifying, the second message causing the set of processors to exit the wait state.

15. The computer usable program product of claim 8, wherein: The stored program instructions are stored in at least one of one or more storage devices of the local data processing system and wherein the stored program instructions are transferred from the remote data processing system over the network.

16. The computer-usable program product of claim 8, wherein the stored program instructions are stored in at least one of 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 devices, and program instructions stored on at least one of the one or more storage devices, the program instructions being configured to be executed 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, for a process of an operating system, that a live migration has occurred, said detecting being performed by detecting a change in a processor version of a computer system on which said process is executing; program instructions for, after detecting, broadcasting a first message to a group of processors, the first message causing each processor in the group of processors to enter a wait state; as well as Program instructions for modifying a portion of a set of program instructions of the operating system while each processor in the set 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 a user process.

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 message handler process until a second message is received, the message handler process 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 set of processors, the acknowledgment confirming that a processor in the set of processors is in the wait state.

21. The computer system of claim 17, wherein the modifying adjusts the portion to account for a change in the processor version.

22. The computer system of claim 17, wherein the change in the processor version includes a change in process accounting, and the modifying adjusts the portion to implement the change in process accounting.

23. The computer system of claim 17, wherein: The stored program instructions also include: Program instructions for broadcasting a second message to the set of processors after the modifying, the second message causing the set of processors to exit the wait state.

24. A computer-readable storage medium storing program code, wherein when the program code is run on a computer, the program code is adapted to execute the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Migration program, information processing apparatus, computer system, and computer-readable recording medium having stored migration program

    US20060153188A1

  • Method and apparatus for processor migration from different processor states in a multi-processor computer system

    US6226734B1