Methods and apparatus for providing acceleration of virtual machines in virtual environments

A host server computer system that includes a hypervisor within a virtual space architecture running at least one virtualization, acceleration and management server and at least one virtual machine, at least one virtual disk that is read from and written to by the virtual machine, a cache agent residing in the virtual machine, wherein the cache agent intercepts read or write commands made by the virtual machine to the virtual disk, and a solid state drive. The solid state drive includes a non-volatile memory storage device, a cache device and a memory device driver providing a cache primitives application programming interface to the cache agent and a control interface to the virtualization, acceleration and management server.

BACKGROUND OF THE INVENTION

The present invention generally relates to virtual machine acceleration in virtual environments and, more particularly, applying a non-volatile memory-based cache architecture in a hypervisor environment.

Data center virtualization technologies are now well adopted into information technology infrastructures. As more and more applications are deployed in a virtualized infrastructure, there is a growing need for performance acceleration, virtualization services and business continuity in various levels.

A virtual server is a type of virtual machine, which as used herein refers to software that executes programs like a physical machine. Virtual servers are logical entities that run as software in a server virtualization infrastructure, referred to as a “hypervisor” or a virtual machine manager. A hypervisor provides storage device emulation, referred to as “virtual disks”, to virtual servers. Hypervisors implement virtual disks using back-end technologies, such as files on a dedicated file system, or raw mapping to physical devices.

Whereas physical servers run on hardware, virtual servers run their operating systems within an emulation layer that is provided by a hypervisor. Virtual servers may be implemented in software to perform the same tasks as physical servers. Such tasks include, for example, running server applications, such as database applications, customer relation management (CRM) applications, email servers, and the like. Most applications that run on physical servers are portable to run on virtual servers. Within the context of virtualization, one distinction should be mentioned for clarification purposes, which is, the distinction between virtual desktops and virtual servers: virtual desktops run client side applications and service individual users, whereas virtual servers run applications that service multiple and potentially large numbers of clients.

The goal of virtual servers is to provide high performance, high availability, data integrity and data continuity. Virtual servers are dynamic in the sense that they may be moved from one host server computer system to another. This also entails that on a single host server computer system the number of virtual servers may vary over time since virtual machines can be added and removed from the host server computer system at any time.

As computing resources, such as CPU and memory, are provided to the virtual server by the hypervisor, the main bottleneck for the virtual server's operation resides in the storage path. Hard disk drives (HDDs) in particular, being electro-mechanical devices with all their known drawbacks, are hampered by low performance, especially in random pattern workload situations due to their rotational and seek latencies.

A solid-state drive (SSD) is a drive that uses solid-state technology to store its information and provide access to the stored information via a storage interface. The most common SSDs use NAND flash memory arrays to store the data and a controller serving as the interface between the host server computer system and the NAND flash memory array. Such a controller can use internal DRAM or SRAM memory, battery backup, and other elements.

In contrast to a magnetic hard disk drive, a non-volatile memory-based storage device (SSD or raw flash, for example, direct memory mapped rather than a block device behind a SATA interface) is an electronic device and does not contain any moving parts. As a result, seek and rotational latencies inherent in hard disk drives are almost completely eliminated in non-volatile memory-based storage devices resulting in read and write requests being serviced in an immediate operation. Thus, a flash-based device has greatly improved performance over hard disk drives, especially in an environment defined by mostly small read and write operations with random patterns.

Due to the much higher cost of non-volatile memory-based storage and limited data retention relative to magnetic hard disks, back end storage mainly uses magnetic hard disks as the primary storage tier. However, non-volatile memory-based storage acceleration is achieved in the storage level, for example, by means of caching or tiering mechanisms.

Conventional virtualization acceleration systems for disk I/O are often implemented at the physical disk level, which means they are not specifically designed to handle the demands by the virtualization paradigm, for the simple reason that they are not implemented at the hypervisor level. Consequently, these systems are not fully virtualization aware. More specifically, acceleration implemented outside the hypervisor environment suffers from inefficiency, lack of coordination between the services, multiple services to manage and recover, and lack of synergy. Therefore, it is advantageous to establish a unified environment of acceleration in the hypervisor which is much more efficient, simpler to manage, and dynamically adaptive to the changing virtual machine storage needs and synergy.

