Storing files in blocks within composite images

It is common for modern computer systems to create different privilege contexts using containerization technologies. In general, containerization refers to the ability of a computer system to provide guest contexts (or partitions) in which one or more processes or even an entire operating system (OS) run in relative isolation. For instance, OS-level virtualization technologies refer to containerization in which guest contexts are isolated user-space instances created by a host OS kernel and in which user-space processes can run on top of that kernel in isolation from other guest contexts created by the same kernel. Examples of OS-level virtualization technologies include containers (DOCKER), Zones (SOLARIS), and jails (FREEBSD). Hypervisor-based virtualization technologies refer to containerization in which guest contexts are virtual hardware machines created by a host OS that includes a hypervisor and in which an entire additional OS can run in isolation from other virtual machines. Examples of hypervisor-based virtualization technologies include HYPER-V (MICROSOFT), XEN (LINUX), VMWARE, VIRTUALBOX (ORACLE), and BHYVE (FREEBSD).

Regardless of the containerization technology used, a guest context generally needs access to a filesystem volume, such as a filesystem volume comprising files for an OS, files for applications, and the like. As such, various disk and/or filesystem “image” formats are employed by various containerization technologies, each with its own benefits and drawbacks.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described supra. Instead, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.

In some aspects, the techniques described herein relate to methods, systems, and computer program products, including: determining to replace a first file of a filesystem volume that is contained within a composite image (CIM) with a second file; identifying a first file definition within a metadata portion of the CIM, the first file definition defining first data of the first file as including a first data block of a first region file of the CIM that includes a first plurality of equally-sized data blocks; and extending the CIM to include the second file, including: adding a second region file to the CIM that includes a second plurality of equally-sized data blocks, including writing a portion of data from the second file into a second data block of the second region file; and writing a second file definition to the metadata portion of the CIM, the second file definition defining second data of the second file as including, the first data block within the first region file; and the second data block of the second region file.

In some aspects, the techniques described herein relate to methods, systems, and computer program products, including: determining to replace a first file of a filesystem volume that is contained within a CIM with a second file; identifying a first file definition within a metadata portion of the CIM, the first file definition defining first data of the first file as including a first data block of a first region file of the CIM that includes a first plurality of equally-sized data blocks; and extending the CIM to include the second file, including: adding a second region file to the CIM that includes a second plurality of equally-sized data blocks, including writing a portion of data from the second file into a second data block of the second region file; and replacing the first file definition with a second file definition, the second file definition defining second data of the second file as including, the first data block within the first region file; and the second data block of the second region file.

In some aspects, the techniques described herein relate to methods, systems, and computer program products, including: determining to replace a first file of a filesystem volume that is contained within a CIM with a second file; identifying a first file definition within a metadata portion of the CIM, the first file definition defining first data of the first file as including a first data block of a first region file of the CIM that includes a first plurality of equally-sized data blocks; and extending the CIM to include the second file, including: adding a second region file to the CIM that includes a second plurality of equally-sized data blocks, including writing a portion of data from the second file into a second data block of the second region file; writing a second file definition to the metadata portion of the CIM, the second file definition defining second data of the second file as including the first data block within the first region file and the second data block of the second region file; and incrementing a reference count for the second data block.

This Summary introduces a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.

Some filesystem image formats used with containerization technologies are file-based. One family of file-based image formats, referred to herein as a composite image (CIM) format, comprises a first set of one or more files for storing metadata defining the files within a filesystem volume, as well as a second set of one or more files for storing those files' data. In this description and in the claims, any filesystem image that uses a CIM format is referred to as a CIM.

As mentioned, a CIM defines a filesystem volume using separated metadata and data. Using current CIM formats, a CIM comprises metadata comprising a set of metadata files (e.g., a metadata region file, an object identifier file, a filesystem description file) to define a filesystem volume and any files contained therein. For each file, the CIM's metadata defines relevant information such as a file name, a file identifier, a location of the file within a directory hierarchy, a set of file attributes (e.g., size, permissions, creation time, access time), and the like. Additionally, using current CIM formats, the CIM comprises a set of data region files to store the actual data of the files defined by the CIM's metadata. Each data region file comprises blob data that embodies the data of a plurality of the files defined by the CIM's metadata (e.g., the data of a plurality of files concatenated together, one after another). For each file that has data associated therewith (e.g., non-empty files), a CIM's metadata defines the location of that file's data within a single one of the CIM's data region files (e.g., using a byte offset and a byte length within that region file). A CIM filesystem uses the CIM's metadata to mount the CIM as a filesystem.

