Method and apparatus for swapping virtual machine memory

A method and system for swapping memory of a virtual machine are described. In one embodiment, virtual machines are hosted by a server and accessed by remote clients over a network. The server assigns first storage and second storage to each virtual machine, where the first storage is designated for swap memory of a respective virtual machine and the second storage is designated for persistent data of a respective virtual machine. The server monitors events pertaining to the virtual machines. Upon detecting a predefined event pertaining to one of the virtual machines, the server causes the contents of the first storage to be wiped out.

Embodiments of the present invention relate to management of virtual machines, and more specifically, to swapping virtual machine memory.

BACKGROUND

Virtualization allows multiplexing of the underlying host machine between different virtual machines. The host computer allocates a certain amount of its resources to each of the virtual machines. Each virtual machine is then able to use the allocated resources to execute applications, including operating systems (referred to as guest operating systems). The software layer providing the virtualization is commonly referred to as a hypervisor and is also known as a virtual machine monitor (VMM), a kernel-based hypervisor or a host operating system. The hypervisor emulates the underlying hardware of the host computer, making the use of the virtual machine transparent to the guest operating system and the user of the computer.

In some systems, the host is a centralized server that is partitioned into multiple virtual machines to provide virtual desktops to the users. The centralized host manages the allocation of disk storage to the virtual machines. Some hosts pre-allocate a fixed amount of disk storage to each virtual machine. However, a virtual machine often expands and outgrows the pre-allocated storage space. One reason for the expansion is a growing number of swapped pages written to a disk by a virtual machine. Swapped pages are written to a disk when a guest operating system of the virtual machine needs to transfer pages from main memory to disk, in order to clean up the main memory for currently active applications. Presently, there is no efficient mechanism for removing swapped pages created by virtual machines. As a result, the accumulation of the swapped pages in the disk storage can affect the performance of virtual machines and reduce the speed of disk backup operations.

DETAILED DESCRIPTION

A method and system for swapping memories of virtual machines are described. Virtual machines may be hosted by a server and accessed by remote clients over a network. Each virtual machine is configured to use a separate storage device for swapped pages. The server monitors events pertaining to various virtual machines. Upon detecting a predefined event pertaining to one of the virtual machines, the server causes the swap files of this virtual machine to be whipped out from a corresponding storage device.

FIG. 1illustrates an exemplary network architecture100in which embodiments of the present invention may operate. The network architecture100may include a host103coupled to one or more clients101over a network102. The network102may be a private network (e.g., a local area network (LAN), wide area network (WAN), intranet, etc.) or a public network (e.g., the Internet). The host103may be coupled to a host controller107(via a network or directly). Alternatively, the host controller107may be part of the host103.

In one embodiment, the clients101may include computing devices that have a wide range of processing capabilities. Some or all of the clients101may be thin clients, which serve as access terminals for users and depend primarily on the host103for processing activities. For example, the client101may be a desktop computer, laptop computer, cellular phone, personal digital assistant (PDA), etc. The client101may run client applications such as a Web browser and a graphic user interface (GUI). The client101may also run other client applications to receive multimedia data streams or other data sent from the host103and re-direct the received data to a display or other user interface.

In one embodiment, the host103includes a server or a cluster of servers to run one or more virtual machines131. Each virtual machine131runs a guest operating system (OS) that may be different from one another. The guest OS may include Microsoft Windows, Linux, Solaris, Mac OS, etc. The host103may include a hypervisor (not shown) that emulates the underlying hardware platform for the virtual machines131. The hypervisor may also be known as a virtual machine monitor (VMM), a kernel-based hypervisor or a host operating system.

Each virtual machine131can be accessed by one or more of the clients101over the network102. In one scenario, the virtual machine131can provide a virtual desktop for the client101. The virtual machines131can be managed by the host controller107. The host controller107may also add a virtual machine, delete a virtual machine, balance the load on the server cluster, provide directory service to the virtual machines131, and perform other management functions.

The host103may also be coupled to data stores hosting images120and122of storage devices (e.g., disks) that store data of the virtual machines131. These storage devices (physical storage) may be part of local storage of the host103or remote storage (e.g., a storage area network (SAN) or network attached storage (NAS)) coupled to the host103. The data stores (e.g., repositories) hosting images120and122may reside on a single or multiple storage devices that may also be part of local storage of the host103or remote storage coupled to the host103. Images120and122of an individual virtual machine may be stored in one repository or different repositories. In addition, if a virtual machine has two or more users, a separate set of images120,122may be associated with each individual user and may be stored in a single repository or different repositories.

