Hierarchical composite boot device and file system for operating system boot in file system virtualization environment

Abstract

A layered composite boot device and corresponding layered composite file system can be implemented by a boot manager. Requests directed to the layered composite boot device and file system can be serviced from a primary device and file system encapsulated by the layered composite boot device and file system. The primary device and file system can correspond to a virtualized file system in a container environment, enabling changes in the container environment to affect early stages of operating system boot in the container environment. If such requests cannot be serviced from the primary layer, the composite device and file system can include a secondary layer corresponding to a container host connection and host file system, providing a fallback to existing data if there are no changes in the container environment, enabling boot to proceed in a traditional manner.

Description

Background Technology

[0001] Traditional virtual computing environments (often called "virtual machines") virtualize most or all aspects of a computing environment, and therefore can present a computing environment very different from the host computing device hardware and operating system. Such virtual machine computing environments can virtualize the computing hardware itself. However, because they need to virtualize most or all aspects of the host computing environment, traditional virtual computing environments can consume large amounts of memory, require significant processing resources, and can be inefficient. In some cases, lightweight virtual computing environments, often called "containers," can provide many of the isolation advantages of traditional virtual computing environments in a more efficient way, such as by leveraging aspects of the host computing device hardware and operating system, rather than virtualizing those aspects of the computing environment. Such container virtual computing environments can virtualize only the file system, rather than the computing hardware, thus presenting a different, isolated view of file data. Therefore, containers can be used to provide isolated computing environments, such as limiting the impact of potentially malicious instructions, providing raw computing environments, such as for testing or troubleshooting purposes, and other similar benefits.

[0002] Unfortunately, because the file system virtualization provided by a container virtualization environment is provided by file system drivers, filter drivers, microdrivers, or other similar computer-executable instructions instantiated after the operating system kernel boots, processes executed within the container environment cannot alter the early stages of the operating system boot process within the container. This renders such a container environment unavailable for many functionalities, for which the isolation it provides is particularly useful. For example, a container environment cannot be used to develop, test, and evaluate anti-malware, as anti-malware typically requires the execution of computer-executable instructions during the early stages of the operating system boot process. While anti-malware executed within a container environment could make such changes, these changes would persist within the container file system until the operating system kernel has booted and subsequently instantiated the necessary file system drivers. Thus, for example, changes made by anti-malware would need to be available earlier than the time the existing container file system virtualization environment boots. The inability to persist changes affecting the early stages of the operating system boot process within a container file system virtualization environment negatively impacts its usability. Summary of the Invention

[0003] The layered composite boot device and its corresponding layered composite file system can be implemented by computer-executable instructions, which may be part of the boot manager, thereby providing access to the virtualized container file system at an early stage during the operating system boot process in a container file system virtualization environment. Requests to the layered composite boot device and the layered composite file system can be serviced from the primary device and primary file system encapsulated by the layered composite boot device and the layered composite file system, respectively. This primary device and primary file system may correspond to the virtualized file system within the container environment, allowing changes in the container environment to affect the early stages of operating system booting within that container environment. If such a request cannot be serviced from the primary layer, the composite device and composite file system may include secondary layers, such as secondary devices that may correspond to the container host connection to the host computing environment, and secondary file systems that may correspond to the host file system, providing a rollback of existing data if no changes are made within the container environment, allowing the operating system booting in the container environment to continue in a conventional manner.

[0004] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed embodiments below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0005] Additional features and advantages will become clear from the following detailed description with reference to the accompanying drawings. Attached Figure Description

[0006] The following detailed description can be better understood in conjunction with the accompanying drawings, in which:

[0007] Figure 1 This is a system diagram of an exemplary file system virtualization environment;

[0008] Figures 2a to 2f This is a system diagram of an exemplary operating system that boots in a file system virtualization environment that utilizes a layered composite boot device and file system;

[0009] Figure 3 This is a system diagram of an exemplary operating system that boots in a file system virtualization environment that utilizes a layered composite boot device and file system;

[0010] Figure 4 This is a flowchart of an exemplary operating system that boots in a file system virtualization environment that utilizes a layered composite boot device and file system;

[0011] Figure 5 This is a flowchart illustrating the operation of an exemplary composite boot device and file system; and

[0012] Figure 6 This is a block diagram of an exemplary computing device. Detailed Implementation

[0013] The following description relates to a layered composite boot device and a corresponding layered composite file system, which can be implemented by computer-executable instructions that can serve as part of a boot manager, thereby providing access to a virtualized container file system in an early stage of operating system booting within a container file system virtualization environment. Requests to the layered composite boot device and the layered composite file system can be serviced from the primary device and primary file system encapsulated by the layered composite boot device and the layered composite file system, respectively. This primary device and primary file system can correspond to a virtualized file system within the container environment, allowing changes within the container environment to affect the early stages of operating system booting within that container environment. If such a request cannot be serviced from the primary layer, the composite device and composite file system can include secondary layers, such as a secondary device that may correspond to a container host connection to the host computing environment, and a secondary file system that may correspond to the host file system, providing a rollback of existing data if changes within the container environment are not made, allowing operating system booting in the container environment to continue in a conventional manner.

[0014] Although not strictly necessary, the following description will be performed in the general context of computer-executable instructions (such as program modules) executed by a computing device. More specifically, unless otherwise stated, the description will refer to the actions and symbolic representations of operations performed by one or more computing devices or peripheral devices. Accordingly, it should be understood that such actions and operations, sometimes referred to as computer-performed, include operations that represent data in a structured form via processing units of electrical signals. This operation transforms the data or maintains it in a location in memory, which reconfigures or otherwise alters the operation of the computing device or peripheral device in a manner well known to those skilled in the art. The data structure that maintains the data is a physical location having specific attributes defined by the format of the data.

[0015] Typically, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will understand that computing devices are not limited to conventional personal computers and include other computing configurations, including servers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, etc. Similarly, computing devices are not limited to standalone computing devices, as this mechanism can also be implemented in a distributed computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote storage devices.

[0016] refer to Figure 1 The illustration depicts an exemplary system 100 to provide context for the following description. Exemplary system 100 includes an exemplary host computing environment 110, which, for the purpose of providing context for the following description, may host a file system virtualization environment in the form of an exemplary container 150. As used herein, the term "file system virtualization environment" refers to a virtualized computing environment that does not virtualize the underlying computing hardware or device, but rather virtualizes the file system, thereby isolating it from the host computing device so that file-level changes made within the file system virtualization environment do not affect the file system of the host computing device.

[0017] More specifically, such as Figure 1 As shown in the exemplary system 100, the exemplary host computing environment 110 may have a host operating system running thereon, such as in the form of an exemplary host operating system 120. As part of the host operating system 120, one or more file system drivers, filters, microfilters, and other similar file system components (typically in...) Figure 1 A host file system driver (130) can obtain data in a structured form from one or more storage media (such as exemplary storage media 111) and can parse such data into a file structure that can be presented to applications and other processes executing on the host operating system 120. For example, an application 151 executing on the host computing environment 110 can present multiple files, such as exemplary file 141, exemplary file 142, and exemplary file 143, as part of the host file system 131. Similarly, a container operating system (such as exemplary container operating system 160) can execute within exemplary container 150. However, to provide file system virtualization, exemplary container operating system 160 can present files different from those in the host file system 131.

