Improved performance of real-time updates across frames

Abstract

Embodiments of a method for performing a live update are provided. The method includes determining a migration type for a live migration to be performed from a source server to a target server; and performing the live migration from the source server to the target server. The method also includes maintaining pages to be migrated based on the migration type, tracking modifications in a hypervisor page table, and performing a reverse migration based on the migration type. Embodiments of a system and computer program product for performing a live update are also provided.

Description

Technical Field

[0001] The present invention relates to data migration, and more particularly, to enhancing the efficiency of real-time updates across frames. Background Art

[0002] Virtualization, as a technology, aims to insert a layer between a hardware platform and an operating system to execute applications. From a business continuity and disaster recovery perspective, virtualization offers the inherent advantage of environment portability. Specifically, moving an entire environment configured with multiple different applications is simply a matter of moving a virtual image from one supporting hardware platform to another. Furthermore, more robust computing environments can support the coexistence of multiple different virtual images while maintaining virtual separation between them. Consequently, a failure in one virtual image cannot compromise the integrity of other co-executing virtual images on the same hardware platform.

[0003] A virtual machine monitor, known in the art as a "hypervisor," manages the interaction between each virtual image and the underlying resources provided by the hardware platform.

[0004] In this regard, a bare metal hypervisor runs directly on the hardware platform, just as an operating system runs directly on the hardware. In contrast, a hosted hypervisor runs within a host operating system. In either case, the hypervisor can support the operation of different "guest operating system images" (called virtual machine (VM) images), with the number of VM images limited only by the processing resources of the VM container holding the VM image or the hardware platform itself.

[0005] Virtualization has proven particularly useful for end users who require separate computing environments for different types of applications while being limited to a single hardware platform. For example, it is common to provide virtualized guest operating systems native to a different hardware platform for a host operating system native to one type of hardware platform, so that applications requiring the presence of the guest operating system can coexist with other applications requiring the presence of the host operating system. In this way, end users do not need to provide separate computing environments, each supporting different types of applications. However, access to the underlying resources of a single hardware platform remains static, regardless of the guest operating system.

[0006] Virtualization environments have been deployed to aggregate different, interdependent applications within different VMs when composing application solutions. For example, an application server may execute within one VM, while a database management system may execute within a different VM, and further, a web server may execute within another VM. Each VM may be communicatively coupled to one another within a secure network; however, any given deployment of an application can be live migrated to a different deployment without disrupting the execution of other applications within the other VMs. In a typical live migration, a VM may be moved from one host server to another to facilitate server maintenance or to allow for improvements to the VM's hardware support. Consequently, live migration can prove to be a time-consuming process.

[0007] Therefore, there is a need in the art to solve the above problems. Summary of the Invention

[0008] From a first aspect, the present invention provides a computer-implemented method for performing live updates, the method comprising: determining a migration type for a live migration to be performed from a source server to a target server; performing the live migration from the source server to the target server; maintaining pages to be migrated based on the migration type; tracking modifications in a hypervisor page table; and performing a reverse migration based on the migration type.

[0009] From another aspect, the present invention provides a system for performing live updates, the system comprising: one or more processors; and at least one memory coupled to the one or more processors, wherein the one or more processors are configured to: determine a migration type for a live migration to be performed from a source server to a target server; perform a live migration from the source server to the target server; maintain pages to be migrated based on the migration type; track modifications in a hypervisor page table; and perform a reverse migration based on the migration type.

[0010] Viewed from another aspect, the present invention provides a computer program product for performing real-time updates, the computer program product comprising a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform a method for performing the steps of the present invention.

[0011] Viewed from another aspect, the invention provides a computer program stored on a computer readable medium and loadable into the internal memory of a digital computer, the computer program comprising software code portions for performing the steps of the invention when said program is run on a computer.

[0012] From another aspect, the present invention provides a computer program product for performing real-time updates, the computer program product comprising: a computer-readable storage medium having program instructions stored thereon, the program instructions being executable by a processor to cause the processor to: determine a migration type for a real-time migration to be performed from a source server to a target server; perform a real-time migration from the source server to the target server; based on the migration type, maintain pages to be migrated; track modifications in a hypervisor page table; and perform a reverse migration based on the migration type.

[0013] Embodiments of the present invention relate to a computer-implemented method for improving the efficiency of live updates across frames. A non-limiting example of the computer-implemented method includes determining a migration type for a live migration to be performed from a source server to a target server, and performing the live migration from the source server to the target server. The computer-implemented method also includes maintaining pages to be migrated based on the migration type, tracking modifications in a hypervisor page table, and performing a reverse migration based on the migration type.