CIM formats facilitate efficiently deploying a filesystem volume embodied by a CIM to a given guest context. For example, when deploying a CIM to a guest context, each data region file can be extracted to destination storage as a single file rather than the multiple individual files contained therein. This is beneficial because writing a single larger file is often less time-consuming and computing resource intensive than writing a plurality of smaller files that, together, embody the same data as the single larger file. Thus, CIMs are faster to construct, extract, and delete than the equivalent raw directories they contain.

In some examples, modifying the filesystem volume within a CIM (e.g., to add, delete, or modify files or directories within the filesystem volume) involves extending (e.g., reconstructing) the CIM to include one or more new data region files.illustrate an example of extending a CIM that uses current CIM formats. Referring initially to, exampleshows a metadata portionand a data portionof a CIM, with metadata portionincluding file definitionto file definitionand data portionincluding a data region file. In example, file definitiondefines a first file within a filesystem volume, including referencing the first file's data within data region file(e.g., data); file definitiondefines a second file within the filesystem volume, including referencing the second file's data within data region file(e.g., data); and file definitiondefines a third file within the filesystem volume, including referencing the third file's data within data region file(e.g., data). As shown in, data region filecomprises variable-sized data portions, with each file defined by file definitions-being fully and contiguously contained within data region file. In some examples, file definitionto file definitioneach refers to their corresponding file data within data region fileby an offset (e.g., a number of bytes from the beginning of data region fileat which the corresponding file data begins) and a length (e.g., a number of bytes the corresponding file data occupies within data region file).

Referring now to, exampleshows the CIM ofafter it has been extended by replacing the first file within the filesystem volume with a larger version of the first file and adding two new files to the filesystem volume. As shown, extending the CIM includes adding a data region fileto data portion(now data portion′) and updating the file definitions within metadata portion(now data portion′). As shown, file definitionhas been updated (e.g., file definition′) to reference its files' data within data region file(e.g., data′) rather than data region file(now, data region file′). Additionally, file definitiondefines a fourth file within the filesystem volume, including referencing the fourth file's data within data region file(e.g., data); and file definitiondefines a fifth file within the filesystem volume, including referencing the fifth file's data within data region file′ (e.g., data). Notably, while datawas stored within a portion of data region file′ that was previously occupied by data, there remains a portion of data region file′ that is wasted (e.g., the shaded portion of data region file′).

The embodiments described herein address the foregoing inefficiencies of current CIM formats (e.g., waste of storage space when extending an existing CIM) while preserving their benefits (e.g., being faster to construct, extract, and delete than the equivalent raw directories they contain). These embodiments are based on introducing data region files that are comprised of fixed-size data blocks (e.g., as opposed to conventional variable file-sized data portions that contiguously store the entire data of a file). These embodiments are further based on referring to a given file's data based on a list of blocks within one or more data region files (e.g., as opposed to an offset and length within a single data region file). As will be demonstrated, using data region files that use fixed-size data blocks introduces opportunities to fully reuse space on existing data region files when extending a CIM. As will also be demonstrated, data region files that use fixed-size data blocks introduce novel opportunities to use block-level deduplication within a CIM.

illustrates an example of computer architecturethat uses block-based region files to extend a CIM. As shown, computer architectureincludes a computer systemcomprising a processor system(e.g., a single processor or a plurality of processors), a memory(e.g., system or main memory), and a storage medium(e.g., a single computer-readable storage medium, or a plurality of computer-readable storage media), all interconnected by a bus. As shown, computer systemmay also include a network interface(e.g., one or more network interface cards) for interconnecting (via a network) to computer system(e.g., a single computer system or a plurality of computer systems). Notably, the embodiments herein can be distributed across a plurality of computer systems. Thus, any of the components or data described herein (e.g., within memoryand/or storage medium) could reside, at least in part, at computer system. Additionally, any of the functionality described herein could be performed, at least in part, at computer system.

