Enabling Filter-Level Access to Virtual Disks

• US 20160306643A1
• Filed: 04/14/2015
• Published: 10/20/2016
• Est. Priority Date: 04/14/2015
• Status: Active Grant

• Current Assignee: Vmware LLC (Broadcom, Inc.)
• Original Assignee: VMware, Inc. (Broadcom, Inc.)
• Inventors: Klee, Christoph, Drzewiecki, Adrian
• Granted Patent: US 10,025,606 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 2009/45579 I/O management, e.g. providing access to device drivers or storage
• CPC Class Codes: G06F 3/0619 in relation to data integrity, e.g. data losses, bit errors
• CPC Class Codes: G06F 3/0665 at area level, e.g. provisioning of virtual or logical volumes
• CPC Class Codes: G06F 3/0689 Disk arrays, e.g. RAID, JBOD
• CPC Class Codes: G06F 9/45545 Guest-host, i.e. hypervisor is an application program itself, e.g. VirtualBox
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects
• CPC Class Codes: G06F 9/54 Interprogram communication
• CPC Class Codes: G06F 9/545 where tasks reside in different layers, e.g. user- and kernel-space

Abstract

Techniques for enabling filter-level access to a virtual disk (VMDK) are provided. In one set of embodiments, an application can invoke a first application programming interface (API) for opening the VMDK, the invoking of the first API causing an ordered group of filters associated with the VMDK to be instantiated. The application can further coordinate with a target filter in the ordered group of filters to establish a communication channel with the target filter and can receive, from the target filter, a handle to the target filter via the communication channel. The application can then issue an I/O request to the VMDK via the target filter using the handle, the issuing causing data associated with the I/O request to be filtered by other filters that are downstream from the target filter in the ordered group.

Claims

1. A method for enabling filter-level access to a virtual disk (VMDK), the method comprising:

invoking, by an application running on a computer system, a first application programming interface (API) for opening the VMDK, the invoking of the first API causing an ordered group of filters associated with the VMDK to be instantiated;

coordinating, by the application, with a target filter in the ordered group of filters to establish a communication channel between the application and the target filter;

receiving, by the application from the target filter, a handle to the target filter via the communication channel; and

issuing, by the application, an I/O request to the VMDK via the target filter using the handle, the issuing causing data associated with the I/O request to be filtered by other filters that are downstream from the target filter in the ordered group.

2. The method of claim 1 wherein the data associated with the I/O request is not filtered by the target filter or any filters upstream from the target filter in the ordered group.

3. The method of claim 1 wherein the coordinating comprises:

placing a predefined command or data in a global data structure accessible to the target filter.

4. The method of claim 1 wherein the coordinating comprises:

opening a socket connection at a predefined socket address known to the target filter.

5. The method of claim 1 wherein the issuing comprises:

invoking a second API that takes as input the I/O request and the handle to the target filter.

6. The method of claim 1 wherein the issuing comprises:

passing the I/O request and the handle to the target filter over the communication channel.

7. The method of claim 1 wherein the first API does not return a VMDK handle to the application, and wherein the application does not have access to any APIs that enable the application to issue I/O requests directly to the VMDK using a VMDK handle.

8. A non-transitory computer readable storage medium having stored thereon program code executable by computer system, the program code embodying a method for enabling filter-level access to a VMDK, the method comprising:

invoking, by an application running on the computer system, a first API for opening the VMDK, the invoking of the first API causing an ordered group of filters associated with the VMDK to be instantiated;

coordinating, by the application, with a target filter in the ordered group of filters to establish a communication channel between the application and the target filter;

receiving, by the application from the target filter, a handle to the target filter via the communication channel; and

issuing, by the application, an I/O request to the VMDK via the target filter using the handle, the issuing causing data associated with the I/O request to be filtered by other filters that are downstream from the target filter in the ordered group.

9. The non-transitory computer readable storage medium of claim 8 wherein the data associated with the I/O request is not filtered by the target filter or any filters upstream from the target filter in the ordered group.

10. The non-transitory computer readable storage medium of claim 8 wherein the coordinating comprises:

placing a predefined command or data in a global data structure accessible to the target filter.

11. The non-transitory computer readable storage medium of claim 8 wherein the coordinating comprises:

opening a socket connection at a predefined socket address known to the target filter.

12. The non-transitory computer readable storage medium of claim 8 wherein the issuing comprises:

invoking a second API that takes as input the I/O request and the handle to the target filter.

13. The non-transitory computer readable storage medium of claim 8 wherein the issuing comprises:

passing the I/O request and the handle to the target filter over the communication channel.

14. The non-transitory computer readable storage medium of claim 8 wherein the first API does not return a VMDK handle to the application, and wherein the application does not have access to any APIs that enable the application to issue I/O requests directly to the VMDK using a VMDK handle.

15. A computer system comprising:

a processor; and

an application running on the processor,

wherein the application is configured to;

invoke a first API for opening a VMDK, the invoking of the first API causing an ordered group of filters associated with the VMDK to be instantiated;

coordinate with a target filter in the ordered group of filters to establish a communication channel between the application and the target filter;

receive, from the target filter, a handle to the target filter via the communication channel; and

issue an I/O request to the VMDK via the target filter using the handle, the issuing causing data associated with the I/O request to be filtered by other filters that are downstream from the target filter in the ordered group.

16. The computer system of claim 15 wherein the data associated with the I/O request is not filtered by the target filter or any filters upstream from the target filter in the ordered group.

17. The computer system of claim 15 wherein the coordinating comprises:

placing a predefined command or data in a global data structure accessible to the target filter.

18. The computer system of claim 15 wherein the coordinating comprises:

opening a socket connection at a predefined socket address known to the target filter.

19. The computer system of claim 15 wherein the issuing comprises:

invoking a second API that takes as input the I/O request and the handle to the target filter.

20. The computer system of claim 15 wherein the issuing comprises:

passing the I/O request and the handle to the target filter over the communication channel.

21. The computer system of claim 15 wherein the first API does not return a VMDK handle to the application, and wherein the application does not have access to any APIs that enable the application to issue I/O requests directly to the VMDK using a VMDK handle.