During operation, virtual machines131may create persistent data such as user profiles, database records, word processing documents, etc. In addition, guest operating systems create swap files when transferring pages from main memory to disk, in order to clean up the main memory for currently active applications. These swap files accumulate over time and can take up a significant amount of storage space.

Embodiments of the present invention address the above problem by assigning, to each virtual machine131, one or more disks designated for persistent data and at least one separate disk designated for swap files. In one embodiment, the swap files include hibernate files created by the guest operating system when entering into hibernation. The hibernate files include data reflecting the state of the virtual machine at the time of hibernation.

The disks designated for persistent data and the disks designated for swap files may be of two different types. In particular, the disks designated for swap files may use a significantly cheaper and less redundant (or non-redundant) storage due to the short-lived nature of their contents.

InFIG. 1, images of disks designated for persistent data are shown as virtual machine (VM) disk images1(images122), and images of disks designated for swap memory are shown as VM disk images2(images120). In one embodiment, the guest operating system of each virtual machine131is configured to use VM disk images122for disk access requests associated with persistent data and to use VM disk images120for disk access requests pertaining to swap memory. The disk access requests may include read operations, write operations and delete operations. In other words, the guest operating system of a virtual machine131writes swapped pages to a VM disk image120, and moves swapped pages back to main memory from the VM disk image120when needed. The VM disk image120may have several swap areas.

In one embodiment, the host103includes a swap memory manager132that periodically wipes out swap files from VM disk images120. The swap memory manager132may be part of the hypervisor or be controlled by the hypervisor. The swap memory manager132may monitor events pertaining to individual virtual machines131(e.g., a shutdown event, a restart event, a stand by event, a hibernate event, a hard reboot event, a soft reboot event, etc.). Upon detecting a predefined event (e.g., a shutdown or restart event) pertaining to a specific virtual machine, the swap memory manager132causes the swap files of this virtual machine to be removed from a respective disk. For example, the swap memory manager132may delete a disk image120of this virtual machine and create a new disk image120for this virtual machine. Alternatively, the swap memory manager132may first select the swap files to be removed (e.g., based on the age of a swap file, the date a swap file was last modified or accessed, etc.), and then remove the selected swap files.

During backup, archive or remote mirroring (e.g., for disaster recovery) operations, the host103creates copies of VM disk images122but not VM disk images120. In addition, when creating a new virtual machine that is similar to an existing virtual machine131, the host103does not use the VM disk image120for cloning.

With embodiments of the present invention, the amount of storage space utilized by the virtual machines is substantially reduced, and disk backup, archive and remote mirroring operations are simplified and take significantly less time. In addition, by using a cheaper storage for disks designated for swap files, the overall cost of storage devices utilized by the virtual machines is significantly reduced.

FIG. 2is a block diagram of one embodiment of a host200that may represent a server or a cluster of servers hosting virtual machines202. Each virtual machine202includes a guest operating system (OS)204. The guest operating systems204can be any operating systems, such as Microsoft Windows, Linux, Solaris, Mac OS, etc. Each guest OS204manages a file system for its associated virtual machine202.

In one embodiment, each guest OS204is configured to use a VM disk image216for disk access requests associated with swap files, and to use a VM disk image218for disk access requests associated with persistent data.

As an example, a Linux guest OS may be configured to format the swap partition using the command “mkswap-L swap1/dev/sdb,” where “/dev/sdb” represents the storage device designated for storage of swap data. This command can be optionally used when there is a need to wipe the swap data each boot. In one embodiment, the swap data is wiped at least once, either within the guest OS or outside the guest OS. In another example, a Linux guest OS may be configured to deactivate a previous swap using the command “swapoff-a,” and it may be configured to activate a new device for swap data using the command “swapon-L swap1.” It should be noted, however, that the above commands are provided for the purpose of illustration only, and various other approaches can be used to provide the described functionality without loss of generality.

The guest OS204may include a data operation handler206that receives a disk access request from the guest OS204and determines whether this request pertains to swap memory. A disk access request pertaining to swap memory may be a write request (e.g., create a new swap file, update an existing swap file or delete a swap file), or a read request to read a swap file (e.g., to move its contents to main memory). If the data operation handler206determines that the requested disk access request pertains to swap memory, it performs the requested data operation using the VM disk image216. If the data operation handler206determines that the requested disk access request pertains to persistent data, it performs the requested data operation using the VM disk image218.

The host200includes a hypervisor (not shown) that manages the virtual machines202. The hypervisor may contain or otherwise control a swap memory manager208. The swap memory manager208may include a storage assignor210, a swap memory cleaning module212, and a backup module214. Alternatively, some or all of the above components may be external to the swap memory manager208and may communicate with the swap memory manager208via a network or a local means.