Furthermore, commonly, the main storage is located outside the physical server in a storage area network (SAN) or network attached storage (NAS) configuration to allow for multiple accesses by all physical servers and allow migration of the virtual machine. In contrast, non-volatile memory-based storage devices for caching can be placed in the physical server itself, thus providing faster access to the media with lower latency due to the short distance compared to the external storage. The capacity of the cache is limited due to its location on the physical server. Therefore, efficient caching algorithms must make complex decisions on what part of the data to cache and what not to cache. In order to be successful, these advanced algorithms for caching also require the collection of storage usage statistics over time for making an informed decision on what to cache and when to cache it.

A major aspect in virtual environment acceleration compared to a physical environment (i.e., single server) is its heterogeneous nature. Because of the plurality of virtual machines, different workload peak times coincide with different workload patterns and different service levels required. For example, a virtual environment can host a database for transaction processing during the day, and switch to database analysis for the night in addition to virtual desktops that boot together at the start of a shift and so on. As a result, virtual environment caching should support multiple, diverse modes of acceleration, while providing shared and dynamic resources for different applications at different times.

In view of the above, it can be appreciated that there are certain problems, shortcomings or disadvantages associated with the prior art, and that it would be desirable if an improved system and method were available for virtual machine acceleration in virtual environments that implements cache mechanisms on the hypervisor level and implements efficient cache algorithms.

BRIEF DESCRIPTION OF THE INVENTION

The present invention provides systems and methods suitable for improved virtual machine acceleration in virtual environments by implementing cache mechanisms on a hypervisor level with efficient caching algorithms.

According to a first aspect of the invention, a system is provided that includes a host server computer system including a hypervisor within a virtual space architecture running at least one virtualization, acceleration and management server and at least one virtual machine, at least one virtual disk that is read from and written to by the virtual machine, a cache agent residing in the virtual machine and adapted to intercept read or write commands made by the virtual machine to the virtual disk, and a solid state drive. The solid state drive includes a non-volatile memory storage device, a cache device and a memory device driver providing a cache primitives application programming interface to the cache agent and a control interface to the virtualization, acceleration and management server.

According to a second aspect of the invention, a method is provided that uses accelerating, migrating and synchronizing virtual machines across a network of functionally connected host server computer systems. Each host server computer system includes a hypervisor within a virtual space architecture with at least one virtual machine, at least one virtualization, acceleration and management server to accelerate the virtual machine, a virtual disk to be written to and read from by the virtual machine, a cache agent residing in the virtual machine and operating to intercept read or write commands made by the virtual machine to the virtual disk, and a solid state drive including a non-volatile memory storage device, a cache device and a memory device driver to provide access to the solid state drive by the hypervisor and cache primitives application programming interface. The method includes first detecting migration of the virtual machines from a first host server computer system to a second host server computer system. Next, the second host server computer system is informed of the migration of the virtual machines. Cache invalidation of the virtual machines that migrated from the first host server computer system to the second host server computer system is then performed and cache from the first host server computer system is transferred to the second host server computer system.

According to a third aspect of the invention, a system is provided that includes at least two host server computer systems interconnected by a network. Each host server computer system includes a hypervisor within a virtual space architecture running at least one virtualization, acceleration and management server, at least one virtual machine, at least one virtual disk that is read from and written to by the virtual machine, a cache agent residing in the virtual machine and adapted to intercept read or write commands made by the virtual machine to the virtual disk, and a solid state drive that includes a non-volatile memory storage device, a cache device and a memory device driver providing a cache primitives application programming interface to the cache agent and control interface to the virtualization, acceleration and management server. The virtualization, acceleration and management server is adapted to functionally couple any two of the host server computer systems to synchronize migration of the virtual machine and the virtual disk from one host server computer system to another host server computer system while maintaining the coherency of the cache devices in the two host server computer systems.

A technical effect of the invention is the ability to establish a unified environment of virtual machine acceleration in virtual environments that is implemented in the hypervisor level.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1illustrates a simplified block diagram of a hypervisor's virtual space architecture10including a hypervisor30running a plurality of accelerated virtual machines12and14, in this case at least two virtual servers, and a virtualization, acceleration and management server (VXS)20. The virtual space architecture is run on a host server computer system.

Each accelerated virtual machine12and14includes a cache agent16and18, respectively. The cache agents16and18are software modules that reside in a guest's operating system (OS). More specifically, the cache agents16and18are a software layer in the OS kernel (e.g., Windows® kernel or Linux® kernel). The cache agents16and18analyze and execute read and write commands made by the virtual machines12and14, respectively.

