virtualhome.blog My blog about virtualized infrastructures, backup and disaster recovery topics and the cloud !
Related Articles
In this post I’m going to present you a little overview of the vSphere API for I/O filtering (VAIO). I stumbled upon this API and did a lot of research about it. All in all I decided to write a blog post about it, because it is very interesting!
Introduction to the vSphere API for I/O filtering
The vSphere APIs for I/O filtering were first introduced in vSphere 6.0 Update1. Basically, the VAIO framework and the program around it was developed to provide VMware and partners the ability to insert filters for I/O into the data path of virtual machines. Those I/O filters enable the possibility to intercept and manipulate the I/O of a virtual machine. The VAIO framework is limited to exactly four use cases, whereby 2 use cases are currently exclusive to VMware only.
- Replication
- Caching
- Quality of Service QoS (VMware only)
- Encryption (VMware only)
Prior to the vSphere API for I/O filtering, partners had to use unsupported kernel level methods or some sort of virtual appliances to intercept the I/O traffic. All those solutions are implemented in a different way which could potentially cause instabilities and operational complexity. Basically, VMware wants their partners to have the chance to use the same APIs as all the others. In my opinion, this is going into the same direction as the VADP API from VMware. All vendors and partners who designed backup solutions have the same set of APIs to leverage their product.
Therefore, VMware has a certification process for partners before a solutions is officially VAIO certified.
Technical Overview of the vSphere API for I/O
So how does the VAIO framework function ? First of all, the VAIO enables the interception of I/O requests from a guest operating system to a VMware virtual disk (VMDK). This is possible by placing a filter driver into the vSphere I/O stack. This specific filter driver executes in the the user space (user world in ESXi) so that all the third party filter code can run nativeley in ESXi. Likewise, the VAIO allows the filter driver to intercept I/O operations through the ESXI kernel. All the I/O operations are intercepted at the SCSI emulation layer (vSCSI) in the kernel. As a result, partners and vendors are able to run their data services before the I/O is fully processed by the different storage virtualization modules of the ESXi kernel. We are talking about VMFS, NFS, SCSI, vSAN etc. here.
In the figure above, you can see the I/O path of the VAIO framework. In this specific example above, a single I/O Filter is shown. Therefore, the I/O Filter is implemented in the user space. This is to avoid producing any impact to the hypervisor if there is any issue with the I/O Filter. It is also possible to implement multiple I/O filters to the same VM or VMDK. If you are having multiple I/O filters, the order in which those are applied depends on the filter “class order” out of the VAIO framework. For example, a replication filter will execute before a caching filter does. After an I/O has moved through all the I/O filters, it moves to the next layer.
A detailed description and in depth guide on how it works can be found here: https://storagehub.vmware.com/t/vsphere-storage/vmware-vsphere-apis-for-i-o-filtering-vaio/
Vendors who use / will use the VAIO framework
So at the moment, there are a only 11 vendors who are using the VAIO framework. You can always check the current state on the VMware compatibility guide page located here: VMware Compatibility Guide for VAIO
Above is a screenshot from the 19th of December 2019.
For example, Infinio is a very interesting product. Infinio is using the VAIO for caching storage devices. Therefore, they are inserting a caching layer into the I/O path between the hypervisor and storage using the VMware Path Selection Policy. Infinio replaces the native policy with a custom PSP that is certified and supported by VMware. A virtual appliance is managing the caching layer and the kernel directly intercepts I/O and responds to cache misses. This enables Infinio to provide the lowest possible latency across all the operations. As a result, Infinio creates a global deduplicated cache, that offloads the storage array from read requests.
I’m assuming, that there will be a lot more in the future. I am especially excited about the CDP feature of Veeam, which is also based on the VAIO framework. Anthony Spiteri did a great presentation at Tech Field Day 20 regarding the CDP feature.
Also check out the blog post of Matt Crape. He explains what the CDP feature of Veeam “brings to the table” and how to it will look like ! I can only recommend this !
The Veeam CDP feature is the feature you want if you are considering synchronous replication with a RPO as minimal as of seconds ! Therefore, Veeam is using a continously running job which uses the VAIO to replicate the data from one host to the other. Really cool feature !
Other links and blog posts regarding VAIO
Here are some more links regarding the vSphere API for I/O filtering. I definetely recommend those!
- https://storagehub.vmware.com/t/vsphere-storage/vmware-vsphere-apis-for-i-o-filtering-vaio/
- https://code.vmware.com/programs/vsphere-apis-for-io-filtering
- https://blogs.vmware.com/virtualblocks/2015/02/05/vsphere-apis-for-io-filtering/
- https://storagehub.vmware.com/t/vsphere-storage/vmware-vsphere-apis-for-i-o-filtering-vaio/
- http://www.yellow-bricks.com/2017/10/13/new-white-paper-available-vsphere-apis-io-filtering-vaio/
- https://www.starwindsoftware.com/blog/vmware-vsphere-apis-for-io-filtering-vaio
Summary
As you can see, there are many many possibilities with the vSphere API for I/O filtering. I’m really looking forward to see more in the field and of course to try more of them. As always, thanks for reading and have a nice day !