[0014] Embodiments of the present invention relate to a system for improving the efficiency of live updates across frames. A non-limiting example of the system includes one or more processors and at least one memory coupled to the one or more processors. The one or more processors are configured to determine a migration type for a live migration to be performed from a source server to a target server and to perform the live migration from the source server to the target server. The one or more processors are further configured to maintain pages to be migrated based on the migration type, track modifications in a hypervisor page table, and perform a reverse migration based on the migration type.

[0015] Embodiments of the present invention relate to a computer program product for improving the efficiency of live updates across frames, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith. The program instructions are executable by a processor to cause the processor to perform a method. A non-limiting example of the method includes determining a migration type for a live migration to be performed from a source server to a target server, and performing the live migration from the source server to the target server. The computer-implemented method further includes maintaining pages to be migrated based on the migration type, tracking modifications in a hypervisor page table, and performing a reverse migration based on the migration type.

[0016] Additional technical features and advantages are achieved through the technology of the present invention. Embodiments and aspects of the present invention are described in detail herein, and these embodiments and aspects are considered to be part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The details to which the exclusive rights claimed herein are particularly pointed out and distinctly claimed are in the claims at the conclusion of the specification. The foregoing and other features and advantages of the embodiments of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0018] Figure 1 Depicting a cloud computing environment according to one or more embodiments of the present invention;

[0019] Figure 2 Depicts an abstract model layer according to one or more embodiments of the present invention;

[0020] Figure 3 A block diagram of a computer system for practicing the teachings herein is shown;

[0021] Figure 4 Another system according to one or more embodiments of the present invention is shown;

[0022] Figure 5 depicts a migration from a first server to a second server according to one or more embodiments of the present invention;

[0023] Figure 6 depicts the state of a system according to one or more embodiments of the present invention;

[0024] Figure 7 depicts the state of a system according to one or more embodiments of the present invention;

[0025] Figure 8 depicts a hypervisor table including a post-migration migration bit during the migration process described herein in accordance with one or more embodiments of the present invention;

[0026] Figure 9 depicts the state of a system according to one or more embodiments of the present invention; and

[0027] Figure 10 Depicted is a flow diagram of a method for performing migration according to one or more embodiments of the present invention.

[0028] The figures depicted herein are illustrative. Many variations of the figures or operations described herein may be made without departing from the spirit of the present invention. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "coupled" and variations thereof describe a communication path between two elements and do not imply a direct connection between elements without intervening elements / connections therebetween. All such variations are considered part of this specification.

[0029] In the drawings and the detailed description of the embodiments disclosed below, the various elements shown in the drawings are provided with two or three-digit reference numerals. With few exceptions, the leftmost (one or more) digits of each reference numeral correspond to the drawings in which its element is first shown. DETAILED DESCRIPTION

[0030] Various embodiments of the present invention are described herein with reference to the accompanying drawings. Without departing from the scope of the present invention, alternative embodiments of the present invention may be designed. In the following description and accompanying drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are set forth between elements. Unless otherwise specified, these connections and / or positional relationships may be direct or indirect, and the present invention is not intended to be restrictive in this respect. Therefore, the coupling of entities may refer to direct or indirect coupling, and the positional relationship between entities may be direct or indirect positional relationship. In addition, the various tasks and process steps described herein may be incorporated into a more comprehensive program or process with additional steps or functions not described in detail herein.

[0031] The following definitions and abbreviations will be used to interpret the claims and specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or "contains," "containing," or any other variations thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

[0032] Additionally, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" may be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "plurality" may be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connected" may include both indirect and direct "connections."

[0033] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with measurements of a particular quantity based on the equipment available at the time the application is filed. For example, "about" may include a range of ±8%, or 5%, or 2% of a given value.

[0034] For the sake of brevity, conventional techniques related to making and using aspects of the present invention may or may not be described in detail herein. In particular, various aspects of the computing systems and specific computer programs used to implement the various technical features described herein are well known. Thus, for the sake of brevity, many conventional implementation details are only briefly mentioned herein or omitted entirely, without providing well-known system and / or process details.

[0035] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings described herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0036] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0037] Features are as follows:

[0038] On-demand self-service: A cloud consumer can unilaterally and automatically provision computing capacity, such as server time and network storage, as needed, without requiring human interaction with the provider of the service.

[0039] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0040] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers typically do not have control or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0041] Rapid Elasticity: The ability to provision capacity quickly and elastically, in some cases automatically, to scale up quickly and release it quickly to scale down quickly. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0042] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the utilized services.

[0043] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, which can include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0044] The deployment model is as follows:

