Microsoft Technology Licensing, LLC

Scott A Brender

Michael David Marr

Arun Upadhyaya Kishan

Karan Mehra

William R Tipton

Darren Glen Moss

Surendra Verma

Shi Cong

Ping Xie

Neal Robert Christiansen

Sarosh Cyrus Havewala

John Andrew Starks

Shaheed Gulamabbas Chagani

Octavian Tony Ureche

Philip J Lafornara

Craig Ashley Barkhouse

Robert Ian Oliver

Lei Shi

Ravisankar V Pudipeddi

Rajsekhar Das

David Rudolph Wooten

Malcolm James Smith

Elden Christensen

Timothy J Oerting

Methods, systems, and computer storage media for providing a set of common flat files in a composite image that can be mounted as a container (i.e. composite container) to support isolation and interoperation of computing resources. Container management is provided for a container management system based on a composite image file system engine that executes composite operations to support resource isolation and operating system (OS) virtualization functionality. In particular, a layout manager operates with a composite engine interface to support generating composite images with optimized configurations (i.e., pre-alignment and pre-computed hashes of for executable files). In operation, a plurality of files for generating a composite image are accessed. The composite image for the plurality of files is generated while pre-processing executable files, where pre-processing the one or more files comprises pre-aligning the executable files in the composite image or pre-computing a hash for the executable files in the composite image.

Container management system with a layout manager system

Methods, systems, and computer storage media for providing a set of common flat files in a composite image that can be mounted as a container (i.e., composite container) to support isolation and interoperation of computing resources. Container management is provided for a container management system based on a composite image file system engine that executes composite operations to support resource isolation and operating system (OS) virtualization functionality. In particular, a container engine interface supports creating, mounting, and providing access to and from composite images or composite containers. In operation, a plurality of files for generating a composite image are accessed. The composite image for the plurality of files is generated. The composite image includes a set of common flat files. The composite image is communicated to cause mounting of the composite image, where mounting the composite image is based on a metadata file from the set of common flat files.

Container management system with a composite engine interface

Methods, systems, and computer storage media for providing a set of common flat files in a composite image that can be mounted as a container (i.e. composite container) to support isolation and interoperation of computing resources. Container management is provided for a container management system based on a composite image file system engine that executes composite operations. In particular, a remote sharing manager operates with a composite engine interface to support generating composite images configured for split layer memory sharing, split layer direct access memory sharing, and dynamic base images. In operation, a plurality of files and a selection of a remote sharing configuration for generating a composite image are accessed. The composite image for the plurality of files and the remoting sharing configuration is generated. The composite image is communicated to cause sharing of the composite image, sharing of the composite image is based on the remote sharing configuration.

Container management system with a remote sharing manager

Storage virtualization techniques allow directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the directories are stored locally&#x2014;even though the data of those directories may not be resident on the local computing device. That is, the contents of directories that may exist in the cloud look and behave as if they were stored locally on a computing device.

Storage virtualization for directories

A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Aggregation of write traffic to a data store

The techniques and systems described herein determine whether or not to implement reparse behavior in association with a file or a directory access. A file system and/or a file system filter can receive, from a host system component, a request to open a file or a directory. While attempting to access the file or the directory, a reparse tag associated with an intermediate directory is encountered. The file system can then determine whether a next node, along an access path for the file or the directory to be opened, exists in the intermediate directory. That is, the file system can look beyond the reparse tag and into the intermediate directory to determine if the next node exists. Subsequently, the file system and/or the file system filter can decide whether to implement reparse behavior based on the reparse tag and whether the next node exists in the intermediate directory.

Controlling reparse behavior associated with an intermediate directory

The techniques and systems described herein reduce the amount of storage resources consumed by containers by creating placeholder files in container namespaces. The placeholder files are associated with read-only access to corresponding shared files stored in a read-only namespace. The read-only namespace can be accessible to multiple different containers. This increases the storage density for a storage unit because more containers can be executed from the same storage unit. The techniques and systems described herein further reduce the amount of storage resources consumed by containers by creating placeholder directories. The techniques and systems described herein also reduce the amount of memory storage resources consumed by containers to execute files by using a shared execution memory area.

Reducing resource consumption associated with storage and operation of containers

Common block storage infrastructure techniques are described in which files are created through interaction with a file system to reserve extents in a volume on behalf of volume storage drivers, which may form a driver stack that resides logically on top of the volume. The files protect the reserved extents within the volume for use by the volume storage drivers, such as to store metadata related to operations performed by the drivers. When reserved extents are created, a location of the reserved extents is communicated through the driver stack to a corresponding volume storage driver. Volume storage drivers may also be configured to discover their corresponding reserved extents and communicate these to upper-level drivers and components. Accordingly, when a volume storage driver manipulates data in the volume, it may do so with awareness of the reserved extents of the other volume storage drivers.

Common block storage infrastructure

Full volume encryption can be applied to volumes in a clustering environment. To simplify the maintenance of keys relevant to such encrypted volumes, a cluster key table construct can be utilized, where each entry of the cluster key table corresponds to an encrypted volume and comprises an identification of the encrypted volume and a key needed to access that volume. Keys can be protected by encrypting them with a key specific to each computing device storing the cluster key table. Updates can be propagated among the computing devices in the cluster by first decrypting the keys and then reencrypting them with a key specific to each computing device as they are stored on those computing devices. Access control requirements can also be added to the entries in the cluster key table. Alternative access control requirements can be accommodated by assigning multiple independent entries to a single encrypted volume.

Full volume encryption in a clustered environment

Hardware encrypting storage devices can provide for hardware encryption of data being written to the storage media of such storage devices, and hardware decryption of data being read from that storage media. To utilize existing key management resources, which can be more flexible and accommodating, mechanisms for storing keys protected by the existing resources, but not the hardware encryption of the storage device, can be developed. Dedicated partitions that do not have corresponding encryption bands can be utilized to store keys in a non-hardware-encrypted manner. Likewise, partitions can be defined larger than their associated encryption bands, leaving room near the beginning and end for non-hardware encrypted storage. Or a separate bit can be used to individually specify which data should be hardware encrypted. Additionally automated processes can maintain synchronization between a partition table of the computing device and a band table of the hardware encrypting storage device.

External encryption and recovery management with hardware encrypted storage devices

Dynamic run-time verification of a module which is loaded in memory (in whole or in part) for execution is enabled by storing hashes of smaller portions of the module (e.g. page-level hashes) as they should look when loaded into memory for execution. After an initial authentication is completed, hashes of smaller portions of the module are stored. These hashes consist of the portion of memory as modified by changes which would be made by the operating system loader operating normally. Thus, the hashes can be used to verify that the portion as loaded into memory for execution is 1) a correct copy of the portion of the software module, 2) correctly modified for execution by the processor, and 3) not tampered with since loading. Additionally, during execution of the module, new portions/pages of the module which are loaded can be verified to ensure that they have not been changed, and a list of hot pages of the module can be made, including pages to be continually re-verified, in order to ensure that no changes have been made in the module.

Growing community of inventors

Kirkland, WA, United States of America

Scott A Brender