In, storage mediumis illustrated as storing computer-executable instructions implementing a CIM management componentthat manages the construction (e.g., creation and extension) of CIMs. In, storage mediumis illustrated as storing a directory hierarchy. In embodiments, CIM management componentcreates a new CIM (e.g., CIMin storage medium, CIMin memory) whose embodied filesystem volume mirrors directory hierarchy. For example, CIM management componentcreates a CIM comprising metadata defining the files within directory hierarchyas well as one or more data region files that comprise the data of the files within directory hierarchy. In embodiments, CIM management componentconstructs CIMwithin memory. In some embodiments, CIM management componentpersists CIMto storage mediumas CIM

In, storage mediumis illustrated as also storing a directory hierarchy. As indicated by an arrow extending from directory hierarchyto directory hierarchy, directory hierarchyis derived from directory hierarchy(e.g., by the addition of one or more objects (e.g., files or directories) to directory hierarchy, by the removal of one or more objects from directory hierarchy, by the modification of one or more objects within directory hierarchy). In embodiments, CIM management componentextends an existing CIM (e.g., CIMin storage medium, CIMin memory) whose filesystem volume embodies directory hierarchy, resulting in a CIM (e.g., CIMin storage medium, CIMin memory) whose embodied filesystem volume mirrors directory hierarchy. In embodiments, CIM management componentextends CIMwithin memory, resulting in CIMwithin memory. In some embodiments, CIM management componentpersists CIMto storage mediumas CIM

In some embodiments, directory hierarchyand directory hierarchycoexist (e.g., modifications to directory hierarchyare applied to a copy of directory hierarchy). In other embodiments, directory hierarchyreplaces directory hierarchy(e.g., modifications to directory hierarchyare applied to directory hierarchydirectly). In some embodiments, CIMand CIMcoexist (e.g., CIM management componentpersists CIMto CIMin storage mediumwhile retaining CIM). In other embodiments, CIMreplaces CIM(e.g., CIM management componentpersists CIMto CIMin storage mediumwhile removing or overwriting CIM).

illustrates an exampleof the CIM management componentof. Each component of CIM management componentdepicted inrepresents various functionalities that CIM management componentmay implement under the embodiments described herein. These components—including their identity and arrangement—are presented merely as an aid in describing example embodiments of CIM management component.

In example, CIM management componentincludes a filesystem management component. In embodiments, the filesystem management componentdetermines a structure of a filesystem volume that is to be contained within a CIM. In the context of creating a CIM, filesystem management componentdetermines a structure of a filesystem volume that mirrors an input directory hierarchy (e.g., directory hierarchy). In the context of extending a CIM, filesystem management componentdetermines one or more differences (e.g., added objects, removed objects, changed objects) between a directory hierarchy that is already represented by a CIM (e.g., directory hierarchyrepresented by CIM) and a target directory hierarchy (e.g., directory hierarchy).

In example, CIM management componentalso includes a metadata management component. In embodiments, the metadata management componentcreates and/or modifies the CIM metadata that defines a filesystem volume embodied by the CIM. In the context of creating a CIM, metadata management componentcreates new metadata representing the objects (e.g., files and directories) of an input directory hierarchy. In the context of extending a CIM, metadata management componentdetermines changes (e.g., modifications, additions, removals) to existing CIM metadata to capture the differences between a directory hierarchy that is already represented by a CIM and a target directory hierarchy.

In example, CIM management componentalso includes a data region file management component. In embodiments, the data region file management componentmanages one or more data region files contained within a CIM. Conventionally, CIMs comprised data regions, such as data region fileand data region filedescribed in connection with, that relied on using variable file-sized data portions to contiguously store the entirety of each file. While data region file management componentmay also support the creation and use of variable file-sized data portions, data region file management componentintroduces data region files that use fixed-size data blocks. As mentioned, using data region files that use variable file-sized data portions introduces opportunities to more fully reuse space on existing data region files when CIM management componentextends an existing CIM.