[0045] Private cloud: Cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0046] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0047] Public cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by the organization that sells cloud services.

[0048] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0049] The cloud computing environment is service-oriented and focuses on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure consisting of a network of interconnected nodes.

[0050] Now see Figure 1, depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The computing nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 1 The types of computing devices 54A-54N shown in FIG. 5 are intended to be illustrative only, and computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and / or network-addressable connection (eg, using a web browser).

[0051] Now see Figure 2 , showing the cloud computing environment 50 ( Figure 1 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 2 The components, layers, and functions shown in are intended to be illustrative only, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0052] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; servers based on RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage devices 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0053] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 ; virtual storage 72 ; virtual networks 73 , including virtual private networks; virtual applications and operating systems 74 ; and virtual clients 75 .

[0054] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources for performing tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-arrangement and procurement of cloud computing resources in anticipation of future requirements for the cloud computing resources according to the SLA.

[0055] The workload layer 90 provides examples of functionality that can take advantage of a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and action analysis and notification 96.

[0056] Turning now to an overview of technology more particularly related to aspects of the present invention, servers sometimes perform migrations for different reasons. Live migration allows clients to maintain operations during the migration process, thereby avoiding application downtime.

[0057] To implement a live update, an additional proxy LPAR is created with the same amount of system resources as the original. At the end of the live update operation, all processes and associated resources are transferred from the original LPAR to the proxy LPAR. In some cases, packaged servers may face challenges due to limited or insufficient resources to accommodate the proxy LPAR and the original LPAR during the live update operation. To overcome this limitation, live update includes the ability to migrate the VM (needing to undergo an update) to a different server (the target server) with sufficient processor and memory resources. The live update is performed on the target server. After the live update is complete, a reverse migration to the managed server is performed.

[0058] Live Partition Mobility (LPM) provides the ability to move a logical partition (LPAR) or virtual machine (VM) from one server to another without disrupting infrastructure services and workloads. The system's hypervisor, in conjunction with the Mobility Service Partition (MSP), manages the migration of LPAR / VM memory pages from one system to another. There are different types of migrations, including temporary and permanent migration processes. Temporary migrations move a logical partition to a different location or server for a period of time and then return it to the source location or server. Permanent migrations have no intention of returning the partition to the source server or location.

[0059] Live Update has the ability to migrate a VM (that needs to undergo an update) to a different server (target server) with sufficient processor and memory resources. Live Update is performed on the target server. After the live update is completed, a reverse migration to the hosted service is performed.

[0060] Live Update performs a live migration to a replacement server, performs a live update operation at the target server, and performs a subsequent migration back to the hosting or source server. Because the cross-server move includes LPM operations, it adds additional time consumption to the live update, thereby increasing the overall live update operation time.

[0061] LPM operations performed during a live update are only temporary migrations, as the LPAR / VM returns to its original hosting server once the live update operation is complete. LPM / live migrations to and from memory are not considered temporary moves. Round trips (two LPMs) degrade the performance of live updates. Currently, there is no existing technology in the hypervisor for tracking the status of migrated pages. Therefore, all memory pages are transferred during LPM, regardless of whether the pages are updated.

[0062] In other words, the page memory is not maintained during temporary migration, and the complete page memory must be transferred back to the source hypervisor when performing a temporary migration. In other words, permanent migrations and temporary migrations are treated the same. This results in increased latency during the reverse migration process because even pages that have not been modified are transferred back to the source server.

[0063] Turning now to an overview of various aspects of the present invention, one or more embodiments of the present invention address the aforementioned shortcomings of the prior art by providing techniques described herein that improve memory page transfer operation times by selecting only those memory pages that are written / updated after the first LPM.

[0064] The above aspects of the present invention address the shortcomings of the prior art by using an additional field that can be introduced into the hypervisor page table, which operates as a flag (modified after migration bit). The logical page number can be the same for both the front and back LVMs. The LU records this additional field by looking at the page table. When performing a reverse migration, the system will only transfer pages for which the modified after migration flag is set.

[0065] The hypervisor needs to know this additional field because it will be responsible for virtual-to-physical page mappings. It will only refer to physical page mappings. It will only refer to physical pages whose flag bit is set for logical pages. This should reduce the overall memory page transfer time. This additional field can be addressed as the Modified After Migration (MAM) bit.

[0066] Turning now to a more detailed description of various aspects of the present invention, Figure 3 A block diagram of an exemplary computer system (i.e., server) 12 operable for various embodiments of the present disclosure is shown. As shown, server 12 is merely one example of a suitable computer for migrating a logical partition (LPAR) from one machine to another and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present disclosure described herein.

