Virtual Machine Failover Using Distributed Shared Memory

Distributed shared memory is used to efficiently manage virtual machine failover by minimizing data copying and reducing recovery time through local cache updates and shared memory flushing, enabling rapid restart on a standby node.

JP2025531712APending Publication Date: 2025-09-25INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025512655
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2022-09-15
Filing Date
2023-09-11
Publication Date
2025-09-25

AI Technical Summary

Technical Problem

Current virtual machine failover systems require copying snapshot data across a network, limiting the ability to restart a virtual machine on a remote node and increasing recovery time.

Method used

A method utilizing distributed shared memory to write updates to a local cache and flush data to a shared memory device, capturing virtual CPU state and resetting an epoch timer to minimize data copying and improve recovery time.

Benefits of technology

Reduces data copying and minimizes recovery time by leveraging distributed shared memory for virtual machine failover, ensuring efficient and rapid restart on a standby node.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025531712000001_ABST
    Figure 2025531712000001_ABST
Patent Text Reader

Abstract

Virtual Machine Failover Using Distributed Shared Memory According to one aspect, a computer-implemented method includes running a program on a virtual machine on a first device having a local cache memory. Based on a determination that an epoch timer has not expired, the method includes writing one or more updates to the local cache memory and sending items evicted from the local cache memory to a shared memory device separate from the first device. Based on a determination that an epoch timer has expired, the method includes flushing the local cache memory to the shared memory device, sending a virtual CPU state of the virtual machine to the shared memory device, and resetting the epoch timer.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates generally to computer systems, and more particularly to computer systems, computer-implemented methods, and computer program products for providing failover for virtual machines using distributed shared memory. [Background technology]

[0002] In recent years, the use of distributed shared memory has become more common. Generally, distributed shared memory provides compute memory distribution, which allows multiple processors to be connected to the same memory resource (e.g., a type 3 memory device). In addition, compute memory distribution allows memory devices to be separated from processing devices, unlike most current architectures that combine processors and memory within the same physical server unit.

[0003] In general, the state of a virtual machine can be easily moved or copied to storage, which is also called a snapshot. The state of a virtual machine (VM) includes the virtual CPU state (e.g., registers, program counter), memory pages, and storage and network state. In current systems, the virtual CPU state and memory pages are copied to a remote server so that they can be accessed later in the event of a failure. In the event of a failure, the VM is restarted on the corresponding remote node using the latest copied snapshot of the virtual CPU and memory state. The problem with this approach is that the snapshot data needs to be copied across the network, and the restart can only occur on the node that created the snapshot data copy. Summary of the Invention

[0004] An embodiment of the present invention is directed to a computer-implemented method for providing failover of a virtual machine using distributed shared memory. The method includes running a program on a virtual machine on a first device having a local cache memory. Based on a determination that an epoch timer has not expired, the method includes writing one or more updates to the local cache memory and sending items evicted from the local cache memory to a shared memory device separate from the first device. Based on a determination that an epoch timer has expired, the method includes flushing the local cache memory to the shared memory device, sending a virtual CPU state of the virtual machine to the shared memory device, and resetting the epoch timer.

[0005] Other embodiments of the present invention implement features of the above-described methods in computer systems and computer program products.

[0006] Additional technical features and advantages are realized through the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, please refer to the detailed description and drawings. [Brief explanation of the drawings]

[0007] The details of the exclusive rights set forth herein are particularly pointed out and distinctly claimed in the claims at the conclusion of this specification. The above and other features and advantages of embodiments of the present invention will become apparent from the following detailed description when taken in conjunction with the accompanying drawings.

[0008] [Figure 1] FIG. 1 illustrates a block diagram of an exemplary computer system for use with one or more embodiments of the present invention.

[0009] [Figure 2]1 is a block diagram of a system for providing virtual machine failover using distributed shared memory in accordance with one or more embodiments of the present invention.

[0010] [Figure 3] 1 is a block diagram of a portion of a system for providing virtual machine failover using distributed shared memory in accordance with one or more embodiments of the present invention.