[0018] According to one aspect, the file system of the exemplary container operating system 160 may be a hierarchical file system, which enables an application (such as exemplary application 152) executing within the container environment 150 to access some or all of the same files in the same file system of the host file system 131, such as exemplary file 141, exemplary file 142, and exemplary file 143, except that any changes or modifications to these files can only be retained within the container environment 150. For example, as Figure 1 As shown in the exemplary system 100, the exemplary container operating system 160 may include a hierarchical file system in the form of a container file system 171, which may be used as a primary layer or "overlay layer" in combination with a primary file system 181, which may be used as a secondary layer or "bottom layer".

[0019] The file system mentioned herein can be any known, existing file system, such as the NT File System (NTFS), Apple File System (APFS), UNIX File System (UFS), or other file systems. Similarly, the file system driver can be a corresponding driver, filter, microfilter, and other similar drivers capable of implementing such a file system. Thus, for example, if the host file system 131 is NTFS, then the host file system driver 130 can be the relevant NTFS driver. However, within the exemplary container environment 150, the host file system 181 can be implemented in a slightly different manner to provide access to the host file system from within the file system virtualization environment. More specifically, according to one aspect, access to the host computing environment 110 from within the container environment 150 can be via a container host connection (such as, exemplary container host connection 190). According to one aspect, exemplary container host connection 190 can be in the form of a virtualized network connection that can emulate a container environment 150 of computing devices separate from the host computing environment 110, and the two computing devices are communicatively coupled via a network. Other container host connections can be based on other communication protocols, such as peripheral interconnect protocols. According to one aspect, container host connection 190 can appear as a block data device from within container environment 150. Therefore, for example, host file system 181 from within container environment 150 can be implemented as a network file system, and accordingly, drivers 180, such as drivers, filters, microfilters, and other similar structures, can communicate with host computing environment 110 via container host connection 190 to implement this network file system. Host computing environment 110 can also include a file system of the same type as host file system 131. For example, if host file system 131 is NTFS, then container file system 171 can also be NTFS. In this case, container file system driver 170 can include drivers, filters, microfilters, and other similar structures similar to host file system driver 130. In fact, the same codebase, even the same compiled binaries, can be used to implement both container file system driver 170 and host file system driver 130.

[0020] According to one aspect, changes to files within the file system virtualization environment presented by container 150 can be isolated from other file system virtualization environments and the host computing environment 110 itself. For example, if an exemplary application 152 executing within container environment 150 edits exemplary file 141, as shown by edit action 155, this modification can cause the edited version of file 144 representing file 141 to become part of container file system 171. The original file 141 will remain unchanged. However, the hierarchical file system from within container environment 150 will present the edited file 144 instead of the original file 141 from the host file system. In simpler terms, the edited file 144 will "block" or "mask" the presentation of the original file 141. If exemplary application 152 does not edit files 142 or 143, these files will still "pass through" the overlay file system and be presented to the application or process executing within container 150, such as exemplary application 152.

[0021] The digital data representing the edited file 144 can be stored in a sandbox, such as the exemplary sandbox 149. The container file system driver 170 can access the sandbox 149, as previously described, to generate the container file system 171. As used herein, the term "sandbox" refers to one or more files, databases, structured storage, or other similar digital data warehouses capable of storing the relevant data required to implement the container file system 171. For example, sandbox 149 could be a file or package within the host file system 131. In this way, the host computing environment 110 can remain isolated from the edits performed within the container environment 150. Therefore, for example, if the edit 155 is a malicious action, the file 141 in the host computing environment 110 will remain isolated from and unaffected by such an action within the container environment 150.

[0022] As described above, in some cases, it may be desirable to allow processes executing within container environment 150 to modify aspects of container operating system 160, including aspects that can be established during the early stages of the boot process of container operating system 160. However, the layered file system presented by container operating system 160 can be established at a later point in the boot process of container operating system 160. For example, container file system driver 170 and virtual file system driver 180 may not establish layered file systems 171 and 181 until after the kernel of container operating system 160 has been executed. In fact, in some cases, the kernel of operating system 160 can be responsible for executing the relevant drivers 170 and 180. Therefore, if, for example, an application or process executing within container 150 changes aspects of container operating system 160, such changes can be stored in container file system 171, as in the manner previously detailed. However, since the container file system 171 may not be accessible until the kernel of the operating system 160 has executed the relevant driver 170, the operating system 160 will not be able to access this change early in its boot process, as this change will not be accessible until the operating system kernel has been loaded into memory. Therefore, due to the inability to access the container file system 171, the early portion of the boot process of the container operating system 160 can only utilize data from the host computing device, which, as previously mentioned, is unaffected by and isolated from changes made within the container environment 150.

[0023] To enable processes executed within container environment 150 to modify aspects of container operating system 160, including aspects that can be established during the early stages of the boot process of container operating system 160, layered composite boot devices and file systems can be used during the boot of container operating system 160. [Go to...] Figure 2aThe exemplary system 201 shown illustrates an exemplary initiation of booting an operating system within a container file system virtualization environment (such as exemplary container 150). More specifically, the exemplary host computing environment 110 may include a hypervisor, such as exemplary hypervisor 211, or other similar hardware and / or software capabilities. Exemplary hypervisor 211 may utilize data from a container operating system image (such as exemplary container operating system image 212) or other similar container data stored on storage medium 111 of the exemplary host computing environment 110 to boot the operating system within exemplary container 150. For example, as shown in exemplary system 201, hypervisor 211 may cause container firmware 220 to be executed within container environment 150 in the form of executing container firmware 221, as shown in action 219. Information and executable instructions stored in the container operating system image (such as exemplary container operating system image 212) may be static, such that they are unaffected by changes to host computing environment 110, or they may be dynamic, since changes to host computing environment 110 may result in partial or complete changes to container operating system image 212. For example, when executable instructions are used to boot the operating system of the container computing environment 110 itself, the dynamic container operating system image 212 can utilize the same executable instructions for some or all of the relevant parts of the container operating system image 212. In this case, changes to the executable instructions for booting the operating system of the host computing device 110 will necessarily result in changes to the container operating system image 212.

[0024] As previously described, virtualized network connectivity (such as, for example, container host connectivity 190) can be used for processes executed within container 150 to access information from host computing environment 110. Therefore, one aspect of executing container firmware 221 within container 150 can be executing drivers for relevant devices that container 150 may need to access during the boot process, such as graphics drivers, user input device drivers such as keyboard and mouse drivers, and network drivers, relevant to the description provided herein, that enable the execution of firmware 221 to access information from host computing environment 110.

[0025] Go to Figure 2b The exemplary system 202 shown illustrates the execution of container firmware 221, which utilizes a container host connection 190 to access a container boot manager 230 stored on storage medium 111 of the host computing environment 110. As illustrated, the exemplary container boot manager 230 may be part of the exemplary container operating system image 212. Figure 2aIn the portion of action 219 shown, the hypervisor 211 can identify the location of the exemplary container boot manager 230 to the firmware 221. Once accessed, the container boot manager 230 can be executed by the container firmware 221 within the container. Action 229 in the exemplary system 202 illustrates the location and execution of the container boot manager 230 by the firmware 221.