In a non-limiting example, the cache agents16and18can reside in the kernel below the file system and on top of a SCSI driver. For example, in a Windows® OS, it can reside below the NTFS module and on top of the StorPort module with Windows® standard application programming interface (API). In a Linux® OS, it can reside below a File System module (e.g., etx3 or etx4) and on top of the block I/O module. In both examples, the API to the cache agents16and18comprise SCSI command descriptor blocks (CDB) of block device commands according to the SCSI architecture model (SAM) as defined in SCSI block command (SBC) and SCSI primary command (SPC). This allows the cache agents16and18to provide block level acceleration. Alternatively, the cache agents16and18can reside on top of the file system in the OS kernel. For example, in a Windows® OS, it can reside between the IO Manager module and the NAS file system (CIFS or NTFS) module. In a Linux® kernel, it can reside between the virtual file system (VFS) and the NFS or file system (etx3, etx4 or else). Hence, this location enables file system acceleration as well as NAS acceleration.

The accelerated virtual machines12and14with their respective cache agents16and18may be functionally equivalent and therefore, for convenience purposes, the embodiment of the present invention represented inFIG. 1will be described herein generally with reference only to the accelerated virtual machine14and its respective cache agent18. As represented inFIG. 1, the cache agent18is connected to two types of storage devices, a virtual disk38which is a virtual storage entity created from a physical storage device (SAN or NAS) and a solid state drive (SSD)40which comprises at least one non-volatile memory storage device44, preferably a NAND flash-based memory device, combined with a memory device driver and a cache device42which is a logic element for processing the caching primitives and implementing caching algorithms that provides access interface and cache functionality. The memory device driver may provide a cache primitives application programming interface to the cache agent18and a control interface to the VXS20.

The cache device42may provide an interface of the block device according to SPC and SBC standards as well as a cache device interface via vendor specific commands.

The cache agent18is connected to the virtual disk38via a data path36and the cache device42via a data path34. This allows transfer of data between the cache agent18and the virtual disk38and SSD40. The cache agent18may be adapted to accelerate operation of the virtual machine14by using the memory device44for caching data read from the virtual disk38in the SSD40, retrieving cached data, caching data written to the virtual disk38in the SSD40and writing data to the virtual disk38.

The VXS20is a virtual machine that runs on the host server computer system where the accelerated virtual machines12and14are located. The VXS20is connected to the cache device42to receive and send metadata information through control path32to and from the cache device42via SCSI vendor specific commands.

The VXS20may also be used to process metadata information for the cache device42and send the results back to the cache device42. In this case, the VXS20processes offline information like histograms and hot zones and makes this information available to the cache device42.

Alternatively, the VXS20receives management directives from a management service24and passes them to the cache device42. Hence, the VXS20acts as a management gateway. Such directives can be management directives (e.g., firmware upgrade) or cache related directives (e.g., stop accelerate).

In a specific aspect of the invention, the VXS20may be configured to communicate with another VXS in another host server computer system across a network. Via this communication, once migration of the accelerated virtual machine14from one host server computer system to another is detected, the VXS20can inform another VXS of the migration and hence perform and coordinate actions of validation (flush) of non-relevant virtual machines (servers that migrated to another host server computer system) and cache transfer (transfer cache from the original host server computer system to the destination host server computer system).

The management service24may be run on a management server22which is connected to a vCenter26in a VMWare environment. The management service24can retrieve information from the vCenter26regarding the virtual environment. The management service24also has a user interface that communicates with a client28that enables a user to manage the virtual environment.

In a specific aspect of the invention, the management service24detects migration of virtual machines (V-Motion) from one host server computer system to another via the vCenter26. In this case, the management service24is responsible to invalidate (flush) the cache information (data and metadata) from the old host server computer system to maintain coherency of cache.

The management service24may be adapted to connect to any management server in another hypervisor environment, or act on its own to provide central management services.

FIG. 2illustrates a simplified block diagram representing communications between the cache agents16and18that reside in the virtual machines12and14, respectively, and the SSD40that implements a shared cache entity, that is, the SSD40is accessible by all virtual machines across a plurality of hypervisors. For convenience, consistent reference numbers are used throughout the drawings to identify the same or functionally equivalent elements. The cache agents16and18interact with the cache device42and the non-volatile memory storage device44via INVALIDATE, CHECK, WRITE CACHE and READ CACHE primitives, carried over vendor specific block (SCSI) commands.