[0011] [Figure 4] 1 is a block diagram of a portion of a system for providing virtual machine failover using distributed shared memory in accordance with one or more embodiments of the present invention.

[0012] [Figure 5] 1 is a flowchart of a method for operating a virtual machine using distributed shared memory in accordance with one or more embodiments of the present invention.

[0013] [Figure 6] 1 is a flowchart of a method for virtual machine failover using distributed shared memory in accordance with one or more embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] As discussed above, a VM can currently only be restarted using the most recently copied snapshot of its virtual CPU and memory state on the computing system that created the snapshot data copy, which requires correcting any underlying problem in the computing system that caused the failure and copying the snapshot data back over the network to the computing system.

[0015] One or more embodiments of the present invention overcome these shortcomings by providing a method, system, and computer program product for virtual machine failover using distributed shared memory. In exemplary embodiments, efficient virtual machine restart is provided by leveraging shared memory in a distributed environment and minimizing the amount of data that needs to be copied. In exemplary embodiments, using distributed shared memory to provide virtual machine failover significantly reduces data copying and movement and improves recovery time.

[0016] Various aspects of the present invention are illustrated by text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0017] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media"), collectively contained in one or more storage devices, that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as pits / lands formed on a major surface of a punch card or disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals transmitted through wires, and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device temporary because the data is not temporary while it is stored.

[0018] Computing environment 100 comprises an example of an environment for execution of at least a portion of computer code involved in performing the methodology of the present invention, such as virtual machine failover using distributed shared memory 150. In addition to block 150, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes processor set 110 (including processing circuitry 120 and cache 121), communications fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 150, as identified above), peripheral device set 114 (including user interface (UI), device set 123, storage 124, and Internet of Things (IoT) sensor set 125), and network module 115. Remote server 104 includes remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0019] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this presentation of computing environment 100, to keep the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in FIG. 1 within a cloud, it may be located within a cloud. However, computer 101 is not required to reside within a cloud except to any extent that may be expressly indicated.

[0020] Processor set 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple tailored integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0021] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to execute a series of operational steps, thereby enabling a computer-implemented method, such that the instructions so executed instantiate the methods specified in the computer-implemented method flowcharts and / or descriptions contained herein (collectively referred to as the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least some of the instructions for executing the methods of the present invention may be stored in block 150 within persistent storage 113.

[0022] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as switches and conductive pathways that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic communication pathways and / or wireless communication pathways.

[0023] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, although this is not required unless expressly indicated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101, although alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0024] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or to persistent storage 113 directly. Persistent storage 113 can be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, including various known proprietary operating systems or open-source Portable Operating System Interface-type operating systems that employ a kernel. The code contained in block 150 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0025] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a Universal Serial Bus (USB)-type cable), pluggable connections (e.g., a Secure Digital (SD) card), connections made through a local area communication network, and even connections made through a wide area network such as the Internet. In various embodiments, the UI device set 123 may include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage 124 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. The storage 124 may be persistent and / or volatile. In some embodiments, the storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., where computer 101 stores and manages large databases locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple, geographically distributed computers. IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0026] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101 from an external computer or external storage device, typically through a network adapter card or network interface included in network module 115.

[0027] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances using any technology for communicating computer data now known or later developed. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0028] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 101) and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to the end user, the recommendations would typically be communicated from computer 101's network module 115 over WAN 102 to EUD 103. In this manner, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, and the like.

[0029] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on past data, this past data may be provided to computer 101 from remote database 130 of remote server 104.

[0030] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of public cloud 105 computing resources is performed by computer hardware and / or software in cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented by virtual computing environments running on various computers comprising host physical machine set 142, which is the universe of physical computers within and / or available in public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 143 and / or containers from container set 144. It is understood that these VCEs can be stored as images and can be transferred among and between various physical machine hosts, either as images or after instantiation of the VCE. The cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages active instantiations of VCE deployments. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate over the WAN 102.

