Storage management and utilization is an important function of the hypervisor. Without management and utilization of storage, virtualization would have gone nowhere fast.
Management of storage infrastructure can be a resource-intensive task. The hypervisor is responsible for performing most storage functions: creation of files, reading and writing files, processing SCSI commands, file copy, etc. Depending on the virtual workload, this can consume significant CPU and memory resources on the host, resulting in fewer resources available for the guest VM.
Consider the creation of a thick 100GB disk. The thick disk is created in full capacity on the storage subsystem — all 100GB of 0s. Those 0s come from the hypervisor, traverse the storage fabric or network (for iSCSI, NFS and FCoE), and is written to the storage subsystem. Depending on fabric or network conditions and configuration, this can take significant time.
Another example involves a file copy. The hypervisor reads the file and sends the same bytes back over the fabric or network to the storage subsystem (again). This imposes a double file-size IO hit on the environment as the hypervisor is doing all the work.
As virtualization initiatives took off, it became apparent that the load focused on storage management was just too high. Arrays are highly specialized devices that do one thing really well: storage. What if the hypervisor did not have to do all that work? Oh, what a world that would be. Offloading storage functions to the storage subsystem would reduce the load on the hypervisor and place the work on a device designed to handle such requests.
The need was identified, and with the introduction of VMware vSphere 4.1, vStorage APIs for Array Integration (VAAI) technology was introduced. Since then, we have seen inclusion of VAAI functions in more and more storage subsystems from various storage vendors in the marketplace. However, storage offloading is not unique to VMware products. Microsoft introduced support for offloaded data transfer (ODX) functionality in Hyper-V v3.0 (available with Windows Server 2012). Storage vendors are adapting ODX functions, and some functionality should be available with Windows Server 2012 GA.
The following functions are now being offloaded to the storage subsystems and away from the hypervisor:
Storage offloading improves with every hypervisor iteration; support for NAS (file-based data stores), snapshot functionality offloading, and even more functions. With the new focus on NAS storage from hypervisor providers, storage offloading is making NAS on-par, if not more feature-rich than block storage:
While the functionality is valuable, perhaps one the most impressive functions involves enabling the functionality. Storage offload functionality for vSphere and Hyper-V is enabled by connecting the hypervisor to the storage subsystem. No check boxes, no configuration files, or anything like that. When the storage is connected to the hypervisor, the hypervisor negotiates available functionality. The hypervisor "asks" the storage subsystem if it supports the offload functions. If the subsystem supports the functions, they are enabled automatically and the virtualization environment can take advantage of it. In the event the subsystem does not support the functionality, a subsystem code update may add it.
The hypervisor still needs to perform some storage functions. But by offloading some functions to the array, hypervisor resources are significantly less stressed and performance is increased. Talk about a win/win for the virtualization environment.
Unique control with VM-level actions for infrastructure functions including snapshots, replication and QoS make protection and performance certain in production, and accelerate test and development cycles.