Abstract:
In one aspect, a method includes providing virtual volumes (VVols) and mappings from the VVols to corresponding data storage devices to an I/O filter in a first virtual machine (VM), sending control path commands sent from the first VM to a control-path manager VM, the first VM and the control-path manager VM being run on a VM host, intercepting an I/O for a VVol using the I/O filter and sending the intercepted I/O to a data storage device mapped to the VVol.

Description:
BACKGROUND 
     A virtual volume (VVol) (sometimes called a virtual machine (VM) Volume), is a VMDK (Virtual Machine Disk) stored inside a storage system. Instead of a VM host accessing its virtual disk (VMDK) which is stored in a VMFS formatted data store (part of ESXi hypervisor) built on top of a SCSI LUN (e.g., SAS, SATA, iSCSI, Fibre Channel) or an NFS file system presented by a storage system (or appliance), a VVol pushes more functionality and visibility down into the storage system. In one example, a VVol is a storage container provisioned using VMware vSphere® API (application programming interface) for Storage Awareness (VASA), which aligns to VM boundaries and contains a data store, a set of data services expected, and maintains the metadata of a requested policy. 
     SUMMARY 
     In one aspect, a method includes providing virtual volumes (VVols) and mappings from the VVols to corresponding data storage devices to an I/O filter in a first virtual machine (VM), sending control path commands sent from the first VM to a control-path manager VM, the first VM and the control-path manager VM being run on a VM host, intercepting an I/O for a VVol using the I/O filter and sending the intercepted I/O to a data storage device mapped to the VVol. 
     In another aspect, an apparatus includes electronic hardware circuitry configured to provide virtual volumes (VVols) and mappings from the VVols to corresponding data storage devices to an I/O filter in a first virtual machine (VM), send control path commands sent from the first VM to a control-path manager VM, the first VM and the control-path manager VM being run on a VM host, intercept an I/O for a VVol using the I/O filter and send the intercepted I/O to a data storage device mapped to the VVol. 
     In a further aspect, an article includes a non-transitory computer-readable medium that stores computer-executable instructions. The instructions cause a machine to provide virtual volumes (VVols) and mappings from the VVols to corresponding data storage devices to an I/O filter in a first virtual machine (VM), send control path commands sent from the first VM to a control-path manager VM, the first VM and the control-path manager VM being run on a VM host, intercept an I/O for a VVol using the I/O filter and send the intercepted I/O to a data storage device mapped to the VVol. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an example of a virtual volume converter configuration prior to receiving data and control path commands. 
         FIG. 2  is a block diagram of an example of a virtual volume converter configuration depicting data path command and control path command flow. 
         FIG. 3  is a flowchart of an example of a process to handle control and data path commands. 
         FIG. 4  is a computer on which any portion of the process of  FIG. 3  may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     Described herein are techniques to form a control-path virtual machine (VM), which behaves as a virtual volume (VVol) storage array and exposes VVols to a hypervisor, but actually the VVols do not really exist. In one example, the control-path VM instructs an I/O filter to redirect the I/Os to other devices which may be traditional virtual disk (VMDK) devices or any other type of virtual devices. 
       FIG. 1  depicts a virtual volume converter configuration  100  prior to receiving data and control path commands and  FIG. 2  depicts a virtual volume converter configuration  200  that includes the same components as the virtual volume converter configuration  100  but shows data path command and control path command flow. 
     The virtual volume converter configurations  100  and  200  allow for generating a virtualized storage array that can abstract and virtualize multiple back-end storage providers of various types and expose a single end-point for them. In one example, the front-end personality for these devices will conform to the VVol format consumed by the VMWare vSphere infrastructure, and supports the control-path management that is required (through VMWare&#39;s VASA APIs). 
     As will be described herein, the control path for this virtualized device goes through a virtual entity (e.g., a VM) that is responsible for management of the back-end devices and mapping them into virtualized devices, while the data-path itself is fully separated and distributed, handled by a light-weight component running in the host (which is also a VM) context, and does not need to pass through the management VM at all. This provides for unlimited scaling of the data-path which does not need to go through any single bottleneck. This data-path layer can provide intelligent mirroring, caching and additional data-path related enhancements which are distributed across the various hosts rather than centralized in a single location. 
     This proposal can be used for migrating legacy storage arrays that do not expose VVol functionality as of yet into the VVol paradigm, while not sacrificing performance or generating any bottlenecks due to a centralized virtualization layer through which all I/Os need to go through. 
     Referring back to  FIG. 1 , the virtual volume converter configuration  100  includes a virtual machine host  102  and backend storage devices  104 . The virtual machine host  102  includes VM  110  and a control-path manager VM  116 . 
     The VM  110  includes an I/O filter  114 . The I/O Filter  114  is a filtering mechanism also called VAIO, the I/O filter runs within the same hypervisor user process which runs the virtual machine and can intercept all I/Os generated by the virtual machine and operate on them. The I/O Filter  114  is notified by the control-path manager VM  116 , through a connection  152  with the VVol targets  132 , about the VVols being exposed by the control-path manager VM  116  and the back-end storage devices  104  that the VVols are maps to. An I/O (sometimes referred to as an I/O (input/output) request) may be a read I/O request (sometimes referred to as a read request or a read) or a write I/O request (sometimes referred to as a write request or a write. 
     Using a connection  150 , the back-end storage devices  104  are attached to the control-path VM  116  (i.e., the back-end storage devices  104  are the internal disks of the control-path VM  116 ). The Control-path manager VM  116  includes a VVol interface  128  and VVol targets  132 . The Control-path manager VM  116  exposes the VVol interface  128 . In one example, the VVol interface  128  is a VMware vSphere® API for Storage Awareness (VASA) interface (e.g., VVol-storage provider) and handles the various control-path APIs that are provided through VASA, such as generating a new VVol, exposing the new VVol to the virtual machine host  102  and so forth. When a VVol is generated, the VVol interface  128  maps the VVol to a specific region on the back-end storage  104 , which may be a full storage device on the back-end or part of a storage device. 
     The control-path manager VM  116  also exposes the VVol targets  132  that is used to expose the VVols generated to the virtual machine host  102  itself in the data-path. In one example, the VVol targets  132  are SCSI targets that provides VVols with SCSI personality and responds to any queries. In one particular example, the SCSI target is an iSCSI target. 
     The back-end storage is consumed by the virtual machine host  102 . The back-end storage devices  104  include datastores (e.g., a datastore  120   a , a datastore  120   b  and a datastore  120   c ). The datastores  120   a - 120   c  may include network-attached storage (NAS), a virtual volume (VVol), a storage area network (SAN) and any other storage that can be attached to the virtual machine host  102  as devices. 
     Referring back to  FIG. 2 , control path command flows  202   a ,  204   a , such as SCSI discovery commands, for example, are received by the control-path manager VM  116  (i.e., control path command flow  202   a  is received) and sent in particular to the VVol targets  132  (i.e., control path command flow  202   b  is sent). 
     I/Os (i.e., data path commands) are intercepted by the I/O filter  114  (i.e., data path command flow  204   a  is intercepted path) and re-routed by the I/O filter  114  (i.e., data path command flow  201   b  is rerouted path) directly to a storage device (e.g., a datastore  120   b ). 
     Referring to  FIG. 3 , a process  300  is an example of a process to handle control and data path commands. Process  300  receives information of virtual volumes and backend storage devices mapped to the virtual volumes ( 304 ). For example, the control-path manager  116  provides the virtual volumes and their mapping to the data storage devices  104  to the I/O filter  114 . 
     Process  300  sends control path commands to the control-path manager ( 308 ). For example, the control path commands from the VM  110  bypass the I/O filter  114  and go straight to the control-path manager VM  116 . 
     Process  300  reroutes data path commands to a backend device ( 312 ). For example, an I/O received by the VM  110  is intercepted by the I/O filter  114  and is rerouted directly to the corresponding datastore of the back-end storage devices  104 . 
     Referring to  FIG. 4 , in one example, a computer  400  includes a processor  402 , a volatile memory  404 , a non-volatile memory  406  (e.g., hard disk) and the user interface (UI)  408  (e.g., a graphical user interface, a mouse, a keyboard, a display, touch screen and so forth). The non-volatile memory  406  stores computer instructions  412 , an operating system  416  and data  418 . In one example, the computer instructions  412  are executed by the processor  402  out of volatile memory  404  to perform all or part of the processes described herein (e.g., process  300 ). 
     The processes described herein (e.g., process  300 ) are not limited to use with the hardware and software of  FIG. 4 ; they may find applicability in any computing or processing environment and with any type of machine or set of machines that is capable of running a computer program. The processes described herein may be implemented in hardware, software, or a combination of the two. The processes described herein may be implemented in computer programs executed on programmable computers/machines that each includes a processor, a non-transitory machine-readable medium or other article of manufacture that is readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device to perform any of the processes described herein and to generate output information. 
     The system may be implemented, at least in part, via a computer program product, (e.g., in a non-transitory machine-readable storage medium such as, for example, a non-transitory computer-readable medium), for execution by, or to control the operation of, data processing apparatus (e.g., a programmable processor, a computer, or multiple computers)). Each such program may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the programs may be implemented in assembly or machine language. The language may be a compiled or an interpreted language and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program may be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. A computer program may be stored on a non-transitory machine-readable medium that is readable by a general or special purpose programmable computer for configuring and operating the computer when the non-transitory machine-readable medium is read by the computer to perform the processes described herein. For example, the processes described herein may also be implemented as a non-transitory machine-readable storage medium, configured with a computer program, where upon execution, instructions in the computer program cause the computer to operate in accordance with the processes. A non-transitory machine-readable medium may include but is not limited to a hard drive, compact disc, flash memory, non-volatile memory, volatile memory, magnetic diskette and so forth but does not include a transitory signal per se. 
     The processes described herein are not limited to the specific examples described. For example, the process  300  is not limited to the specific processing order of  FIG. 3 . Rather, any of the processing blocks of  FIG. 3  may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth above. 
     The processing blocks (for example, in the process  300 ) associated with implementing the system may be performed by one or more programmable processors executing one or more computer programs to perform the functions of the system. All or part of the system may be implemented as, special purpose logic circuitry (e.g., an FPGA (field-programmable gate array) and/or an ASIC (application-specific integrated circuit)). All or part of the system may be implemented using electronic hardware circuitry that include electronic devices such as, for example, at least one of a processor, a memory, a programmable logic device or a logic gate. 
     Elements of different embodiments described herein may be combined to form other embodiments not specifically set forth above. Various elements, which are described in the context of a single embodiment, may also be provided separately or in any suitable subcombination. Other embodiments not specifically described herein are also within the scope of the following claims.