The INVALIDATE primitive invalidates cache information from the cache device42. The command terminates after the data and metadata related to the requested data segment from the logical space are no longer valid in the cache device42.

The CHECK primitive checks if a data segment from the logical space or part of the data segment is valid in the cache device42. The command returns with a map of the available parts of the requested segment that are available in the cache device42.

The WRITE CACHE primitive asks to place a data segment from the logical space into the cache device42. There is no guarantee, however, that the data will be placed in the cache device42.

The READ CACHE primitive attempts to read a data segment from the logical space if it, or part of it, resides in the cache device42. The cache device42returns the available parts from the requested segment from the logical space if available.

FIG. 3is a simplified block diagram of the cache agent18representing communication flow from an upper layer toward storage and cache devices. The cache agent18communicates with the shared cache entity through the SSD40using cache primitives and with the virtual disks38and48via standard block device commands. The cache agent18further contains a configuration unit46to indicate which volumes of virtual disks38and48(from the assigned disks to the virtual machine12and14) to accelerate. As typically used in the art, the term volume refers herein to a logical drive or logical unit that is similar to a partition of a drive (it can be a partition but a partition does not have to be a logical unit or volume). The volume is visible to the file system and there may be several volumes on virtual disks38and48.

The cache agent18may be adapted to be transparent to incoming commands for non-accelerated virtual disks38and48and pass the commands as-is toward and from them.

For local accelerated virtual disks38and48, that is, virtual disks38and48that are running on the same physical sever, the cache agent18may use the SSD40to retrieve data (if they exist) and hence use a faster media to increase performance of the accelerated virtual disks38and48. The cache agent18also updates data in the SSD40to increase the chance of a “hit”, i.e., retrieving required data from the cache.

FIG. 4is a simplified flow chart representing a Write command arriving from an upper layer (e.g., file system layer) to the cache agent18. For non-accelerated virtual disks38and48, the Write command arrives at the cache agent18, and passes the command to a production volume52, thereby acting as transparent layer. For accelerated disks38and48, if a “cache on write” policy is configured, data are sent to the SSD40via the WRITE CACHE primitive and to the production volume52simultaneously. If, no “cache on write” policy is implemented, the cache agent18sends the CHECK primitive to the SSD40. If the data exist in the SSD40, it sends an INVALIDATE primitive to invalidate this data segment.

Additionally, every write command sent to the cache agent18is also sent to the virtual disk38or48. Hence, data are always placed in the external (SAN or NAS) that hosts the virtual disk38or48. As a result, a full copy of the virtual machines12and14data always resides in external storage, allowing volume migration and protection from power failure. In other words, the caching is done in “write-through” mode.

FIG. 5illustrates a simplified flow chart representing a Read command arriving from an upper layer (e.g., file system layer) to the cache agent18. When the Read command arrives at the cache agent18for non-accelerated volumes on virtual disks38and48, it passes the command to the production volume52and hence acts as transparent layer. For accelerated volumes on virtual disks38and48, it sends the CHECK primitive to the SSD40to see if the data segment exists in the cache. If the data segment resides in the cache, it sends the READ CACHE primitive to the SSD40. If the data segment does not reside in the cache, in the case of a cache miss, the cache agent18sends the command to the production volume52.

If only a part of the requested segment (but not all of it) resides in the cache, the cache agent18can retrieve the available part from the cache via the READ CACHE primitive and retrieve the missing part from the production volume52.

FIG. 6illustrates a simplified flow chart representing a Read command callback arriving from the production volume52with missing data. If a read callback arrives at the cache agent18from the production volume52for non-accelerated volumes on virtual disks38and48, the cache agent18sends the data upward and simply acts as transparent layer. For accelerated virtual disks38and48, the data are sent to upper layers as well as the SSD40via the WRITE CACHE primitive simultaneously.

FIG. 7is a block diagram representing the cache agent18having a configuration unit46to determine what kind of data should be accelerated and making an according determination whether data are accelerated or not. Non-accelerated data are sent to local virtual disks38and48whereas accelerated data are forwarded to a prediction layer54capable of predicting whether a data segment resides in the SSD40thereby reducing queries sent to the SSD40to query for data existence in the cache.

