VAIO is a Framework that enables third parties (Partners) to develop filters that run in ESXi and can intercept any IO requests from a guest operating system to a virtual disk. An IO will not be issued or committed to disk without being processed by IO Filters created by 3rd parties. Filters execute inside ESXi and not in a VM. In addition, the VAIO Framework provides a centralized installation and upgrade.

The first release of vSphere APIs for IO Filtering (ESXi 6.0 Update 1) will only support and certify the Caching and Replication use cases and now it supported with vSphere 6.0,6.5 and 6.7 releases

Caching – Will significantly increase the IOPS available, reduce latency, and increase hardware utilization rates.

Replication – Will allow the user to create VM granular replication policies for use in DR and other scenarios (ie. Snapshot)

Note: This package does entail a vetting process and based on the answers to the questionnaire below, partner solutions may or may not qualify for this certification and listing.

How IO Filtering Works

IO request moving between the guest operating system (Initiator), located in the Virtual Machine Monitor(VMM), and a virtual disk (Consumer) are filtered through a series of two IO Filters (per disk), one filter per filter class, invoked in filter class order. For example, a replication filter executes before a cache filter. Once the IO request has been filtered by all the filters for the particular disk, the IO request moves on to its destination, either the VM or the virtual disk.

Partner will develop IO Filter plug-ins to provide filtering virtual machines. Each IO Filter registers a set of callbacks with the Filter Framework, pertaining to different disk operations. If a filter fails an operation, only the filters prior to it are informed of the failure.

Any filter can complete, fail, pass, or defer an IO request. A filter will defer an IO if the filter has to do a blocking operation like sending the data over the network, but wants to allow further IOs to get processed as well. If a filter performs a blocking operation during the regular IO processing path, it would affect the IOPS of the virtual disk, since we wouldn’t be processing any further IOs until the blocking operation completes. If the filter defers an IO request, the Filter Framework will not pass the request to subsequent filters in the class order until the filter completes the request and notifies the Filter Framework that the IO may proceed.

Overview

The vSphere APIs for I/O Filtering Certification package is part of the SDDC Integration program and provides tools and development resources designed to enable TAP partners to get their developed Filter class-tested against vSphere and obtain official VMware certification and support.

Upon successful completion of Filter IO certification and digitally signed by VMware,  the products will be listed in the VMware Compatibility Guide. Partners will also be provided with a VMware ReadyTM logo, which can be used in their marketing and sales efforts of the certified products.

Once qualified, partners will be provided with up to date product communications on VMware vSphere release dates, certification policies, and product features.

VAIO Technical Overview

The vSphere APIs for I/O Filtering enables the interception of I/O requests from Guest Operating Systems (GOS) to virtual disks (VMDK). This is enabled by inserting an I/O Filter in the vSphere I/O stack. This filter driver executes in user space (called User Worlds in ESXi) so that 3^rd party filter code can run natively in ESXi without jeopardizing the stability of the ESXi kernel. At the same time, VAIO allows for filter drivers to intercept I/O operations as they go through the data path of the ESXi kernel without any perceived performance overhead. I/O operations are intercepted as soon as they go through the virtual SCSI emulation layer (vSCSI) in the kernel, as shown in Figure 1. As a result, data services can be applied before I/O is processed by the different storage virtualization modules of ESXi’s kernel (VMFS, NFS, SCSI, vSAN, etc), which allows for generic data services that are agnostic to the storage backend. For the same reason, I/O is intercepted before it traverses the network providing security and integrity of data.

Let’s take a look at the above example

The I/O Filter is implemented in the user space/world to avoid impacting the hypervisor should there be an issue with the I/O Filter. It is also possible to have multiple I/O Filters applied to the same VM or VMDK(s). If multiple I/O Filters are applied to the same VM or VMDK, the order in which it is applied is defined by the filter “class order” which is defined as part of the VAIO framework. This means, for instance, that a replication filter executes before a cache filter. Once the I/O has moved through all I/O filters, it moves to the next layer.

The I/O Filter not only intercepts and manipulates I/O depending on the implemented functionality, but it can also be responsible for acknowledging the I/O to the Guest Operating System. It is a bi-directional information and traffic flow. If an I/O Filter is written to do write caching, this can be implemented in a write-back or write-through modus. Depending on the implementation, the I/O Filter needs to be informed that the write data is committed to a storage device before placing it in the cache.

When a replication I/O Filter is implemented, the replication can be done either synchronously or asynchronously. Synchronous replication includes the latency to reach the remote storage in the critical path of a write operation—both copies of the operation must be persisted before the operation is acknowledged to the Guest OS. Asynchronous replication is used when the additional latency is not acceptable. This means that the acknowledgment from the local storage system enables the VM to continue, while the I/O is (asynchronously) being replicated to a different location. Note that in this case, the successful asynchronous replication of the I/O is still acknowledged to the I/O Filter. The I/O filter will keep track of each I/O request on a per VMDK basis to ensure data consistency and integrity.

Besides regular I/O, VAIO is also informed when certain control operations are performed. For instance, when a snapshot is requested by someone (or something), or a change to a VM or VMDK is requested (grow disk, stop VM, start VM, etc.) the I/O Filter is informed about this event so that this change can be taken in to account.

Requirements for implementing I/O Filters usually depend on the type of filter being used. There are, however, a couple of common requirements before an I/O Filter can be installed and configured:

• vSphere 6.0 Update 1 or higher
• vMotion with attached filters is supported but requires the I/O Filter to be installed on the target host
• DRS is supported but requires the I/O Filter to be installed on all hosts in the cluster
• Note that with vSphere 6.0 U1 it was required to have DRS enabled, as of vSphere 6.0 U2 this is no longer the case.
• Permissions to install a VIB (vSphere Installation Bundle)

Benefits of VAIO

• Encryption enables the third-party software to encrypt and decipher the data streams from a virtual machine on the fly. As a result, the storage receives the already encrypted data. The inherent flexibility of VAIO enables the solution to process the data stream going from not only the entire virtual machine but also a single application.
• De-duplicationis already employed in VMware Virtual SAN. Data that passes through the driver is deduplicated in real-time and then sent to storage, allowing to reduce the occupied disk space. This technique is already available for VMware partners.
• Tiering allows multi-level data stored based on its importance. Data is kept on storages with different availability and performance characteristics. VAIO enables to analyze data and determine its destination storage.
• Analytics enables us to inspect data stream from a particular virtual machine directly and build different solutions including, for example, caching systems (i.e., such solutions as primary which can be connected to the hypervisor directly). It also allows detecting data from particular applications in the stream or using write-back caching.

more Details Refer to Storage Hub