[0026] Similar to firmware 221, the execution of container boot manager 231 may include the execution of drivers or other similar computer-executable instructions, which enable container boot manager 231 to access relevant parts of the host operating system environment 110, including, for example, graphics drivers, input peripheral drivers, network drivers, etc. These drivers may be the same drivers used by container firmware 221, and thus these drivers may be retained in memory for use by container boot manager 231, or the drivers may be different drivers, which may require container boot manager 231 to clear the memory previously used by container firmware 221 and load its own drivers into the memory of container environment 150.

[0027] As part of action 229, firmware 221 can identify to container boot manager 231 the boot device used to boot the operating system into container environment 150. Figure 2b In the system 202 shown, this boot device can be the container host connection 190. Subsequently, the container boot manager 230 can access this boot device to locate and obtain container boot configuration data. [Go to...] Figure 2c The exemplary system 203 illustrates action 238, through which the container boot manager 231, executing within the container environment 150, uses the previously specified container host connection 190 to the container boot manager 231 as a boot device to locate and read container boot configuration data 240. As shown, the container boot configuration data 240 can also be a portion of the exemplary container operating system image 212.

[0028] According to one aspect, to facilitate the utilization of modifications occurring within container environment 150 in subsequent boots of the operating system within container environment 150, container boot configuration data 240 may specify a new boot device. More specifically, such as Figure 2cAs illustrated in specification 249 of system 203, container boot configuration data 240 can specify a composite device (such as, exemplary composite device 250) as a new boot device. Exemplary composite device 250 can implement a layering system similar to that described above, having a primary layer and secondary layers. Although described in the context of two layers (i.e., primary and secondary layers), a composite device (such as, exemplary composite device 250) can include any number of layers, including a third layer below a secondary layer, and so on.

[0029] As will be further detailed below, a composite device (such as, in this example, composite device 250) can access multiple devices in a hierarchical order. Thus, for example, a primary device may be accessed first, and if the sought information is not available from the primary device, a secondary device may be accessed, and the sought information may be obtained and provided from the secondary device. Conversely, if the sought information is available from the primary device, access to the secondary device may not be necessary. To enable the process executing within container environment 150 to make changes that could affect subsequent boots of the operating system within container environment 150, the exemplary composite device 250 may be a combination of a primary device 251 (which in this example may be sandbox 149) and a secondary device 252 (which in this example may be container host connection 190).

[0030] Composite devices (e.g., exemplary composite device 250) may be able to use composite file systems, such as exemplary composite file system 260. As described above, a composite file system can layer a primary file system on top of a secondary file system, such that if a file is found in the primary file system, the file can be used even if the same file exists in the secondary file system; however, if the file is not found in the primary file system, the secondary file system can be checked, and if found, the file can be retrieved from the secondary file system. Like composite device 250, composite file system 260 may include multiple layers in addition to the primary and secondary file systems. For example, composite file system 260 may include a third file system, etc. Similarly, to enable the ability of a process executed within container environment 150 to make changes that may affect subsequent boots of the operating system within container environment 150, exemplary composite file system 260 may include a primary file system 261 (which may be container file system 171 in this example) and a secondary file system 262 (which may be host file system 181 in this example).

[0031] According to one aspect, a container boot manager (such as container boot manager 230 from container operating system image 212 in host computing environment 110) is instantiated into container environment 150 as execution container boot manager 231 and executed in container environment 150. The container boot manager may include computer-executable instructions that can operate with a composite device (such as exemplary composite device 250) and implement a composite file system (such as exemplary composite file system 260).

[0032] For example, the container boot manager 231 can execute drivers, filters, microfilters, or other similar computer-executable instructions that can access the sandbox 149. Such computer-executable instructions... Figure 2c In the illustrated exemplary system 203, an exemplary driver 277 is shown. According to one aspect, the exemplary driver 277 may be similar to or even equivalent to a driver ultimately used by a container operating system to implement the container file system 171, such as... Figure 1 The exemplary driver 170 shown and described above. According to another aspect, the exemplary driver 277 may differ from the exemplary driver 170, as they may implement more basic and simpler functions, including device and file system functions used by the container boot manager 231, but lacking support for more complex functions. Similarly, the exemplary driver 277 need not be driver code in the traditional sense, but may be computer-executable instructions capable of implementing the mechanisms described herein, regardless of the form in which such computer-executable instructions are encapsulated for the purpose of convenience and / or interoperability with other aspects of the container environment 150 and / or the host computing environment 110.

[0033] Similarly, the container boot manager 231 can execute drivers, filters, microfilters, or other similar computer-executable instructions that can access data in the host file system via the container host connection 190. These computer-executable instructions... Figure 2c In the exemplary system 203 shown, an exemplary driver 278 is illustrated. According to one aspect, the exemplary driver 278 may be similar to or even equivalent to a driver ultimately used by a container operating system to implement a host file system 181 in container 150, such as… Figure 1The exemplary driver 180 shown and described above. According to another aspect, the exemplary driver 278 may differ from the exemplary driver 180, as it may implement more basic and simpler functions, including device and file system functions used by the container boot manager 231, but lacking support for more complex functions. As previously stated, the exemplary driver 278 need not be driver code in the traditional sense, but may be computer-executable instructions capable of implementing the mechanisms described herein, regardless of the form in which such computer-executable instructions are encapsulated for the purpose of convenience and / or interoperability with other aspects of the container environment 150 and / or the host computing environment 110.

[0034] According to one aspect, the container boot manager 231 may also include computer-executable instructions such as the exemplary driver 270, which can provide device and / or file system aggregations described in further detail below. For example, Figure 2c The computer-executable instructions illustrated as an example driver 270 may include device drivers or other similar computer-executable instructions that can receive device-centric requests, such as requests to install a device, requests to open a device, requests to enumerate devices, and other similar device-centric requests, and can direct these requests to computer-executable instructions that implement interfaces with a device that is part of composite device 250 (such as primary device 251 and secondary device 252). Thus, for example, driver 270 can receive a request to install composite device 250, and in response, can direct the device installation request to both driver 277 (to install sandbox 149 as a device accessible from within container environment 150) and driver 278 (to install container host connection 190 as a device accessible from within container environment 150). Driver 270 can then respond to the device installation request as if installing a single device; the installation of the individual primary and secondary devices is abstracted in this manner. Similarly, Figure 2cThe computer-executable instructions illustrated as an exemplary driver 270 may include one or more file system drivers, filter drivers, microfilters, or other similar computer-executable instructions. These instructions may receive file system-centric requests, such as requests to open a file, requests to read from a file, requests to write to a file, requests to enumerate files within a folder, and other similar file system-centric requests. Such requests may be directed to computer-executable instructions that implement an interface with the file system, which is a portion of a composite file system 260 (e.g., a primary file system 261 and a secondary file system 262). Thus, for example, driver 270 may receive a request to open a file in composite device 260, and in response, if the file is part of container file system 271, driver 270 may first direct the file open request to driver 277; or if the file is not part of container file system 271 but part of host file system 181, the file open request may first be directed to driver 278. Driver 270 may then interact with the underlying primary and secondary file systems, abstracted as described above, in response to the file open request, as if a single file system were accessed.