[0067] Server 12 can operate in many other computing system environments or configurations. For example, server 12 can be a virtual partition on a physical host, a clustered server environment, or a distributed cloud computing environment including any of the above systems. When implemented in a distributed cloud computing environment, tasks can be performed by both local and remote servers 12 that are linked together and communicate via a communication network (such as network 99). In embodiments of the present invention, local and remote servers 12 can be referred to as source and target servers for real-time operating system migration. In addition, embodiments of server 12 include a standalone machine control point, also known as a hardware management console (HMC), which acts as a coordinator for inventory verification and real-time operating system migration. In another embodiment, server 12 can include a system management device that is configured to provide a single focus for system management, including hardware configuration and software, hardware, and network management in a multi-node or multi-server environment. Another embodiment of server 12 includes a virtual I / O server (VIOS), also known as a virtualization manager, which hosts virtual machines (also known as logical partitions (LPARs) or clients), manages the virtualization of physical hardware resources, and participates in real-time operating system migration.

[0068] The server 12 may be described in the context of executable instructions, such as programs, or more specifically, an operating system (OS) 40 as an aggregation of program modules 42, components, objects, logic, or data structures, which are executed, for example, by the processing unit 16 to control the operation of the server 12. Inventory verification and live operating system migration may be implemented as program modules 42 or as extensions to the OS 40. At least a portion of the OS 40 may be dedicated to performing Figure 3-Figure 4 algorithm.

[0069] Each participating server 12 is controlled by an OS 40 residing on each local and remote server 12. Each instance of a virtual machine emulates a physical computer. A physical computer can host multiple virtual machine instances, each sharing the physical computer's hardware resources and emulating the physical computer. Each virtual machine instance is controlled by an OS 40.

[0070] Components of server 12 may include, but are not limited to, one or more processors or processing units 16 , a system memory 28 , and a bus 18 that couples various system components (eg, system memory 28 ) to processing unit 16 .

[0071] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Server 12 may further include other removable / non-removable, volatile / nonvolatile computer system storage media.

[0072] By way of example only, storage system 34 may be provided as one or more devices for reading from and writing to non-removable, non-volatile magnetic media, such as a hard disk drive (HDD) or an optical drive such as a CD-ROM, DVD-ROM, or the like. Each device of storage system 34 may be connected to bus 18 via one or more data media interfaces. OS 40 and one or more application programs may be stored on storage system 34 and subsequently loaded into memory 28 for execution as needed.

[0073] The server 12 may also communicate with one or more external devices 14 (e.g., a keyboard, a pointing device, a display 24, etc.); with one or more devices that enable a user to interact with the server 12; and / or with any device that enables the server 12 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via the I / O interface 22.

[0074] The server 12 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 20. As shown, the network adapter 20 communicates with other components of the server 12 via a bus 18. However, in a multi-tenant data center (MTD) environment, such as a cloud computing environment, network communications may be routed through the member servers 12 and virtual machines through both physical devices (e.g., network adapters, network switches) and virtualized networks, such as those implemented using software-defined networking (SDN).

[0075] External storage adapter 26 connects server 12 to an external storage subsystem, such as a storage area network (SAN) 15. For live operating system migration, also known as a mobility event or live partition mobility, the source and target servers share a connection to SAN 15. The migrated virtual machine also has a virtual connection to SAN 15 through the source physical computer. Depending on the architecture implementation, exemplary external storage adapters 26 include, but are not limited to, host bus adapters (HBAs) (also known as Fibre Channel), host channel adapters (HCAs), SCSI, and iSCSI. External storage adapter 26 communicates with processing unit 16 and memory 28 of server 12 via bus 18.

[0076] It should be understood that, although not shown, other hardware and / or software components may be used in conjunction with server 12. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, tape drives, and data archival storage systems.

[0077] Figure 4 A system for reducing redundancy verification for live operating system migration is shown. This embodiment includes a source and a target server system 12. The source server system 12 includes LPARs 220 and 222, but a greater or lesser number of LPARs may be provisioned. An LPAR is assigned a subset of the computer's physical hardware resources (i.e., a subset of the hardware underlying the server environment) and is virtualized as a separate computer / virtual machine within the server environment. Resources such as processor capacity, virtual and physical I / O devices, memory, or any other type of resource may be assigned to a particular LPAR. Each LPAR has its own operating system instance (e.g., OS 224, 226, and 293), application programs (e.g., application(s) 228, 230, and 295), and / or associated files, thereby allowing multiple virtual environments to execute simultaneously within the server environment.