[0031] Some further discussion of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0032] Private cloud 106 is similar to public cloud 105, except that its computing resources are available only for use by a single enterprise. While private cloud 106 is shown in communication with WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both public cloud 105 and private cloud 106 are part of a larger hybrid cloud.

[0033] In exemplary embodiments, a method, system, and computer program product are provided for failing over a virtual machine using distributed shared memory. In one embodiment, a virtual machine located on a first computing system is configured to store its main program memory in a shared memory device separate from the first computing system. When a failure of the first computing device is detected, the virtual machine is restored on a second computing system using its main program memory from the shared memory device.

[0034] Referring now to FIG. 2, a block diagram of a system 200 for providing failover for virtual machines using distributed shared memory is shown. As shown, system 200 includes a first computing system 210, also referred to herein as the active node, and a second computing system 220, also referred to herein as the standby node. The system also includes a shared memory device 240. In an exemplary embodiment, one or more of computing systems 210, 220, and shared memory device 240 may be embodied in computer 101, as shown in FIG. 1. Both computing system 210 and second computing system 220 are configured to communicate with shared memory device 240 via interconnect 230. In an exemplary embodiment, interconnect 230 is a high-speed communication link such as a Peripheral Component Interconnect Express (PCIe).

[0035] First computing system 210 includes program 211 running on guest operating system 212, which runs as a virtual machine on hypervisor 216. Hypervisor 216 manages resources of first computing system 210, including CPU 214 and local cache memory 215, and makes them available to guest OS 212 as virtualized devices. As used herein, vCPU refers to a virtualized CPU. First computing system 210 also includes manager 213 configured to monitor the operation of guest OS 212 and / or program 211.

[0036] Similar to first computing system 210, second computing system 220 includes guest operating system 222 running as a virtual machine on hypervisor 226. Hypervisor 226 manages resources of second computing system 221, including CPU 224 and local cache memory 225, and makes them available to guest OS 222 as virtualized devices. Second computing system 220 also includes manager 223 configured to monitor the operation of guest OS 222 and / or program 221.

[0037] In the exemplary embodiment, shared memory device 240 is configured to store main program memory 242 from program 211. CPU 214 is connected to cache coherent interconnect 230, which allows both CPUs 214 and 224 to directly access attached shared memory device 240 through load store instructions. The shared memory device may include volatile and / or non-volatile memory.

[0038] Main memory 242 for program 211, traditionally held in locally attached DRAM, is instead held in shared memory device 240. However, certain cache lines held in CPU 214 may not be coherent with shared memory device 600 and are typically volatile, i.e., lost in the event of a power failure or program reset. If any element of the active node fails, program 211 is restarted on the standby node by remote manager 223, and it transparently continues execution from where it left off (with some minimal loss of time and progress). In an exemplary embodiment, the failure of an element of the active node is detected by manager 213. During failover, the standby node is attached to shared memory device 240 via interconnect 230 and accesses main memory 242 of program 211.

[0039] In an exemplary embodiment, program 211 writes to local cache memory 215, and when items are evicted from local cache memory 215, they are written to main program memory 242. As is typical in current hardware architectures, cache lines cannot be forced to stay in cache and may be evicted at any time, and therefore written to shared memory. As a result, at any time, the current state of program 211 may be arbitrarily distributed across local cache memory 215 and shared memory device 240. In this case, when a failure occurs, program 211 cannot be restarted on a standby node with consistent data; that is, at least a portion of the data may be lost in local cache memory 215.

[0040] 3, a block diagram of a portion of a system 300 for providing virtual machine failover using distributed shared memory is shown, in accordance with one or more embodiments of the present invention. As shown, system 300 includes a shared memory device 340 connected to interconnect 330 via a memory controller 350. In an exemplary embodiment, memory controller 350 is configured to transparently provide support for undoing or rolling back changes to main program memory 342. These types of memory controllers 350 are applied to persistent memory to achieve crash consistency. In one embodiment, shared memory device 340 stores state main program memory 342 that is used to either rewind or roll forward main program memory 344.