[0035] Utilizing composite device 250 as a new boot device, as specified in container boot configuration data 240 and as shown in specification 249, container boot manager 231 can locate container operating system loader computer-executable instructions, such as exemplary container operating system loader 280, which may be a part of exemplary container operating system image 212, and this container operating system loader 280 can be executed within container environment 150. Go to Figure 2d The exemplary system 204 shown illustrates action 239, through which the container boot manager 231 executes the container operating system loader 280 as the container operating system loader 281 in the container environment 150.

[0036] According to one aspect, the container boot manager 231 can utilize the composite device 250 and the composite file system 260 to locate the container operating system loader 280. According to a specific aspect shown by the exemplary system 204, the container operating system loader 280 can remain unchanged by the process executed within the container 150, and therefore can be a part of the host file system 181, rather than a part of the container file system 171, as described in the reference above. Figure 1The mechanism described above. Therefore, the request for the container boot manager 231 to open and execute the container operating system loader 280 can be passed through the driver 278, and the container operating system loader 280 can be obtained from the container operating system image 212 in the host computing environment 110 through the container host connection 190.

[0037] Go to Figure 2e The exemplary system 205 shown illustrates exemplary operation of a container operating system loader 281 executing within a container environment 150. According to one aspect, the container operating system loader 281 can open a composite device 250 and access a composite file system 260 to locate configuration data for a container operating system, which the container operating system loader 281 then boots into the container environment 150, such as the exemplary container operating system 298. Figure 2e The exemplary system 205 illustrated here depicts exemplary operations if the container operating system configuration is not changed by a process executed within container 150. More specifically, for example, as referenced above... Figure 1 In this manner, if the container operating system configuration has not been changed by a process executed within container 150, then when container operating system loader 281 attempts to access container operating system configuration data, such modified data cannot be found in the primary file system 261, such as container file system 171 containing files that have been changed by a process executed within container environment 150. Therefore, container operating system loader 281 can alternatively find the container operating system configuration data through secondary file system 262 (e.g., host file system 181). Thus, as shown in exemplary system 205, action 288 of container operating system loader 281 obtains container operating system configuration data 290 from operating system container image 212 in host computing environment 110 and uses this container operating system configuration data 290 to configure the boot of container operating system 298. Because the container operating system configuration data 290 is obtained from the host file system 181, the composite device 250 may have been provided with relevant access via the secondary device 252, the composite file system 260 may have been provided with relevant access via the secondary file system 262, and the driver 278 responsible for the secondary device 252 and the secondary file system 262 may have been used by the container operating system loader 281 to obtain the container operating system configuration data 290 from the host file system 181, and to boot the container operating system 298 in the container environment 150 using the same container operating system configuration data 290, as highlighted in black.

[0038] Conversely, if one or more processes executed within container environment 150 have previously modified portions of the operating system configuration data, a copy of the container operating system configuration data 290 may be a portion of the container file system 171, for example, it may be stored in sandbox 149 or otherwise preserved in sandbox 149. As previously described, existing mechanisms do not provide access to the container file system 171 until after the container operating system 298 has completed booting, because the relevant computer-executable instructions (such as relevant drivers) can be loaded by the boot of the container operating system 298 and are unavailable before this boot, making the container file system 171 inaccessible until after the container operating system 298 has completed booting. However, using the mechanisms described herein, access to the container file system 171 can be provided at an earlier stage of the boot process, such as to access a modified copy of the container operating system configuration data 290 that reflects modifications made by processes executed within container environment 150, more specifically, before the container operating system loader 281 uses this configuration data to boot and configure the container operating system 298.

[0039] More specifically, and refer to Figure 2f The exemplary system 206 shown illustrates exemplary operation through which container operating system configuration data 291, reflecting changes previously made by processes executed within container environment 150, can be used to control the configuration and booting of container operating system 299. Container operating system 299 is labeled with... Figure 2eThe container operating system 298 of the illustrated system 205 has different identifiers to indicate that the executing operating system can have different configurations. Container operating system configuration data 291, which has been modified by processes executed within the container environment 150, can be stored and persisted within the container file system 171, such as in the sandbox 149. Therefore, the container operating system loader 281 can locate the container operating system configuration data 291 via the primary file system 261 (e.g., container file system 171). Thus, as shown in the exemplary system 206, action 289 of the container operating system loader 281 can obtain the container operating system configuration data 291 from the sandbox 149 and can utilize this container operating system configuration data 291 to configure the booting of the container operating system 298. Because the container operating system configuration data 291 is obtained from the container file system 171, the composite device 250 may have already been provided with relevant access via the primary device 251, the composite file system 260 may have already been provided with relevant access via the primary file system 261, and the driver 277 responsible for the secondary device 252 and the secondary file system 262 may have been used by the container operating system loader 281 to obtain the container operating system configuration data 291 from the sandbox 149, and to boot the container operating system 299 in the container environment 150 using the container operating system configuration data 291, such as... Figure 2f The black highlighting in the image is shown.

[0040] In this way, changes made by processes executing within container 150 are accessible early enough during the boot process to alter the configuration of the container operating system booted within container environment 150. For example, refer back to [reference]. Figure 1 In the exemplary system 100, if the application 152 executing within the container environment 150 is, for example, an anti-malware program, this application 152 may need to execute computer-executable instructions during the early stages of operating system boot to detect potential malware threats occurring during operating system boot. Therefore, application 152 may modify file 141 as shown in action 155, where in this example, file 141 may be an operating system configuration file, and modification 155 may be inserting a path to the computer-executable instructions that will be executed during the early stages of operating system boot, and, for example, inserting instructions to execute these computer-executable instructions. Modifications to file 141 can result in the persistence of a copy of file 144 and such modifications existing within the container file system 171, for example, within the sandbox 149, while file 141 on the host file system 131 remains unchanged. Return to Reference Figure 2fThe exemplary system 206 shown, the exemplary container operating system configuration data 290 can remain unchanged within the host computing environment 110, and the modifications described in the above example can instead be reflected in the container operating system configuration data 291, which can be a part of the container file system 171 and can be persisted in the sandbox 149.

[0041] During execution, the container boot manager has notified composite device 250 to be used as the boot device. As previously detailed, container operating system loader 281 can access composite device 250 and search for container operating system configuration data within it. As will be further detailed below, the primary device 251 (e.g., sandbox 149 in this example) and the corresponding primary file system 261 (e.g., container file system 171 in this example) can be referenced first to determine if container operating system configuration data exists therein. This reference can identify container operating system configuration data 291, including modifications made by the application within container process 150, such as those detailed above in this example. Therefore, container operating system loader 281 can use the modified container operating system configuration data 291 to boot container operating system 299, as shown in action 289.