[0078] The dedicated LPARs 240 and 242 are dedicated to implementing I / O functions by executing VIOS software / firmware (software, logic, and / or executable code for performing various functions as described herein (e.g., hardware logic that resides as software and / or algorithms running on a processor unit, resides in a processor or other type of logic chip, is centralized in a single integrated circuit, or is distributed among different chips in a data processing system)). The logical partitioning, including virtualization of physical hardware resources, is facilitated by software / firmware hypervisors 246 and 248. The hypervisors 246 / 248 coordinate with the VIOS 240 / 242 and control point 250 to control and monitor the state and operation of the server system 12 hardware and software (including the LPAR's operating system). Depending on the embodiment, the hypervisors 246 / 248 may run directly on the computer system's hardware, may be combined with the VIOS, or may run within a conventional operating system environment.

[0079] The control point 250 cooperates with the VIOS 240 / 242 and hypervisors 246 / 248 to perform system server and LPAR management. The control point 250 or portions thereof can be implemented in any suitable manner using known technologies, which can be hardware-based, software-based, or some combination of the two. For example, the control point 250 can include software, logic, and / or executable code (e.g., software and / or algorithms resident on a processor unit, hardware logic resident in a processor or other type of logic chip, centralized in a single integrated circuit, or distributed across different chips in a data processing system) for performing the various functions described herein. In alternative embodiments, the portions of the control point operating system 215 that manage LPAR configuration files, perform LPAR operations (i.e., activate, deactivate, update), and perform inventory verification can be incorporated into the VIOS 240 / 242 operating system. Inventory verification, configuration profile management, and LPAR migration operations can be performed from the VIOS 240 / 242 and / or the control point 250. For example, in some embodiments, the display 24 of the control point 250 can be used to display various configuration profiles 205 and verification checklist 210 data that can be selected for mobility events for selection by the user / administrator. The selected information can be transmitted from the control point 250 to the VIOS LPAR 240 and / or 242.

[0080] Control point 250 includes a repository of configuration profiles 205. Each LPAR is associated with at least one profile that defines, among other parameters, the portion of hardware resources allocated to the LPAR on system server 12, an indication of priority for receiving additional system resources, and an operating system environment. Configuration profile 205 includes the LPAR's virtual and physical I / O device configurations. Control point 250 includes a validation manifest repository 210. Each LPAR is associated with a validation manifest in validation manifest repository 210. The LPAR's validation manifest may include a unique LPAR identifier, the mobility event source and target server systems, the LPAR's resources according to the LPAR's configuration profile 205, and an indication of whether pre-migration validation for a previous mobility event attempt passed or failed. Validation manifest repository 210 may be cached on control point 250. As part of the process of activating an LPAR, control point 250 locates the validation manifest from the LPAR's previous validation in validation manifest repository 210 and sends it to VIOS 240 / 242 on the server system where the LPAR is defined. VIOS 240 / 242 monitors LPARs for configuration changes that could invalidate the validation checklist, requiring full validation before a subsequent mobility event. Control point 250 can take one or more actions in response to notification of an LPAR's validation checklist invalidation from VIOS 240 / 242. For example, control point 250 can note that the LPAR requires full validation at the next mobility event. In another embodiment, control point 250, upon receiving the notification, can initiate full validation before the next mobility event and cache the results. In a further embodiment, control point 250 can initiate partial validation for newly modified, added, or removed resources. As shown, the same control point 250 manages both the source and target server systems 12. However, different control points 250 can manage the source and target server systems 12, for example, when the source and target server systems 12 are geographically separated.

[0081] exist Figure 2 In the illustrated embodiment, LPAR 222 is being migrated from source server system 12 to target server system 12. LPAR 288 does not exist on target server system 12 but will be dynamically created as part of the migration. While migration can be performed while the LPAR is inactive, the various embodiments herein are particularly well-suited for migrating execution workloads. LPARs can be migrated between different hardware platforms, and multiple LPARs can be migrated serially or simultaneously. The transfer or migration of LPAR 222 from source server system 12 to target server system 12 is coordinated by control point 250 in cooperation with hypervisors 246 and 248, with VIOS 240 and 242 acting as agents.

[0082] The configuration for the migration environment includes at least one physical HBA configured in each of the source and target VIOSs 240 / 242. These physical HBAs are configured to access the same logical unit numbers (LUNs), i.e., physical volumes, on the external storage subsystem 15 connected to the SAN 268. Each physical HBA is associated with one or more virtual Fibre Channel (VFC) adapters in each VIOS 240 / 242. LPAR 222 is configured with one or more VFC adapters from VIOS 240. During a mobility event, one or more additional VFC adapters are created on the target LPAR 288. During the migration, the memory pages of LPAR 222 are asynchronously copied from the source system server 12 to the target system server 12, and LPARs 222 and 288 maintain uninterrupted access to running applications.

[0083] The VFC adapter may implement N_Port ID Virtualization (NPIV) technology. A VFC adapter that implements NPIV technology may also be referred to as an NPIV adapter. NPIV allows a single HBA (referred to as N_Port in NPIV) to register multiple World Wide Port Names (WWPNs) and N_Port identification numbers. WWPNs uniquely identify endpoints on the SAN. Each VFC adapter is assigned a pair of WWPNs for accessing the LUNs of the LPAR on the external storage subsystem 15. During a mobility event, the migrating LPAR 222 uses one WWPN for connections through VIOS 240 and one WWPN for connections through VIOS 242. During the migration, LPAR 222 is temporarily active on both the source server system 12 and the target server system 12 while the memory pages of LPAR 222 are being transferred. Therefore, the WWPN pair maintains unique endpoint identity, as required for connection to SAN 268.

[0084] If the LPAR's validation manifest is marked as passed and unchanged since the LPAR's activation, VIOS 240 can proceed with the mobility event without performing validation. Thus, unnecessary validation checks can be avoided, thereby reducing migration time. The source VIOS 240 and target VIOS 242 communicate with each other via the public network 252 and / or the private network 254 through the service processors 260 / 262. The control point 250 uses both the contents of the validation manifest from LPAR 288 and the configuration profile 205 to create the target LPAR 288 on the target server system 12. The source hypervisor 246 sends and tracks memory pages from the source LPAR 222, enabling the migrating LPAR 222 to continue operating during the mobility event.

[0085] Now refer to Figure 5, shows a system for performing real-time updates across frames according to one or more embodiments. Figure 5 As shown, a first server (Server1) includes a first virtual machine (VM1) and a second virtual machine (VM2). VM1 is currently running a workload and an original kernel, and VM2 is also running a workload and an original kernel. The hypervisor table of VM1, which is also coupled to VM1, is stored in the server, as shown in the figure. It should be understood that any number of VMs can be run on Server1 and are not subject to change. Figure 5 Limitations of the examples shown.

[0086] In this illustrative example, a second server (Server2) includes VM3, which also runs the workload and the original kernel. Server2 can be selected as the target or destination of the migration. The migration can include a permanent migration or a temporary migration.

[0087] like Figure 6 As shown, the migration process has begun, and VM1's original HPT is stored on Server2. If a temporary migration is performed, Server1 retains the HPT state, the MSP state, and the OS / VM state. On the other hand, if a permanent migration is performed, Server1 does not maintain these states. Conventional technologies delete source-side / host-side state information after the migration to free up and release resources.

[0088] For temporary migration, VM1's HPT in Server2 is configured to track changes that occur during the migration process. Bits are used to indicate which changes occurred. The post-migration modified bits are maintained in the HPT on Server2 (VM1's hypervisor page table (originally in Server2)). In one or more embodiments of the present invention, the MAM bit is set to "1" for entries modified due to LPM.