illustrate an example of extending a CIM that uses data region files comprising fixed-sized data portions. Referring initially to, and much like example, exampleshows a metadata portionand a data portionof a CIM, with metadata portionincluding file definitionto file definitionand data portionincluding a data region file. Data region fileof exampleused variable file-sized blocks; in contrast, exampleshows that data region fileuses fixed-sized blocks, including data blockto data block. In example, file definitiondefines a first file within a filesystem volume, including referencing the first file's data within data region fileby reference to data blocksand(collectively, data); file definitiondefines a second file within the filesystem volume, including referencing the second file's data within data region fileby reference to data blocksand(collectively, data), and file definitiondefines a third file within the filesystem volume, including referencing the third file's data within data region fileby reference to data block(data).

Referring now to, exampleshows the CIM ofafter it has been extended by replacing the first file within the filesystem volume with a larger version of the first file and adding two new files to the filesystem volume, much like in example. As shown in example, the CIM management componenthas extended the CIM by adding a data region file(e.g., data blockto data block) to data portion(now, data portion′), and updating the file definitions within metadata portion(now metadata portion′). As shown, file definitionhas been updated (e.g., file definition′) to reference data blockwithin data region file′, data blockwithin data region file, andwithin data region file(collectively, data′). In example, data blockwithin data region file′ is identical to data blockwithin data region file(e.g., because the data within that portion of the file did not change). However, in other examples, data blockwithin data region file′ is different from data blockwithin data region file(e.g., because the data within that portion of the file has changed). Additionally, file definitiondefines a fourth file within the filesystem volume, including referencing the fourth file's data within data region fileby reference to data block, data block, and data block(collectively, data). Finally, file definitiondefines a fifth file within the filesystem volume, including referencing the fifth file's data within data region file′ by reference to data block′ (data).

While the changes to the filesystem volume were much like in example(e.g., replacing the first file within the filesystem volume with a larger version of the first file and adding two new files to the filesystem volume), in exampleCIM management componenthas utilized fixed-size data blocks utilize space on data region file′ that was previously occupied by datamore efficiently than was the case for data region file′ in example. As a result, the CIM illustrated in exampleconsumes less space than the CIM illustrated in example, even though it was extended with the same files.

In some examples, CIM management componentalso includes a block deduplication component. The inclusion of block deduplication componentis enabled by the support of data region files that use fixed-size data blocks by the data region file management component. In embodiments, block deduplication componentgenerates a digest for each fixed-size data block, with each digest representing the data stored within its corresponding data block. In embodiments, block deduplication componentgenerates each digest using a hash function (e.g., a cryptographic hash function, such as one of the Secure Hash Algorithms published by the National Institute of Standards and Technology) that has strong collision resistance (e.g., which produces a unique digest for each unique input with a cryptographically significant degree of reliability). Using these digests, block deduplication componentreduces the size of data region files within CIMs by ensuring that only one copy of each unique data block exists within a CIM.

In some embodiments, block deduplication componentuses reference counting to determine when a data block is no longer being used. For example, block deduplication componentincrements a reference count for a given data block each time that block is referred to by a file definition and decrements the reference count when a reference to the data block is removed from a file definition. If the reference count reaches zero, then block deduplication componentfrees the data block.

illustrates an exampleof block-level deduplication within a CIM. In example, a file definitionreferences data blockrather than data block, as was the case in example. Thus, in example, block deduplication componenthas determined that the data stored on data blockand the portion of data that would have been stored on data blockare identical (e.g., based on those data blocks having the same digest). As a result, data region file management componenthas omitted data blockfrom data region file, and metadata management componenthas referenced data blockin place of data block. As a result, the CIM that is illustrated in exampleconsumes less space than the CIM that is illustrated in example, even though they were extended with the same files. Notably, although not illustrated in example, a single block can be used multiple times by different file definitions.

Embodiments are now described in connection with, which illustrates a flow chart of an example methodfor using block-based region files to extend a CIM. In embodiments, instructions for implementing methodare encoded as computer-executable instructions (e.g., CIM management component) stored on a computer storage media (e.g., storage medium) that are executable by a processor (e.g., processor system) to cause a computer system (e.g., computer system) to perform method.