[0041] In an exemplary embodiment, shared memory device 340 holds previous versions of a designated set of one or more memory regions in state main program memory 344. A program, or other software, specifies the start and end of a transaction. During the transaction, updates to main program memory 342 are made and logged. At the end of the transaction, the updates to main program memory 342 are applied to state main program memory 344 and the log is cleared. Additionally, at the end of the transaction, the state of the vCPU is captured and written to state main program memory 344.

[0042] In an exemplary embodiment, memory is continuously written to the shared memory device, but snapshots are still used. In one embodiment, a snapshot boundary (which occurs at the end of a defined epoch or in response to some trigger, for example, by an application) defines the point at which the hypervisor forces a flush of local cache memory to the shared memory device. In addition, the hypervisor also saves the vCPU state to the shared memory device at this point. Once all vCPU and page states are committed to shared memory, the transaction is completed and a new transaction can begin. An advantage of this solution is that a coherent state of the VM page and vCPU states can be successfully picked up by the standby node, and a new instance of the program can be created on the standby node. In an exemplary embodiment, the epoch timer that determines the frequency of snapshots is approximately 1 millisecond or less. As a result, the amount of data to be flushed is very small.

[0043] In an exemplary embodiment, both fixed epochs may trigger snapshots (i.e., hypervisor-controlled), as well as "application-triggered" snapshots, in which an application running within a guest VM may trigger a snapshot according to some application-defined criteria. In one embodiment, the hypervisor is configured to forcefully evict (write-back and invalidate) memory lines from local cache memory during a snapshot epoch to aggressively reduce the time required to achieve a quiescent state at the end of the snapshot.

[0044] 4, a block diagram of a portion of a system 400 for providing failover of virtual machines using distributed shared memory is shown, in accordance with one or more embodiments of the present invention. In the illustrated embodiment, system 400 includes a switch 460 configured to connect an active shared memory device 440 and a standby or backup shared memory device 441 to interconnect 430. In an exemplary embodiment, data stored on active shared memory device 440 may be replicated to backup shared memory device 441 using any known replication scheme. This allows the shared memory devices to operate in an active-standby or active-active model and tolerate failures of the shared memory devices. Although not shown, system 400 may also include a memory controller, such as the one shown in FIG. 3.

[0045] Referring now to FIG. 5, a flowchart of a method 500 for operating a virtual machine using distributed shared memory is shown, in accordance with one or more embodiments of the present invention. This flowchart has been described with reference to FIGS. 1-2 and may include additional steps not shown in FIG. 5. Although shown in a particular order, the blocks shown in FIG. 5 may be rearranged, subdivided, and / or combined. As indicated at block 502, the method 500 comprises operating a virtual machine on a first device having a local cache memory. Next, as indicated at decision block 504, the method 500 comprises determining whether an epoch timer has expired. Based on determining that the epoch timer has not expired, the method 500 proceeds to block 506 and writes one or more updates to the local cache memory. Next, as indicated at block 508, the method 500 comprises writing the items evicted from the local cache memory to a shared memory device separate from the first device.

[0046] Based on a determination that the epoch timer has expired, method 500 proceeds to block 510 and flushes the local cache memory to the shared memory device. Next, method 500 includes writing the virtual CPU state to the shared memory device, as depicted at block 512. Once the virtual CPU state is written to the shared memory device, method 500 includes updating a log in the shared memory device and committing the transaction to the shared memory device, as depicted at block 514. In an exemplary embodiment, the shared memory device is configured to update a log corresponding to the main memory for the program based on receiving the virtual CPU state of the virtual machine. Method 500 also includes resetting the epoch timer, as depicted at block 516. In an exemplary embodiment, if the epoch timer is reset, the first device sends a transaction start message to the shared memory device and, after the virtual CPU state is sent, sends a transaction end message to the shared memory device.

[0047] In an exemplary embodiment, the duration of the epoch timer is set by a hypervisor running on the first device. In one embodiment, the duration of the epoch timer is configurable to allow the hypervisor to balance the risk of data loss against the additional cost of increased network traffic.