[0042] From one perspective, minor modifications can accommodate not only changes to the container operating system configuration data, but also changes to the container boot configuration data itself. More specifically, let's return to... Figure 2cThe exemplary system 203 shown, as previously described, may include an indicator 249 of a composite device 250 to be used as a new boot device, since the container boot manager process 231 may have initially been executed using the container host connection 190 as the boot device, as detailed above. According to the aspects currently described, the container boot manager 231 may detect when the boot device specified by the container boot configuration data 240 differs from the boot device utilized by the container boot manager 231, in order to first read the container boot configuration data 240. For example, the container boot manager 231 may first compare the identifier of the boot device specified by the container boot configuration data 240 with the identifier of the boot device used by the container boot manager 231 to read the container boot configuration data 240. These identifiers may be based on device type and / or the entire device descriptor. In the case of a composite device (such as, for example, the composite device 250), these composite device identifiers may be based on device type and the descriptor of the device abstracted by the composite device. According to one aspect, the device descriptor may instead include metadata of the corresponding device, such as interface identifiers, channel identifiers, disk identifiers, partition identifiers, etc. When such differences between devices are detected, the container boot manager 231 can use the newly specified device (such as composite device 250 in this example) to locate and read the container boot configuration data again.

[0043] More specifically, and turning to Figure 3 The exemplary system 300 shown, upon detecting that container boot configuration data 240 specifies a different boot device, namely composite device 250, allows container boot manager 231 to utilize composite device 250 to reopen the container boot configuration data. If the container boot configuration data has been modified, a new copy of the container boot configuration data reflecting this modification (such as an exemplary copy of container boot configuration data 340) can be a portion of container file system 171, such as that persisted in sandbox 149, according to the previously detailed mechanism. An enumeration of container boot configuration data 340 from primary file system 261 can be provided to container boot manager 231, instead of container boot configuration data 240 from secondary file system 262. Therefore, container boot manager 231 can read container boot configuration data 340 from container file system 171, as shown in action 338. Figure 3In the exemplary system 300 shown, container boot configuration data 340 may also specify composite device 250 as the boot device, as shown in specification 349. Therefore, since the boot device specified by container boot configuration data 340 (i.e., composite device 250) is the same as the boot device used by container boot manager 231 to read container boot configuration data, container boot manager 231 can continue, for example, in the manner described above, except that the configuration used by container boot manager 231 can be modified according to changes made within container environment 150, as reflected in container boot configuration data 340. Conversely, container boot configuration data 240 can remain unchanged on host computing environment 110, thereby maintaining isolation between host computing environment 110 and container environment 150.

[0044] Go to Figure 4 The exemplary flowchart 400 illustrated herein depicts a series of exemplary steps that can modify a process executing within a container file system virtualization environment, modifications that can be implemented during the early stages of operating system booting within such a container file system virtualization environment. Initially, at step 410, a container instance can be created on the host computing device. This creation of the container instance may include memory reservation, establishment of underlying hardware and communication functions, etc. Subsequently, at step 415, a hypervisor (e.g., based on instructions and / or parameters provided by the container manager process) can instantiate firmware for execution within the container instance. Figure 4 As shown, step 415 can correspond to Figure 2a The exemplary system 201 shown and described in detail above.

[0045] At step 420, the firmware executing within the container instance created in step 410 can initialize and open a container host connection, which can be identified by the hypervisor as part of the firmware instantiation in step 415, serving as a boot device to be utilized by the firmware. At step 425, the firmware can utilize the boot device (i.e., the container host connection), such as locating the container boot manager from the host computing environment, and instantiate the container boot manager into the container instance created in step 410. The instantiation of the container boot manager by the firmware at step 425 can include passing parameters from the firmware to the container boot manager. For example, parameters can be provided from the firmware to the container boot manager as pointers to values, command-line arguments provided as part of the execution instructions implemented by the container boot manager, or other similar forms of passing parameters to the instantiated process. These parameters can include the specification of the boot device, which in this example can still be the container host connection. Figure 4 As shown, step 425 can correspond to Figure 2bThe exemplary system 202 shown and described in detail above.

[0046] At step 430, the container boot manager can use the identified boot device, passed as a parameter by the firmware at step 425, to locate, open, and read container boot configuration data. In this example, at step 430, this container boot configuration data is read via the container host connection. At step 435, as part of reading the container boot configuration data, the container boot configuration data may include the specification of the new boot device, i.e., the aforementioned composite device. Figure 4 As shown, steps 430 and 435 can correspond to Figure 2c The exemplary system 203 shown and described in detail above. Optionally, at step 440, the container boot manager may detect that the boot device specified by the container boot configuration data read at step 435 is different from the boot device first used by the container boot manager at step 430 to read the container boot configuration data. Step 440 in Figure 4 The dashed lines indicate that this is an optional step. Additionally, optionally, at step 445, if the boot device specified by the container boot configuration data is determined in step 440 to be different from the boot device initially used to read the container boot configuration data, the container boot manager can utilize the newly specified boot device, and at step 445, the container boot configuration data is read again from this newly specified boot device. As described above, this step 445 allows container boot configuration data that has been modified by processes executed within the container to be used during the boot process. Similar to step 440, step 445 also... Figure 4 The dashed line indicates that it is optional. For example... Figure 4 As shown, steps 440 and 445 can correspond to Figure 3 The exemplary system 300 shown and described in detail above.

[0047] Following either step 445 (if executed) or step 435 (if the aspects represented by steps 440 and 445 are not utilized), processing can proceed to step 450, whereby the container boot manager can utilize the new boot device (i.e., the composite device in this example) specified at step 435 to locate and instantiate the container operating system loader into the container instance created in step 410. At step 450, if the operating system loader within the container environment has not been modified, the container operating system loader can be obtained from the host computing device. More specifically, the utilization of the new boot device as the composite device can first examine the primary device and primary filesystem for the container operating system loader. As described above, such a primary device and primary filesystem can be associated with the container environment to locate any modified copies of the container operating system loader. If the container operating system loader has not been modified, secondary devices and secondary filesystems, such as those associated with the host computing device, can be utilized, and at step 450, the container operating system loader can be instantiated from there. Figure 4 As shown, step 450 can correspond to Figure 2d The exemplary system 204 shown and described in detail above.

[0048] Once instantiated into and executed within a container instance, the operating system loader can proceed to locate and read operating system configuration data from a boot device, which in this example can be a composite device specified by the container boot configuration data at step 435. Therefore, at step 455, if the operating system configuration data has been modified, access to the modified operating system configuration data can be provided using the primary device and primary file system associated with the container environment, and the operating system loader can use this modified operating system configuration data to boot the operating system. In this way, the process executed within the container environment can modify the boot of the operating system of that container environment. Conversely, if the operating system configuration data has not been modified, access to the unmodified operating system configuration data can be provided using the secondary device and secondary file system associated with the host computing environment, and at step 555, the operating system loader can use this unmodified operating system configuration data to boot the operating system. Then, at step 460, booting the operating system into the container environment can be completed.

[0049] Go to Figure 5The exemplary flowchart 500 shown illustrates a series of exemplary steps that can implement a composite device and a composite file system to provide the aforementioned layering. Initially, at step 510, an access request may be received. This access request can be a file-based access request, a folder-based or directory-based access request, or a device-based access request. Although only the selection of access requests is illustrated and described, other corresponding access requests can continue in multiple layers of the composite device and composite file system in a similar manner to those illustrated and described. For example, a device-based access request that may point to the composite device includes conventional device-based requests such as requests to open the device, initialize the device, read from the device, write to the device, install the device, uninstall the device, etc. Similar file-based or directory-based requests may point to files and / or directories in the composite file system.