[0089] Figure 7 The target Server2 is depicted, including the proxy LPAR, HPT, and the updated kernel residing on Server2. After the migration is complete, the workload is transferred to the proxy HPT (VM1 proxy node) and the kernel is updated. Similar to the original HPT, the proxy HPT also uses the MAM bit to track changes to memory pages during the kernel update.

[0090] After the update is complete, the proxy LPAR's HPT is searched to identify pages that were changed during the migration and kernel update. These pages are prepared for the reverse migration process to Server 1 and combined with the original LPAR's preserved state data to provide a complete instance of the LPAR. In one or more embodiments of the present invention, only these changes are propagated back to the source, providing substantial time savings during the process. While implementing this process, it should be understood that processes running on VM 1, VM 2, or VM 3 are not interrupted.

[0091] Now refer to Figure 8 , shows a table 800 for storing MAM bits according to one or more embodiments of the present invention. As discussed in the above example, the MAM bits are stored in the hypervisor page tables of the original node and the proxy node of Server2. Figure 8 Depicted is a first hypervisor table 810 stored in the HPT of VM1 on Server 1. The HPT of VM1 is stored in Server 1 and maps logical addresses (LP) to physical addresses (PP). Figure 8 Also depicted is a second hypervisor table 820 that includes a copy of VM1's HPT and is stored in Server 2. In one or more embodiments of the invention, the MAM bit is set to 1 for those pages that are modified during LPM. Figure 8 A third hypervisor table 830 is depicted including the HPT for VM1 (agent) stored in Server2. In one or more embodiments of the invention, the MAM bit is set to 1 for those modified due to a Live Update (LU).