[0048] Referring now to FIG. 6, a flowchart of a method 600 for virtual machine failover using distributed shared memory is shown, in accordance with one or more embodiments of the present invention. This flowchart has been described with reference to FIGS. 1-2 and may include additional steps not shown in FIG. 6. Although shown in a particular order, the blocks shown in FIG. 6 may be rearranged, subdivided, and / or combined. As indicated at block 602, method 600 comprises executing a program on a virtual machine on a first computing device. Next, as indicated at block 604, method 600 comprises storing main memory for the program in a shared memory device separate from the first computing device.

[0049] Method 600 also includes detecting a failure of the first device, as indicated at block 606. After a failure of the first device is detected, method 600 proceeds to block 608 and sends a notification of the failure to the second computing device. Next, as indicated at block 610, method 600 includes rolling back the main memory for the program on the shared memory device to a last good state, i.e., the state at the end of the last epoch timer when the previous virtual CPU state was written to the shared memory device. Method 600 also includes executing the program on a virtual machine on the second computing device, where the second computing device accesses the main memory for the program on the shared memory device, as indicated at block 612.

[0050] Technical advantages and benefits include improving the speed at which failed virtual machines can be restored and minimizing data loss during the failover process by providing a failover mechanism for virtual machines using distributed shared memory.

[0051] Various embodiments of the present invention are described herein with reference to the associated drawings. Alternative embodiments of the present invention may be devised without departing from the scope of the present invention. Various connections and relationships (e.g., above, below, adjacent, etc.) are described between elements in the following description and in the drawings. These connections and / or relationships may be direct or indirect unless otherwise specified, and the present invention is not intended to be limiting in this respect. Thus, coupling between entities may refer to either direct or indirect coupling, and relationships between entities may be direct or indirect. Furthermore, various tasks and process steps described herein may be combined into a more comprehensive procedure or process having additional steps or functionality not described in detail herein.

[0052] One or more of the methods described herein may be implemented using any or a combination of the following technologies: discrete logic circuitry having logic gates for implementing logical functions on data signals, application specific integrated circuits (ASICs) having appropriate combinatorial logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc., each of which is well known in the art.

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

[0054] In some embodiments, various functions or operations may be performed at a given location and / or in conjunction with the operation of one or more devices or systems. In some embodiments, a portion of a given function or operation may be performed at a first device or location, and the remainder of the function or operation may be performed at one or more additional devices or locations.

[0055] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It can be further understood that the terms "comprises" and / or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components of elements, and / or groups thereof.

[0056] In the following claims, the corresponding structure, material, acts, and equivalents of all means-plus-function or step-plus-function elements are intended to include any structure, material, or acts for performing the function as specifically claimed in combination with other claimed elements. While the present disclosure has been presented for purposes of illustration and description, it is not intended to be exhaustive or limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the invention. The embodiments have been chosen and described to best explain the principles and practical applications of the invention and to enable others skilled in the art to understand the invention in various embodiments with various modifications as may be suitable for the particular uses contemplated.

[0057] The diagrams shown herein are exemplary. There may be many variations of the diagrams or the steps (or operations) described therein without departing from the scope of the invention. For example, operations may be performed in a different order, or operations may be added, deleted, or modified. Also, the term "coupled" describes having a signal path between two elements and does not imply a direct connection between elements with no intervening elements / connections between them. All of these variations are considered part of this disclosure.

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

[0059] 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" are understood to include any integer greater than or equal to one, i.e., 1, 2, 3, 4, etc. The term "plurality" is understood to include any integer greater than or equal to two, i.e., 2, 3, 4, 5, etc. The term "connected" can include both an indirect "connected" and a direct "connected."

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

[0061] The present invention may be a system, method and / or computer program product integrated at any possible level of technical detail. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0062] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may 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 of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0063] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or 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 may comprise copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computing / processing device for storage.