[0050] Returning to the exemplary flowchart 500, if the access request is a file open request, then at step 515, the requested file can be read from the highest level where the file exists. Therefore, for example, if the file exists in the primary file system, the file can be provided in response to the request received at step 510. Conversely, if the file does not exist in the primary file system, files in the secondary file system can be checked, and if the file is located in the secondary file system, the file can be provided from the secondary file system in response to the request. According to one aspect, metadata (such as in the form of flags or other similar indicators) can be generated to identify the file system where the file resides, such that subsequent requests for the same file can be directed to the identified file system, while other file systems are skipped. This metadata can be cached in one or more tables, such as a file table implemented by a composite file system, or other similar databases or data structures. The related processing can then end at step 560.

[0051] If the access request is a file write request, and the file is not in the primary file system, copy-on-write can be performed to copy the file from the secondary file system to the primary file system. The changes being written to the file are then persisted in the primary file system, maintaining isolation between the container environment (with access to the primary file system) and the host computing environment (with access to the secondary file system), where unchanged files can be preserved. The subsequent processing can then end at step 560.

[0052] If the access request is a file deletion request received from a procedure executed within the container environment, then at step 525, a deletion marker can be placed in the primary file system. According to one aspect, when a file deletion marker is encountered at any level, the composite file system returns an indication that the file is no longer available. The relevant processing can then terminate at step 560.

[0053] If the access request is device-based, such as a request to mount a volume, processing can proceed to step 530, and the composite device can send such a request to the file system at each layer. In this way, the relevant volume can be mounted at each layer, allowing subsequent directory enumeration requests or file access requests to include the underlying base layer provided by the host computing environment and not modifiable from the container environment, as well as the primary or overlay layer accessible from within the container environment and persistently modifiable within the container environment. According to one aspect, if it is determined at step 535 that one or more layers do not have the requested volume, metadata can be generated, such as in the form of flags or other similar indicators, to identify layers accessible to the volume, or conversely, layers inaccessible to the volume. Subsequent execution of step 530 can then, based on existing, previously generated flags, send requests only to layers accessible to the volume. The relevant processing can then terminate at step 560.

[0054] If the access request is a directory-based access request, such as a request to enumerate files in a folder or otherwise open a folder, processing can proceed to step 540, where the request can be sent to the file system at each level. As previously described, if it is determined at step 545 that one or more levels do not have the requested folder, metadata can be generated, such as in the form of flags or other similar indicators, to identify the levels that do not have such folders, or conversely, to identify the levels that do have such folders. Subsequent iterations of step 540 can then direct requests to open folders only to those levels that have the folders, based on existing flags (such as those previously executed in step 545). Once the files in the folders have been enumerated at each level, or more specifically, at each level that has such folders, the presented list of files can be arranged according to the priority of the levels. More specifically, as described above, if a file exists at a higher level, the same file from a lower level is not shown. Therefore, for example, if there are modified copies of files that were modified from the container environment and are thus stored in the primary file system (i.e., the container file system), then the unmodified files from the host environment can be part of the secondary file system (which may not be shown), and the enumeration of files in a folder can include only the modified copies of files from the primary file system. This aggregation can be performed at step 555. Additionally, such as at step 550, any file corresponding to a deletion marker at a higher level can be indicated as no longer available and therefore not presented as part of the enumeration of files in a folder. Deletion markers can also be used for folders, where a folder corresponding to a deletion marker at a higher level would cause the aggregation at step 555 to not present any files presented in that folder at a lower level. When steps 550 and 555 are completed, the related processing can end at step 560.

[0055] Go to Figure 6The illustration depicts an exemplary computing device 600 capable of performing some or all of the mechanisms and actions described above. The exemplary computing device 600 may include, but is not limited to, one or more central processing units (CPUs) 620, system memory 630, and a system bus 621 coupling various system components, including system memory, to the processing unit 620. The system bus 621 may be any of various types of bus architectures, including memory buses or memory controllers, peripheral device buses, and local buses using any of various bus architectures. The computing device 600 may optionally include graphics hardware, including but not limited to a graphics hardware interface 660 and a display device 661, which may include a display device capable of receiving touch-based user input, such as a touch-sensitive display device or a multi-touch display device. Depending on the specific physical implementation, one or more of the CPU 620, system memory 630, and other components of the computing device 600 may be physically located in the same location, such as on a single chip. In this case, some or all of the buses in the system bus 621 may simply be silicon paths within a single chip structure, and their... Figure 6 The illustrations in the text are for the convenience of the symbols used.

[0056] Computing device 600 typically also includes computer-readable media, which can include any available medium accessible by computing device 600, and includes volatile and non-volatile media, as well as removable and non-removable media. By way of example, and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media includes media implemented in any method or technology for storing content such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other storage technologies, optical discs, digital versatile discs (DVDs) or other optical disc storage, magnetic tape, disk storage, or other magnetic storage devices, or any other medium that can be used to store desired content and is accessible by computing device 600. However, computer storage media does not include communication media. Communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals, such as carrier waves or other transmission mechanisms, and includes any content delivery medium. By way of example, and not limitation, communication media includes wired media, such as wired networks or direct wired connections, and wireless media, such as voice, radio frequency, infrared, and other wireless media. Any combination of the above items should also be included within the scope of computer-readable media.

[0057] System memory 630 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory 631 and random access memory 632. Basic input / output system 633 (BIOS) is typically stored in read-only memory 631, which contains basic routines that facilitate the transfer of content between components within computing device 600, such as during startup. RAM 632 typically contains data and / or program modules that are readily accessible and / or currently in operation to processing unit 620. By way of example and not limitation, Figure 6 The diagram illustrates the operating system 634, other program modules 635, and program data 636.

[0058] The computing device 600 may also include other removable / non-removable, volatile / non-volatile computer storage media. This is just one example. Figure 6 The illustration depicts a hard disk drive 641 that reads from or writes to a non-removable, non-volatile magnetic medium. Other removable / non-removable, volatile / non-volatile computer storage media that may be used with the exemplary computing device include, but are not limited to, magnetic tape cassettes, flash memory cards, digital universal disks, digital video tapes, solid-state RAM, solid-state read-only memory, and other computer storage media defined and described above. The hard disk drive 641 is typically connected to the system bus 621 via a non-volatile memory interface (such as interface 640).

[0059] The above discussion and Figure 6 The driver and its associated computer storage medium illustrated in the diagram provide storage for computer-readable instructions, data structures, program modules, and other data for the computing device 600. For example, in Figure 6 In this diagram, hard disk drive 641 is shown storing operating system 644, other program modules 645, and program data 646. Note that these components may be the same as or different from operating system 634, other program modules 635, and program data 636. Operating system 644, other program modules 645, and program data 646 are given different reference numerals here to indicate that they are at least different copies.