[0092] Now refer to Figure 9 , shows Server1 and Server2 after performing a reverse migration for a temporary migration. During the reverse migration process, Server2's HPT is analyzed, and pages that have been modified during the migration and update process are identified and sent to the source Server1. The modified pages from Server2 are combined with the pages remaining in the source Server1 to provide a complete instance of the updated LPAR. As shown, Server2 has released the resources used to track updates for the temporary migration. Each VM remains online during the migration process, experiencing no downtime.

[0093] Now refer to Figure 10, a flow chart of a method 1000 for performing a migration according to one or more embodiments of the present invention is provided. Method 1000 begins at block 1002 and proceeds to block 1004, which provides for determining a migration type for a live migration to be performed from a source server to a target server. In one or more embodiments of the present invention, an operating system initiates a live partition migration. The mobility process transfers the system environment, including processor state, memory, attached virtual devices, and connected users, to another partition or another server.

[0094] Next, the operating system indicates whether the migration is temporary or permanent. If the migration is determined to be temporary, the source server maintains the state. If the migration is determined to be permanent, the source server invalidates the state information and releases resources after the migration. It should be understood that other types are contemplated within the scope of the present invention.

[0095] The source hypervisor / MSP determines that the migration type is temporary. The source hypervisor / MSP notifies the destination hypervisor / MSP that the migration type is temporary.

[0096] Block 1006 performs a live migration from the source server to the target server, and block 1008 maintains the pages to be migrated based on the migration type. In one or more embodiments of the present invention, if the migration type is a permanent migration type, the hypervisor page tables of the virtual machine or virtual server being migrated are released for use. If the migration type is a temporary migration type in which the virtual server or virtual machine will be reverse migrated to the source server, the hypervisor page tables and state information are maintained. In other words, the page tables and state information are stored and will be used during the reverse migration process.

[0097] Block 1010 tracks modifications in the hypervisor page table. In one or more embodiments of the present invention, a copy of the original hypervisor page table is stored on the target server. The hypervisor page table includes an additional bit (MAM bit) to track dirty pages or pages that have been updated during the migration process. When a page is received in the original hypervisor page table, the server maintains a copy of the page. The original hypervisor page table tracks modified pages during the migration.

[0098] After the migration process is complete, the proxy LPAR will be used to store updates for the kernel update process. During the kernel update, the proxy page table is used to track changes during the LKU. Similar to the original HPT, the proxy page table uses the MAM to track pages that have changed during the LKU.

[0099] Block 1012 performs a reverse migration based on the migration type. In one or more embodiments of the present invention, a reverse migration is performed when the migration type is a temporary migration. Only pages that have been modified during the live migration process and the live update process are transferred back to the source server. In other words, only those pages that have been updated as indicated by the MAM bit in the hypervisor page table are sent back to the source server. This improves overall migration time because all pages (regardless of whether they have been updated) no longer need to be transferred back to the source to complete the temporary migration.

[0100] After executing the LKU, the proxy HPT is ready for reverse migration. The processor creates a list of pages to be migrated by adding only those pages for which the MAM bit has been set. The reverse migration of the LPM to Server1 only transfers modified pages. In one or more embodiments of the present invention, the modified pages indicated by the MAM bit are merged with the retained pages to complete the migration process. At block 1014, the method 1000 ends. It should be understood that the method 1000 is not limited to Figure 10 Instead of following the steps shown in the , you can use a different order or different steps.

[0101] The techniques described herein improve live migration by maintaining a memory of pages, tracking changes to the memory, and transferring only the changed pages to the hypervisor to complete the temporary migration.

[0102] Technical effects and benefits include improving overall live update operation time by reducing LPM time. The hypervisor and MSP (mover service partition) only transfer pages that have been modified.

[0103] The present invention may be a system, method and / or computer program product of any possible degree of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to execute various aspects of the present invention.

[0104] Computer-readable storage media can be a tangible device that can retain and store instructions for use by an instruction execution device. Computer-readable storage media 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 disc (DVD), a memory stick, a floppy disk, a mechanical encoding device (for example, a punched card or a raised structure in a groove with instructions recorded thereon), and any suitable combination thereof. As used herein, computer-readable storage media should not be interpreted as a temporary signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (for example, light pulses passing through fiber optic cables), or electrical signals emitted by wires.

