Abstract: Examples of enterprise management using managed virtual machines for virtualized applications are described. In some examples, a managed virtual machine is executed on a host device and enrolled with a management service. A virtualized application drive is stored in the managed virtual machine. A launch agent executed within the managed virtual machine detects an application access request corresponding to user interaction with a host operating system of the host device. The application volumes launch agent accesses the virtualized application drive and launches the virtualized application corresponding to the application access request.

Abstract: A virtualized application runs on top of a guest operating system (OS) of a virtual machine and is supported by a file system of the guest OS. The method of supporting the virtualized application with the file system includes provisioning a first virtual disk as a data store of the file system and a second virtual disk for the virtualized application, wherein the first and second virtual disks store first and second files of the virtualized application, respectively, retrieving metadata of the virtualized application, updating a master file table of the file system according to the retrieved metadata to map the first files to logical blocks of the file system, updating the master file table to map the second files to additional logical blocks according to the retrieved metadata, and creating a mapping for the additional logical blocks, that is used during an input/output operation, according to the retrieved metadata.

Abstract: A system is described for high-performance delivery of applications via attachable application storage volumes (ASV), particularly in cloud-based VDI environments, by precaching application data that is determined by learning the application behavior. Data blocks for files that are likely to be used by the application are prefetched and cached by virtual machines before the application requests those blocks so that the relevant data is instantly available in memory when required without needing to wait for the data to be transmitted from the ASV. In order to efficiently prefetch content, the read pattern for application files and their corresponding blocks is inspected. This information is used during application delivery after a user logs onto the virtual machine to selectively prefetch those blocks from the ASVs. As a result, when the user launches those applications, the system avoids the performance penalty of reading those blocks from the ASV.

Abstract: A virtualized application runs on top of a guest operating system (OS) of a virtual machine and is supported by a file system of the guest OS. The method of supporting the virtualized application with the file system includes provisioning a first virtual disk as a data store of the file system and a second virtual disk for the virtualized application, wherein the first and second virtual disks store first and second files of the virtualized application, respectively, retrieving metadata of the virtualized application, updating a master file table of the file system according to the retrieved metadata to map the first files to logical blocks of the file system, updating the master file table to map the second files to additional logical blocks according to the retrieved metadata, and creating a mapping for the additional logical blocks, that is used during an input/output operation, according to the retrieved metadata.

Abstract: A system is described for high-performance delivery of applications via attachable application storage volumes (ASV), particularly in cloud-based VDI environments, by precaching application data that is determined by learning the application behavior. Data blocks for files that are likely to be used by the application are prefetched and cached by virtual machines before the application requests those blocks so that the relevant data is instantly available in memory when required without needing to wait for the data to be transmitted from the ASV. In order to efficiently prefetch content, the read pattern for application files and their corresponding blocks is inspected. This information is used during application delivery after a user logs onto the virtual machine to selectively prefetch those blocks from the ASVs. As a result, when the user launches those applications, the system avoids the performance penalty of reading those blocks from the ASV.

Abstract: An isolated environment is instantiated in response to receiving a request to execute a process. One or more events occurring within the isolated environment in which the process executes are identified. Whether the actual behavior of the process executing within the isolated environment deviates from an expected behavior of the execution of the process is determined. Only when it is determined that the process deviates from the expected behavior is behavior data, which describes the actual behavior of the process during execution, stored. A determination is then made as to whether the process is compromised by analyzing the behavior data that describes the actual behavior of the process.

Abstract: The execution of a process within a virtual machine (VM) may be monitored, and when a trigger event occurs, additional monitoring is initiated, including storing behavior data describing the real-time events taking place inside the VM. This behavior data may then be compared to information about the expected behavior of that type of process in order to determine whether malware has compromised the VM. The trigger event may be analyzed in relation to a set of heuristics, and based on the analysis, a data collection process may be initiated wherein the data comprises information about events occurring in the first virtual machine.

Abstract: Updating a central repository with information about malware resident upon a computer system. Upon detecting the malware executing in a virtual machine, a software module, without manual instruction, sends malware manifest data to a central repository over a network. The malware manifest data may comprise a copy of the malware and all versions, including temporary versions, of any files written to, updated by, or accessed by the malware. The central repository may receive, over a network from at least two computer systems, distinct sets of malware manifest data and may subsequently store the sets of malware manifest data.

Abstract: An isolated environment is instantiated in response to receiving a request to execute a process. One or more events occurring within the isolated environment in which the process executes are identified. Whether the actual behavior of the process executing within the isolated environment deviates from an expected behavior of the execution of the process is determined. Only when it is determined that the process deviates from the expected behavior is behavior data, which describes the actual behavior of the process during execution, stored. A determination is then made as to whether the process is compromised by analyzing the behavior data that describes the actual behavior of the process.

Abstract: The execution of a process within a VM may be monitored, and when a trigger event occurs, additional monitoring is initiated, including storing behavior data describing the real-time events taking place inside the VM. This behavior data may then be compared to information about the expected behavior of that type of process in order to determine whether malware has compromised the VM.

Abstract: The execution of a process within a VM may be monitored, and when a trigger event occurs, additional monitoring is initiated, including storing behavior data describing the real-time events taking place inside the VM. This behavior data may then be compared to information about the expected behavior of that type of process in order to determine whether malware has compromised the VM.

Abstract: Updating a central repository with information about malware resident upon a computer system. Upon detecting the malware executing in a virtual machine, a software module, without manual instruction, sends malware manifest data to a central repository over a network. The malware manifest data may comprise a copy of the malware and all versions, including temporary versions, of any files written to, updated by, or accessed by the malware. The central repository may receive, over a network from at least two computer systems, distinct sets of malware manifest data and may subsequently store the sets of malware manifest data.

Abstract: The execution of a process within a VM may be monitored, and when a trigger event occurs, additional monitoring is initiated, including storing behavior data describing the real-time events taking place inside the VM. This behavior data may then be compared to information about the expected behavior of that type of process in order to determine whether malware has compromised the VM.

Abstract: Updating a central repository with information about malware resident upon a computer system. Upon detecting the malware executing in a virtual machine, a software module, without manual instruction, sends malware manifest data to a central repository over a network. The malware manifest data may comprise a copy of the malware and data identifying or comprising a set of files infected by the malware. The central repository may receive, over a network from at least two computer systems, distinct sets of malware manifest data and may subsequently store the sets of malware manifest data.

Abstract: The execution of a process within a VM may be monitored, and when a trigger event occurs, additional monitoring is initiated, including storing behavior data describing the real-time events taking place inside the VM. This behavior data may then be compared to information about the expected behavior of that type of process in order to determine whether malware has compromised the VM. The trigger event may be analyzed in relation to a set of heuristics, and based on the analysis, a data collection process may be initiated wherein the data comprises information about events occurring in the first virtual machine.