The prediction layer54has a bitmap image (not illustrated) that represents the logical space of the accelerated virtual disk38or48with page granularity (e.g., bits for 16K page size). When a segment of data is sent to the SSD40to be placed in the cache device42, the bits for the segments are set. Accordingly, if the corresponding bits in the prediction layer's54bitmap are not set, then the requested segments are not in the cache, which prohibits the use of the EXIST primitive (i.e., it can be concluded that the data do not exist in the cache) and reroutes the request to fetch the data from the production volume52. If the corresponding bits are set, the requested segments may be in the cache (i.e., they were sent to the SSD40and could have been cached). In this case, the cache agent18can assume that the data are in the cache and can send the READ CACHE primitive to the SSD40. The response to the READ CACHE primitive can be a “fail” response, as the data may have not been cached or may have already been removed from the cache; however, this scenario has a relatively low probability. Most likely, data will reside in the cache and the READ CACHE request will return a “success” response.

The SSD40also sends update information to the prediction layer54to identify data segments that were sent to the SSD40but were not cached or were previously removed from the cache. This information is sent periodically, for example, every minute, in the background in order not to load the cache agent18. Hence, the probability of the READ CACHE returning a “fail” further decreases.

FIG. 8is a block diagram representing communications between the accelerated virtual machine14with cache agent18, SSD40and VXS20. The SSD40may receive cache primitives from the cache agent18located in a virtual machine14. The VXS20may also communicate with the SSD40to send and receive control path information via vendor specific commands.

The VXS20may receive offline a list of the command descriptor blocks (CDB) sent to the SSD40from the accelerated virtual machine14. The VXS20processes these CDBs to provide information back to the SSD40. This information includes histograms of the workload, finding “hot” zones, i.e., zones in the address space that are used more frequently and hence should be placed in the cache. The VXS20may be adapted to use this information to provide offline processing of information for cache operation. The VXS20can process the control path data (i.e., CDBs) to provide statistics and other information to a management server, discussed hereinafter, to provide a visual or other readable format of the processed data for rule-base activation and graphical presentation to an administrator. The VXS20may further be adapted to provide cache management and policy enforcement via this workload information.

As represented inFIG. 8, the cache device42module may include a non-persistent cache map56(i.e., metadata information), a cache logic58module, configuration data60and information for a policy threshold62(i.e., histogram and analysis).

The cache device42may be a software layer (driver) that has block device interface and supports the caching primitives. The cache logic58is implemented as a software module in the host's kernel and the cache map56, the configuration data60and the policy threshold62are located in the host's memory.

Alternatively, the cache device42may be a thin driver interface in the host's kernel and the cache map56and cache logic58may be implemented in hardware, for example, located in the non-volatile memory storage device44.

Another alternative may be adapting the cache device42as a driver interface in the host's kernel, with hardware assistance (i.e., hardware engines located in the non-volatile memory storage device44) for implementing the cache map56and the cache logic58.

The cache logic58may maintain data in a page granularity, for example 16 KByte pages. The page size can be varied according to configuration data60to suit to a physical flash page or other hardware or software optimal value.

Additionally, the cache logic58may implement any suitable cache algorithm and metadata. For example, direct mapping of the data, N-way (e.g., 4 way) associative mapping or fully associative mapping.

The cache logic58may use the information provided by the VXS20for the decision of what data to place in the cache and remove from the cache. The decision is based on the command's zone temperature as measured by the VXS20. This will ensure that the data path34from the virtual machine14through the cache agent18and cache device42to the actual non-volatile memory storage device44is not loaded with any calculations of histograms, statistics and decision making, and therefore adds no overhead latency to the data path34.

As a corollary, the cache algorithm in the cache device42may use central information to provide shared and dynamic cache services to a plurality of accelerated virtual machines, such as virtual machines12and14, over several host server computer systems and their respective hypervisors.

The cache map56may be used as a way of finding the data in the cache, for example through tags. The policy threshold62defines how much data a volume may contain, that is, the level of fill, before the volume is subjected to garbage collection for the purpose of deleting invalid data. In other words, as soon as the policy threshold is reached, cache eviction through garbage collection is triggered. The configuration data60include ID, name and size of each volume and may also contain the time stamp of each cached data segment.

FIG. 9illustrates a block diagram of a heterogeneous virtual space with accelerated virtual machines12and14assigned to cache agents16and18, respectively, and a non-accelerated virtual machine64without any cache agent.

The SSD40may be adapted to serve a plurality of the accelerated virtual machines12and14via cache primitives through the cache device42and also a plurality of the non-accelerated virtual machines64via standard block device commands (read and write) and a block device66interface. Here, the non-volatile memory storage device44is partitioned via a-priori configuration into two partitions, a block device volume and a cache volume.