[0105] 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 (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission cables, wireless transmissions, 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.

[0106] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, the configuration data of integrated circuit or source code or the object code written in any combination of one or more programming languages, and these one or more programming languages ​​comprise object-oriented programming languages ​​(such as Smalltalk, C++ etc.) and process programming languages ​​(such as " C " programming languages ​​or similar programming languages).Computer-readable program instructions can be performed completely on user's computer, partly on user's computer, performed as independent software package, partly on user's computer, partly on remote computer or performed completely on remote computer or server.In the latter case, remote computer can be connected to user's computer by any type of network (comprising local area network (LAN) or wide area network (WAN)), or can (for example, using internet service provider by the internet) be connected to external computer.In certain embodiments, the electronic circuit comprising for example programmable logic circuit, field programmable gate array (FPGA) or programmable logic array (PLA) can make electronic circuit personalization carry out computer-readable program instructions by utilizing the state information of computer-readable program instructions, so as to perform aspects of the present invention.

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

[0108] 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, so 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, and these program instructions can direct the computer, programmable data processing device, and / or other equipment to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

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

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions and operations of possible implementations of the systems, methods and computer program products according to various embodiments of the present invention. To this end, each box in the flowchart or block diagram may represent a module, segment or portion of an instruction, which includes one or more executable instructions for implementing the specified (one or more) logical functions. In some alternative implementations, the functions annotated in the box may not occur in the order annotated in the figure. For example, depending on the functions involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the opposite order. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0111] The description of various embodiments of the present invention has been presented for the purpose of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments described herein.

Claims

1. A computer-implemented method for performing real-time updates, the method comprising: Determine the type of migration for live migration to be performed from the source server to the target server; Perform live migration of virtual machines from source to target servers; Maintaining pages to be migrated based on the migration type; Performing real-time updates of the virtual machine on the target server; tracking modifications during the live update in a hypervisor page table of a proxy virtual machine of the target server used in the live update; as well as A reverse migration of the updated virtual machine is performed based on the migration type. 2 . The computer-implemented method of claim 1 , further comprising tracking modifications during the live migration in a hypervisor page table of the original virtual machine of the target server. 3 . The computer-implemented method of claim 2 , further comprising tracking modifications occurring after the live migration is complete in a hypervisor page table of a proxy virtual machine of the target server. 4 . The computer-implemented method of claim 1 , further comprising determining whether the migration type is a permanent migration or a temporary migration. 5 . The computer-implemented method of claim 4 , in response to determining that the migration type is a permanent migration, freeing page memory of the source server associated with the permanent migration.

6. The computer-implemented method according to any one of claims 1 to 3, wherein: Tracking the modifications includes using post-migration modified (MAM) bits to indicate pages that have been modified.

7. The computer-implemented method of claim 6, wherein: The reverse migration transfers only the changes in the hypervisor page table indicated by the MAM bits, where the changes are combined with the pages maintained in the source server.

8. A system for performing real-time updates, the system comprising: one or more processors; as well as at least one memory coupled to the one or more processors, wherein the one or more processors are configured to: Determine the type of migration for live migration to be performed from the source server to the target server; Perform live migration of virtual machines from source to target servers; Maintaining pages to be migrated based on the migration type; Performing real-time updates of the virtual machine on the target server; tracking modifications during the live update in a hypervisor page table of a proxy virtual machine of the target server used in the live update; as well as A reverse migration of the updated virtual machine is performed based on the migration type.

9. The system according to claim 8, wherein: The one or more processors are configured to track modifications during the live migration in a hypervisor page table of an original virtual machine of the target server.

10. The system according to claim 9, wherein: The one or more processors are configured to track modifications that occur after the live migration is completed in a hypervisor page table of a proxy virtual machine of the target server.

11. The system according to any one of claims 8 to 10, wherein: The one or more processors are configured to determine whether the migration type is a permanent migration or a temporary migration. 12 . The system of claim 11 , wherein in response to determining that the migration type is a permanent migration, the one or more processors are configured to release page memory of the source server associated with the permanent migration.

13. The system according to any one of claims 8 to 10, wherein: Tracking the modifications uses the Migration Modified (MAM) bits to indicate pages that have been modified.

14. The system according to claim 13, wherein: The reverse migration transfers only the changes in the hypervisor page table indicated by the MAM bits, where the changes are combined with the pages maintained in the source server.

15. A computer program product for performing a real-time update, the computer program product comprising: A computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit to perform the method according to any one of claims 1 to 7.

16. A computer-readable medium on which a computer program is stored, said computer program being loadable into the internal memory of a digital computer, said computer program comprising software code portions for executing the method according to any one of claims 1 to 7 when said program is run on a computer.

Images