[0060] Computing device 600 can operate in a networked environment using a logical connection to one or more remote computers. Computing device 600 is shown connected to a general network connection 651 (to network 670) via a network interface or adapter 650, which in turn connects to a system bus 621. In a networked environment, program modules or portions thereof, or their peripherals, described relative to computing device 600, can be stored in the memory of one or more other computing devices communicatively coupled to computing device 600 via general network connection 661. It should be understood that the network connections shown are exemplary, and other methods of establishing communication links between computing devices can be used.

[0061] Although described as a single physical device, the exemplary computing device 600 may be a virtual computing device, in which case the functionality of the aforementioned physical components (e.g., CPU 620, system memory 630, network interface 640, and other similar components) may be provided by computer-executable instructions. These computer-executable instructions may execute on a single physical computing device or may be distributed across multiple physical computing devices, including dynamically distributed across multiple physical computing devices, such that the specific physical computing device hosting such computer-executable instructions changes dynamically over time based on demand and availability. In the case where the exemplary computing device 600 is a virtualized device, the underlying physical computing device hosting such a virtualized computing device may itself include physical components similar to those described above and operate in a similar manner. Furthermore, virtual computing devices may be used in multiple layers, with one virtual computing device executing within the architecture of another virtual computing device. Therefore, as used herein, the term "computing device" refers to a physical computing device or a virtualized computing environment, including virtual computing devices, where computer-executable instructions can be executed in a manner consistent with their execution by a physical computing device. Similarly, as used herein, the term referring to physical components of a computing device refers to physical components or their virtualized components that perform the same or equivalent functions.

[0062] As a first example, the above description includes a computing device comprising: one or more processing units; and one or more computer-readable storage media including: first computer-executable instructions, which, when executed by the processing units, cause the computing device to: host a container providing a file system virtualization environment isolated from the host file system of the computing device; and a container operating system image including: a container boot manager, first container boot configuration data, a container operating system loader, and first container operating system configuration data; wherein the container boot manager includes second computer-executable instructions, which, when executed by the processing units, cause the computing device to: connect to the container operating system image via a container host. The process involves: reading the first container boot configuration data, whereby the container host connection is displayed as a device within the container; receiving the composite device as a boot device specification from the first container boot configuration data, whereby the composite device abstracts the first device as the primary layer and the second device as the secondary layer; and identifying the composite device as the boot device for the container operating system loader. The container operating system loader includes third computer-executable instructions, which, when executed by the processing unit, cause the computing device to: receive the composite device as a boot device identifier; read the obtained container operating system configuration data from the composite device; and use the obtained operating system configuration data to boot the operating system within the container.

[0063] The second example is the computing device of the first example, wherein the container operating system image also includes container firmware.

[0064] The third example is a computing device of the second example, wherein the first computer-executable instructions further enable the computing device to: execute container firmware in the container using the computing device's management program.

[0065] The fourth example is the computing device of the first example, where the container host connection appears as a network connection from inside the container.

[0066] The fifth example is the computing device of the first example, wherein the second computer-executable instructions further cause the computing device to: receive an identifier of a container host connection as a boot device; determine that the composite device is different from the container host connection; and read container boot configuration data from the composite device in response to the determination that the identified boot device has changed; wherein the specification of receiving the composite device as a boot device occurs after receiving the identifier of a container host connection as a boot device.

[0067] The sixth example is the computing device of the fifth example, wherein determining that the composite device is different from the container host connection includes comparing device identifiers, the device identifier of the composite device being based on the device identifiers of a first device and a second device abstracted from the composite device.

[0068] The seventh example is the computing device of the fifth example, wherein reading container boot configuration data from the composite device includes: reading the first container boot configuration data again from the container operating system image.

[0069] The eighth example is the computing device of the fifth example, wherein reading container boot configuration data from the composite device includes: reading second container boot configuration data from a sandbox, the sandbox including file activities from within the container that are isolated from the host file system of the computing device.

[0070] The ninth example is the computing device of the first example, wherein the container operating system configuration data obtained from the composite device includes: reading the first container operating system configuration data from the container operating system image.

[0071] The tenth example is the computing device of the first example, wherein reading the obtained container operating system configuration data from the composite device includes: reading second container operating system configuration data from a sandbox, the sandbox including file activities from within the container that are isolated from the host file system of the computing device.

[0072] The eleventh example is the computing device of the first example, wherein the first device, abstracted by the composite device, is a sandbox, which includes file activities from within the container that are isolated from the host file system of the computing device, and the second device, abstracted by the composite device, is a container host connection.

[0073] The twelfth example is the computing device of the first example, wherein the composite device is associated with a composite file system that abstracts the first file system as the primary layer and the second file system as the secondary layer. The first file system provides access to persistent data on the first device, and the second file system provides access to persistent data on the second device.

[0074] The thirteenth example is a method for booting an operating system in a container. The method provides a file system virtualization environment isolated from the host computing environment hosting the container. The method includes: receiving a specification for a composite device as a boot device, the composite device abstracting a first device as a primary layer and a second device as a secondary layer; in response to receiving the specification for the composite device as a boot device, reading operating system configuration data from a composite file system associated with the composite device, the composite file system abstracting a first file system as a primary layer and a second file system as a secondary layer, the first file system providing access to persistent data on the first device and the second file system providing access to persistent data on the second device; and booting the operating system in the container using the read operating system configuration data; wherein the read operating system configuration data is read from the first file system if it is found therein; and wherein the read operating system configuration data is read from the second file system if it is not found therein.

[0075] The fourteenth example is the method of the thirteenth example, wherein the first file system is at least part of the container's file system virtualization environment, such that edits made from within the container are accessible through the first file system and isolated from and inaccessible through the second file system.

[0076] The fifteenth example is the method of the thirteenth example, and further includes: receiving a specification for a second device as an initial boot device; reading boot configuration data from a second file system based on the received specification for the second device as an initial boot device; wherein reading the boot configuration data occurs when receiving a specification for a composite device as a boot device.

[0077] The method in Example 16 and Example 15 further includes: reading boot configuration data from a composite file system in response to determining that reading boot configuration data from a second file system results in a specification for receiving a different boot device.

[0078] The seventeenth example is the method of the thirteenth example, and further includes: directing a volume mount request for the identified volume to the composite device; passing the volume mount request to a device at each layer of the composite device if there is no existing metadata indicating that one or more layers of the composite device lack the identified volume; and passing the volume mount request only to devices at those layers of the composite device that are indicated by existing metadata to have the identified volume.

[0079] The eighteenth example is the method of the thirteenth example, and further includes: directing a folder open request for the identified folder to the composite file system; passing the folder open request to the file system at each layer of the composite file system if there is no existing metadata indicating that one or more layers of the composite file system lack the identified folder; passing the folder open request only to the file systems of those layers of the composite file system that are indicated by existing metadata to have the identified folder; and generating a file list for the identified folder including: a first file found in the identified folder at multiple layers of the composite file system, and only a single instance of the first file from the highest layer where the first file is found.

[0080] The nineteenth example is the method of the eighteenth example, wherein generating the file list includes: if the file deletion mark corresponding to the second file exists at a higher level than the first level, then the second file found in the identified folder at the first level of the composite file system is excluded.