The storage assignor210allocates storage to a virtual machine being added to the host200. In particular, the storage assignor210assigns, to the virtual machine, one or more disks designated for persistent data and one or more disks designated for swap files. Images (218,216) of these disks are maintained in a single repository or separate repositories accessible to the swap memory manager208. In one embodiment, the storage assignor210provides a user interface allowing a user (e.g., a system administrator) to assign the above disks to a new virtual machine. Alternatively, the disks are assigned to a new virtual machine automatically.

The swap memory cleaning module212monitors events pertaining to individual virtual machines to detect predefined events that trigger cleaning of swap files. The predefined events may be specified by a system administrator (e.g., via a user interface) or hard-coded. Upon detecting a predefined event (e.g., a shut down or restart event) pertaining to a specific virtual machine, the swap memory cleaning module212causes the swap files of this virtual machine to be wiped out. This can be accomplished by deleting a disk image216of the virtual machine and creating a new disk image216for this virtual machine, or by removing all swap files or a subset of swap files from the disk image216of the virtual machine. The subset of swap files to be removed can be determined based on, for example, the age of a swap file, the date a swap file was last modified or accessed, etc.

The backup module214manages backups and archives of the storage utilized by the virtual machines202by including disk images218, but not disk images216, in backup and archive operations.

FIG. 3is a flow diagram illustrating one embodiment of a method300for swapping memory of a virtual machine. The method300may be performed by processing logic526ofFIG. 5that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device to perform hardware simulation), or a combination thereof. In one embodiment, the method300is performed by a guest operating system204of a virtual machine202(FIG. 2).

Referring toFIG. 3, the method300begins with processing logic identifying a disk access request (block302). The disk access request may be a request of a guest operating system or an application of a virtual machine. The disk access request may be a request to add new data to a disk, update existing data on a disk, or delete existing data from a disk.

At block304, processing logic determines whether the requested disk access pertains to swap memory. If so, processing logic causes the disk access request to be performed with respect to a disk designated for swap memory of the virtual machine (block306). In particular, depending on the requested disk access operation, processing logic adds a new swap file to an image of the disk designated for swap memory, updates an existing swap file in the image of the disk designated for temporary files or deletes an existing swap file from the image of the disk designated for temporary files.

Alternatively, if processing logic determines at block304that the requested disk access operation pertains to persistent data, processing logic causes the disk access operation to be performed on a disk designated for persistent data of the virtual machine (block308).

FIG. 4is a flow diagram illustrating one embodiment of a method400for managing swap files of virtual machines. The method400may be performed by processing logic526ofFIG. 5that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device to perform hardware simulation), or a combination thereof. In one embodiment, the method400is performed by the swap memory manager132on the host103(FIG. 1).

Referring toFIG. 4, method400begins with processing logic assigning a first storage and a second storage to each virtual machine being added to the host (block402). As discussed above, the first storage is designated for swap memory of a respective virtual machine and the second storage is designated for persistent data of a respective virtual machine. The first storage may be cheaper and require less redundancy than the second storage.

In one embodiment, processing logic also assigns to each virtual machine a third storage for temporary files (web page caches created by a browser application, etc.). Alternatively, temporary files are stored on the first storage or the second storage.

At block404, processing logic monitors events pertaining to the virtual machines running on the host (e.g., shutdown events, restart events, stand by events, hibernate events, hard reboot events, soft reboot events, etc.). At block406, processing logic detects a predefined event (e.g., restart or shutdown) pertaining to one of the virtual machines. The event indicates that cleaning of the swap files of the above virtual machine should take place.

At block408, processing logic causes the swap files of the above virtual machine to be removed from the first storage of this virtual machine. In particular, processing logic can delete a disk image of the first storage of this virtual machine, and create a new disk image for the first storage of the virtual machine. Alternatively, processing logic can delete swap files from the first storage or identify (e.g., based on the age of swap files, the date they were last modified, etc.) a subset of swap files of the virtual machine that should be removed, and then delete this subset from the image of the first storage of the virtual machine.

The computer system500may further include a network interface device522. The computer system500also may include a video display unit510(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device512(e.g., a keyboard), a cursor control device514(e.g., a mouse), and a signal generation device520(e.g., a speaker).

The secondary memory516may include a machine-readable storage medium (or more specifically a computer-readable storage medium)524on which is stored one or more sets of instructions (e.g., processing logic526) embodying any one or more of the methodologies or functions described herein. The processing logic526may also reside, completely or at least partially, within the main memory504and/or within the processing device502during execution thereof by the computer system500, the main memory504and the processing device502also constituting machine-readable storage media. The processing logic526may further be transmitted or received over a network via the network interface device522.