FIG. 10illustrates the flow of the CHECK primitive in the cache device42. The CHECK primitive is processed in the cache device42via a loop over the aligned pages (where a page can be 8K, 16K or any other size associated with the size of non-volatile memory storage device44) of the requested segment. Each page is checked to see if it resides in the cache device42and the assembled result is returned.

FIG. 11illustrates the flow of the INVALIDATE primitive in the cache device42. The INVALIDATE primitive is processed in the cache device42via a loop over the aligned pages (where a page can be 8K, 16K or any other size associated with the size of the non-volatile memory storage device44) of the requested segment. Each page is checked to see if it resides in the cache device42and if so, it is removed from the cache device42. After all pages are checked and invalidated (if needed), the result is returned.

FIG. 12shows the flow of the READ CACHE primitive in the cache device42. The READ CACHE primitive is processed in the cache device42via a loop over the aligned pages (where a page can be 8K, 16K or any other size associated with the size of the non-volatile memory storage device44) of the requested segment. Each page is checked to see if it resides in the cache device42and, if so, the data requested are returned in a chunk. The READ CACHE primitive can return a full segment only if it exists; otherwise it will return a partial segment (parts of the requested segment that exist in the cache device42) according to a directive in the READ CACHE primitive.

The partial segment of data can be in two forms, either two consecutive chunks or a scattered gather list (SGL) of chunks as represented inFIG. 12. While two consecutive chunks can be retrieved with two IO requests (one from the non-volatile memory storage device44and one from the virtual disk38), SGL may be placed with multiple IO requests. Therefore, the SGL is preferably retrieved with one IO from the virtual disk38to reduce retrieval time.

FIG. 13illustrates the flow of the WRITE CACHE primitive in the cache device42. The WRITE CACHE primitive is processed in the cache device42via a loop over the pages (where a page can be 8K, 16K or any other size associates with the size of the non-volatile memory storage device44) of the requested segment (data segment is provided aligned). Each page is checked according to the volume's policy to see if it should be placed in the cache. This policy is driven by information that is processed in the VXS20and sent to the cache device42. If the segment should be placed in the cache, it is decided where in the cache to place the data (and hence what existing data to remove). This decision is based on counters of recent usage, bank insertion policy (in case of N-Way cache algorithm) and other optimizations. The assembled status (what parts of the data segment were inserted to the cache) is returned.

FIG. 14depicts an additional configuration of the virtual environment in accordance with a further embodiment of the present invention. In this figure, consistent reference numbers are used, if possible, to identify the same or functionally equivalent elements, but with numerical prefixes (1 and 2) added to distinguish this particular embodiment from the embodiment ofFIG. 1. Specifically,FIG. 14illustrates the synchronization flow between two SSDs140and240via the conjoint VXS120and220. A host server computer system running a hypervisor130inside a virtual space architecture110includes a VXS120and a virtual machine112with a cache agent116. A second host server computer system running a hypervisor230inside a virtual space architecture230includes a VXS220and a virtual machine212with a cache agent216. VXS120and220communicate via an IP network. The hypervisor130includes a virtual disk138and a SSD140that further includes a cache device142, a non-volatile memory storage device144and a memory device driver. The cache agent116communicates with the virtual disk138and SSD140via data paths136and134respectively and VXS120communicates with SSD140via a control path132. The hypervisor230includes a virtual disk238and SSD240that further includes a cache device242, a non-volatile memory storage device244and a memory device driver. Cache agent216communicates with the virtual disk238and SSD244via data paths234and236, respectively and VXS220communicates with SSD244via a control path232.

The VXS120and220functionally couple the hypervisors130and230in order to synchronize migration of virtual machines. Therefore, in order to share the cache information of SSD140with SSD240, VXS120retrieves the cached metadata (list of logical addresses and lengths) from SSD140and sends it to VXS220. VXS220then sends the metadata to SSD240. As a result, if the virtual machine112migrates into the virtual space architecture210, its cached data can be retrieved immediately without having to re-populate the cache from scratch, thereby allowing it to continue with its “hot” data cached.

While the invention has been described in terms of specific embodiments, it is apparent that other forms could be adopted by one skilled in the art. For example functionally equivalent memory technology may supersede the NAND flash memory taught in this disclosure and multiple forms of networking could be used to functionally couple the physical servers. Therefore, the scope of the invention is to be limited only by the following claims.