[0081] The twentieth example is one or more computer-readable storage media containing computer-executable instructions that, when executed, perform steps including: receiving a specification for a composite device as a boot device, the composite device abstracting a first device as a primary layer and a second device as a secondary layer; in response to receiving the specification for the composite device as a boot device, reading operating system configuration data from a composite file system associated with the composite device, the composite file system abstracting a first file system as a primary layer and a second file system as a secondary layer, the first file system providing access to persistent data on the first device and the second file system providing access to persistent data on the second device; and booting an operating system in a container using the read operating system configuration data; wherein the read operating system configuration data is read from the first file system based on whether the operating system configuration data is found in the first file system; and wherein the read operating system configuration data is read from the second file system based on whether the operating system configuration data is found in the first file system.

[0082] As can be seen from the above description, a mechanism has been proposed for providing a layered composite boot device and file system for operating system booting in a file system virtualization environment. Given the many possible variations of the subject matter described herein, we claim all embodiments that may fall within the scope of the following claims and their equivalents as our invention.

Claims

1. A computing device, comprising: One or more processing units; as well as One or more computer-readable storage media, including: A first computer-executable instruction, which, when executed by the processing unit, causes the computing device to: A container that provides a file system virtualization environment isolated from the host file system of the computing device; and Container operating system images, including: Container boot manager First container boot configuration data. Container operating system loader, and First container operating system configuration data; The container boot manager includes second computer-executable instructions that, when executed by the processing unit, cause the computing device to: The first container boot configuration data is read from the container operating system image via a container host connection, and the container host connection is displayed as a device within the container. The read-receive composite device, which receives configuration data from the first container as a specification for the boot device, abstracts the first device as the primary layer of the composite device and the second device as the secondary layer of the composite device; and The composite device is identified as the boot device for the container operating system loader; and The container operating system loader includes third computer-executable instructions that, when executed by the processing unit, cause the computing device to: Receive the identifier of the composite device as the guiding device; The container operating system configuration data read from the composite device; and The obtained operating system configuration data is used to boot the operating system in the container.

2. The computing device according to claim 1, wherein the container operating system image further includes container firmware.

3. The computing device of claim 2, wherein the first computer-executable instructions further cause the computing device to: The management program of the computing device is used to execute the container firmware in the container.

4. The computing device of claim 1, wherein the container host connection originates from within the container as a network connection.

5. The computing device of claim 1, wherein the second computer-executable instructions further cause the computing device to: The container host connection is received as the identifier of the boot device; It was determined that the composite device and the container host were connected differently; and In response to the determination that the identified boot device has changed, container boot configuration data is read from the composite device; The specification for receiving the composite device as the boot device occurs after the identifier for receiving the container host connection as the boot device is received.

6. The computing device of claim 5, wherein determining that the composite device is different from the container host connection includes: The device identifiers of the composite device are compared, and the device identifiers of the first device and the second device are abstracted from the composite device.

7. The computing device of claim 5, wherein reading the container boot configuration data from the composite device comprises: The first container boot configuration data is read again from the container operating system image.

8. The computing device of claim 5, wherein reading the container boot configuration data from the composite device comprises: Read second container boot configuration data from the sandbox, which includes file activities from within the container that are isolated from the host file system of the computing device.

9. The computing device of claim 1, wherein the container operating system configuration data read from the composite device comprises: Read the configuration data of the first container operating system from the container operating system image.

10. The computing device of claim 1, wherein reading the obtained container operating system configuration data from the composite device comprises: Read second container operating system configuration data from the sandbox, which includes file activities from within the container that are isolated from the host file system of the computing device.

11. The computing device of claim 1, wherein the first device abstracted by the composite device is a sandbox, the sandbox including file activities from within the container isolated from the host file system of the computing device, and the second device abstracted by the composite device is the container host connection.

12. The computing device of claim 1, wherein the composite device is associated with a composite file system, the composite file system abstracting a first file system as a primary layer and a second file system as a secondary layer, the first file system providing access to persistent data on the first device and the second file system providing access to persistent data on the second device.

13. A method for booting an operating system in a container, the container providing a file system virtualization environment isolated from the host computing environment hosting the container, the method comprising: The receiving composite device is specified as a guiding device, wherein the composite device abstracts the first device as the main layer of the composite device and the second device as the secondary layer of the composite device; In response to the receipt of the specification of the composite device as the boot device, operating system configuration data is read from the composite file system associated with the composite device, the composite file system abstracting a first file system as the main layer of the composite file system and abstracting a second file system as the secondary layer of the composite file system, the first file system providing access to persistent data on the first device and the second file system providing access to persistent data on the second device; as well as The read operating system configuration data is used to boot the operating system in the container; Wherein, the operating system configuration data is found in the first file system, and the read operating system configuration data is read from the first file system; and Since the operating system configuration data was not found in the first file system, the operating system configuration data was read from the second file system.

14. The method of claim 13, wherein the first file system is at least part of the file system virtualization environment of the container, such that edits made from within the container are accessible through the first file system and isolated from and inaccessible through the second file system.

15. The method of claim 13, further comprising: The specification for receiving the second device as the initial boot device; as well as Based on the received specifications of the second device as the initial boot device, boot configuration data is read from the second file system; The specification for receiving the composite device as the boot device occurs during the reading of the boot configuration data.

16. The method of claim 15, further comprising: In response to determining that reading the boot configuration data from the second file system results in receiving the specification of a different boot device, the boot configuration data is read from the composite file system.

17. The method of claim 13, further comprising: The volume mount request for the identified volume is directed to the composite device; If there is no existing metadata indicating that one or more layers of the composite device lack the identified volume, the volume mount request is transmitted to the device on each layer of the composite device; as well as The volume mount request is only passed to devices at those layers that are indicated by the existing metadata as having the identified volume.

18. The method of claim 13, further comprising: The folder open request for the identified folder will be directed to the composite file system; If there is no existing metadata indicating that one or more layers of the composite file system lack the identified folder, the folder open request is passed to the file system at each layer of the composite file system; the folder open request is only passed to the file systems at those layers of the composite file system that are indicated by the existing metadata to have the identified folder; as well as The generated file list for the identified folder includes: the first file found in the identified folder at multiple layers of the composite file system, with only a single instance of the first file from the highest layer where the first file was found.

19. The method of claim 18, wherein generating the file list comprises: If the file deletion marker corresponding to the second file exists at a level higher than the first level, then the second file found in the folder identified at the first level of the composite file system is excluded.

20. One or more computer-readable storage media, including computer-executable instructions that, when executed, perform steps, the steps including: The receiving composite device is specified as a guiding device, wherein the composite device abstracts the first device as the main layer of the composite device and the second device as the secondary layer of the composite device; In response to the receipt of the specification of the composite device as the boot device, operating system configuration data is read from the composite file system associated with the composite device, the composite file system abstracting a first file system as the main layer of the composite file system and abstracting a second file system as the secondary layer of the composite file system, the first file system providing access to persistent data on the first device and the second file system providing access to persistent data on the second device; as well as The read operating system configuration data is used to boot the operating system in the container; Wherein, the operating system configuration data is found in the first file system, and the read operating system configuration data is read from the first file system; and Since the operating system configuration data was not found in the first file system, the operating system configuration data was read from the second file system.

Images