[0064] The computer-readable program instructions for carrying out the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and procedural programming languages ​​such as the “C” programming language or similar. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

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

[0066] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein has an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0067] The 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 executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0068] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implements a specified logical function. In some alternative implementations, the functions noted in the blocks may occur in an order other than that noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or that executes a combination of dedicated hardware and computer instructions.

[0069] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable others skilled in the art to understand the embodiments described herein.

Claims

1. running a program on a virtual machine on a first device having a local cache memory; Based on determining that the epoch timer has not expired: writing one or more updates to the local cache memory; and transmitting the items evicted from the local cache memory to a shared memory device separate from the first device; An epoch timer is determined to have expired based on: flushing the local cache memory to the shared memory device; sending the virtual CPU state of the virtual machine to the shared memory device; and Resetting the epoch timer 1. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , wherein the duration of the epoch timer is set by a hypervisor associated with the virtual machine.

3. The computer-implemented method of claim 1 , further comprising sending a transaction start message to the shared memory device based on the epoch timer being reset.

4. The computer-implemented method of claim 1 , further comprising: upon determining that the epoch timer has expired, sending an end of transaction message to the shared memory device.

5. detecting a failure of the first device; and sending a notification of the failure to a second device, wherein the notification causes the program to execute on the second device. The computer-implemented method of claim 1 further comprising:

6. The computer-implemented method of claim 5 , wherein the second device is configured to access the shared memory device.

7. The computer-implemented method of claim 1 , wherein the shared memory device is configured to store main memory for the program.

8. 2. The computer-implemented method of claim 1, wherein the shared memory device is configured to update a log corresponding to the main memory for the program based on receiving the virtual CPU state of the virtual machine.

9. 9. The computer-implemented method of claim 8, wherein the update to the log marks previously received updates to the main memory for the program as committed.

10. a memory having computer-readable instructions; and one or more processors for executing the computer-readable instructions 10. A system comprising: running a program on a virtual machine on a first device having a local cache memory; Based on determining that the epoch timer has not expired: writing one or more updates to the local cache memory; and transmitting the items evicted from the local cache memory to a shared memory device separate from the first device; An epoch timer is determined to have expired based on: flushing the local cache memory to the shared memory device; sending the virtual CPU state of the virtual machine to the shared memory device; and resetting the epoch timer and controlling the one or more processors to perform operations comprising:

11. The system of claim 10 , wherein the duration of the epoch timer is set by a hypervisor associated with the virtual machine.

12. The system of claim 10 , wherein the actions further comprise sending a transaction start message to the shared memory device based on the epoch timer being reset.

13. 11. The system of claim 10, wherein the actions further comprise sending a transaction completion message to the shared memory device based on determining that the epoch timer has expired.

14. The operations are: detecting a failure of the first device; and sending a notification of the failure to a second device, wherein the notification causes the program to be executed on the second device; The system of claim 10 further comprising:

15. The system of claim 14 , wherein the second device is configured to access the shared memory device.

16. The system of claim 10 , wherein the shared memory device is configured to store main memory for the program.

17. The system of claim 10 , wherein the shared memory device is configured to update a log corresponding to the main memory for the program based on receiving the virtual CPU state of the virtual machine.

18. 20. The system of claim 17, wherein the update to the log marks previously received updates to the main memory for the program as committed.

19. 1. A computer program product comprising a computer-readable storage medium having program instructions embodied thereon, the program instructions causing a processor to: running a program on a virtual machine on a first device having a local cache memory; Based on determining that the epoch timer has not expired: writing one or more updates to the local cache memory; and transmitting the items evicted from the local cache memory to a shared memory device separate from the first device; An epoch timer is determined to have expired based on: flushing the local cache memory to the shared memory device; sending the virtual CPU state of the virtual machine to the shared memory device; and resetting the epoch timer a computer program product executable by the processor to cause the processor to perform operations having the steps:

20. 20. The computer program product of claim 19, wherein the duration of the epoch timer is set by a hypervisor associated with the virtual machine.