The following discussion now refers to a method and method acts. Although the method acts are discussed in specific orders or are illustrated in a flow chart as occurring in a particular order, no order is required unless expressly stated or required because an act is dependent on another act being completed prior to the act being performed.

Referring to, in embodiments, methodcomprises actof identifying CIM metadata defining a first file to use a first data block of a first region file of a CIM. In some embodiments, actcomprises identifying a first file definition within a metadata portion of the CIM, the first file definition defining the first data of the first file as including a first data block of a first region file of the CIM that comprises a first plurality of equally-sized data blocks. For example, the metadata management componentidentifies file definitionfrom the metadata portionof the CIM of example, which, in this example, comprises CIMembodying a filesystem volume corresponding to directory hierarchy. As described, file definitionreferences data blockas being part of the dataof the file defined by file definition

Methodalso comprises actof identifying a second file to add to the CIM. In some embodiments, actcomprises determining to replace a first file of a filesystem volume that is contained within a CIM with a second file. For example, the filesystem management componentdetermines, based on directory hierarchy, that a file is to be added to the filesystem volume embodied by CIM. For example, the filesystem management componentdetermines that a file (e.g., the second file) within directory hierarchyreplaces a file (e.g., the first file) within directory hierarchy(e.g., the first file has been modified, resulting in the second file).

In, no order is specified between actand act. Thus, in various embodiments, these acts are performed serially (in either order) or in parallel. Regardless of their ordering, after actand act, methodalso comprises actof extending the CIM with the second file. In some embodiments, actcomprises extending the CIM to include the second file.

As shown, in some embodiments, actcomprises actof adding a second region file to the CIM. In some embodiments, actcomprises adding a second region file to the CIM that comprises a second plurality of equally-sized data blocks. For example, in example, the data region file management componentadds data region file, which comprises a plurality of fixed-sized blocks (e.g., data blockto data block).

As shown, in some embodiments, actcomprises actof writing data of the second file to a second data block of the second region file. In some embodiments, actcomprises writing a portion of data from the second file into a second data block of the second region file. For example, data region file management componentwrites data blockand data region filewith different portions of data of the second file.

As shown, in some embodiments, actcomprises actof updating the CIM metadata to define the second file as using the first data block and the second data block. In some embodiments, actcomprises writing a second file definition to the metadata portion of the CIM, the second file definition defining the second data of the second file as including 1) the first data block within the first region file and 2) the second data block of the second region file. For example, the metadata management componentwrites file definition′, which defines a file that refers to data blockwithin data region file′, as well as data blockwithin data region file

As mentioned in connection with, in some embodiments, CIMand CIMcoexist (e.g., CIM management componentpersists CIMto CIMin storage mediumwhile retaining CIM). Thus, in some embodiments of method, adding the second region file to the CIM comprises adding the second region file to a copy of the CIM, and writing the second file definition to the metadata portion of the CIM comprises writing the second file definition to a metadata portion of the copy of the CIM. In other embodiments, CIMreplaces CIM(e.g., CIM management componentpersists CIMto CIMin storage mediumwhile removing or overwriting CIM). Thus, in some embodiments of method, the second file definition replaces the first file definition within the metadata portion of the CIM.

In example, data blockwithin data region file′ was identical to data blockwithin data region file(e.g., because the data within that portion of the file did not change). However, in other examples, data blockwithin data region file′ could be different from data blockwithin data region file(e.g., because the data within that portion of the file has changed). In these latter examples, extending the CIM to include the second file can include writing a portion of data from the second file into the first data block of the first region file.

In example, data blockwithin data region file′ was freed and was then used to store data(e.g., data block′). Thus, in some embodiments of method, the first file definition also defines the first data of the first file as including a third data block (e.g., data block) of the first region file of the CIM. In these embodiments, extending the CIM to include the second file includes marking the third data block as free (e.g., so that data blockcan be overwritten, resulting in data block′).

As mentioned, in some embodiments, data region file management componentmay support the creation and use of variable file-sized data portions for data region files, in addition to the creation and use of fixed-sized blocks for data region files. This means that a given CIM could include a mix of one or more data region files using variable file-sized data portions and one or more data region files using fixed-sized blocks. Thus, in some embodiments of method, the CIM also comprises a third region file comprising variable-sized data portions, each data portion storing data of an entire file.

Some embodiments employ the block deduplication componentto reduce the size of a CIM when the CIM would contain identical data blocks. For example, some embodiments of methodgenerate a digest for each data block and use these digests to avoid including duplicate data blocks within a CIM. In one example, and referring to example, methodincludes generating a first digest from a data block (e.g., data block). Then, when extending the CIM to include a third file (e.g., a file corresponding to file definition), methodincludes generating a second digest from a portion of data of the third file (e.g., the portion of the file that was data blockin example), and writing a third file definition (file definition) to the metadata portion of the CIM. Here, the third file definition defines third data (data) of the third file as including the second data block of the second region file based on the first digest equaling the second digest.

As mentioned, block deduplication componentmay keep a reference count for each data block and use that reference count to determine when a data block can be freed (e.g., when the reference count reaches zero). Thus, in embodiments, methodfurther comprises incrementing a reference count associated with the second data block based on writing the second file definition (e.g., file definition′) and incrementing the reference count associated with the second data block based on writing the third file definition (e.g., file definition). Additionally, in embodiments, methodfurther comprises decrementing the reference count associated with the second data block based on a removal of the second file from the CIM, decrementing the reference count associated with the second data block based on a removal of the third file from the CIM, and marking the second data block as free based on the reference count reaching zero.

Embodiments of the disclosure comprise or utilize a special-purpose or general-purpose computer system (e.g., computer system) that includes computer hardware, such as, for example, a processor system (e.g., processor system) and system memory (e.g., memory), as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media accessible by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and/or data structures are computer storage media (e.g., storage medium). Computer-readable media that carry computer-executable instructions and/or data structures are transmission media. Thus, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media are physical storage media that store computer-executable instructions and/or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid state drives (SSDs), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

Transmission media include a network and/or data links that carry program code in the form of computer-executable instructions or data structures that are accessible by a general-purpose or special-purpose computer system. A “network” is defined as a data link that enables the transport of electronic data between computer systems and other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination thereof) to a computer system, the computer system may view the connection as transmission media. The scope of computer-readable media includes combinations thereof.

Upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., network interface) and eventually transferred to computer system RAM and/or less volatile computer storage media at a computer system. Thus, computer storage media can be included in computer system components that also utilize transmission media.

Computer-executable instructions comprise, for example, instructions and data which when executed at a processor system, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a function or group of functions. In embodiments, computer-executable instructions comprise binaries, intermediate format instructions (e.g., assembly language), or source code. In embodiments, a processor system comprises one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more neural processing units (NPUs), and the like.

In some embodiments, the disclosed systems and methods are practiced in network computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAS, tablets, pagers, routers, switches, and the like. In some embodiments, the disclosed systems and methods are practiced in distributed system environments where different computer systems, which are linked through a network (e.g., by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links), both perform tasks. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems. Program modules may be located in local and remote memory storage devices in a distributed system environment.

In some embodiments, the disclosed systems and methods are practiced in a cloud computing environment. In some embodiments, cloud computing environments are distributed, although this is not required. When distributed, cloud computing environments may be distributed internally within an organization and/or have components possessed across multiple organizations. In this description and the following claims, “cloud computing” is a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as Software as a Service (Saas), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), etc. The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, etc.

Some embodiments, such as a cloud computing environment, comprise a system with one or more hosts capable of running one or more virtual machines (VMs). During operation, VMs emulate an operational computing system, supporting an operating system (OS) and perhaps one or more other applications. In some embodiments, each host includes a hypervisor that emulates virtual resources for the VMs using physical resources that are abstracted from the view of the VMs. The hypervisor also provides proper isolation between the VMs. Thus, from the perspective of any given VM, the hypervisor provides the illusion that the VM is interfacing with a physical resource, even though the VM only interfaces with the appearance (e.g., a virtual resource) of a physical resource. Examples of physical resources include processing capacity, memory, disk space, network bandwidth, media drives, and so forth.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described supra or the order of the acts described supra. Rather, the described features and acts are disclosed as example forms of implementing the claims.