Archive: Posts

VMware’s vFlash Read Cache (VFRC) versus Virtunet’s Read+Write Caching

Here are the three biggest differences.

  1. We cache reads and writes, VMware’s VFRC caches only reads. Caching writes improves the performance of not only writes, but also of reads, and even in a read dominated workload.1

  2. We require no ongoing administration. Caching in our case is fully automated. All Vmware features are seamlessly supported. Versus VFRC that requires administrator intervention when doing vmotion, for creating a new VM, for maintenance mode, for VM restore from backup, VFRC requires application block size assignment, requires SSD capacity assignment per vdisk. Many other tasks require admin oversight as well.

  3. We provide easy to understand VM to appliance level metrics for read/write throughput, IOPS, and latencies, with associated alerting to forewarn of failure events. Monitoring vendors charge more for just this set of features than what we charge for the combined functionality of improving performance + storage IO path monitoring. VFRC doesn’t provide any of this.

Below is a longer list of differences, cross-referenced with VMware authored content:



Virtunet VirtuCache

Caching Reads and/or Writes

Caches only reads.1

Caches both reads and writes.1

Administrator Overhead

Requires manually carving out and attaching SSD capacity to each VM disk. Also requires Admin to know block sizes of all applications and configure those on a per VM disk basis. How is the Administrator supposed to know how much SSD capacity to assign to each VM? Also, figuring out application block size for every app is onerous, and requires another 3rd party storage utility.2

SSD needs to be assigned at the host level only once. VirtuCache automatically understands application block size and dynamically allocates cache media per VM. No ongoing admin overhead.

Support for in host SSD or in-host RAM

Supports only SSD.2

Supports SSD, RAM or a combination of the two. If both RAM and SSD are used for caching on the same host, then RAM acts as Tier-1 and SSD as Tier-2.

What happens when SSD fails?

The VM fails since all storage IO from the VM fails.3

Storage IO does not fail, though VMs go back to being as slow as they were before VirtuCache was deployed.

What happens when a VMware host fails and VMware High Availability kicks in?

VMs with VFRC will restart on other hosts only if other hosts in the cluster have spare SSD capacity to honor VFRC SSD reservations of VMs that were on the failed host.4

VMware HA and DRS are seamlessly and automatically supported, without any restrictions. VMs will restart on other hosts regardless of any VirtuCache and SSD/RAM configuration.


When you manually vMotion a VM, you need to specify if you want to move the cache with the VM or invalidate it before you vMotion. If you decide to move the cache, you need spare SSD capacity on the target host to honor SSD reservation of the incoming VM. Also vMotion will take more time to complete, since cache moves with the VM all at once.5

vMotion is seamlessly and automatically supported, without any restrictions. Cache is moved with the VM slowly, as and when data is requested by the applications running in the VM. This ensures that vMotion speed is not affected, and it also ensures that reads and writes are continuously served from local or remote cache.

Support for VDI

VFRC will not work with XenDesktop or Horizon View.6

VDI with both XenDesktop and Horizon View are big use cases for us.

Caching misaligned blocks

This is the most important reason why you might not see improved storage performance. VFRC only caches blocks that are aligned to 4KB boundary. Most storage IO in Windows and Linux Guest OSes is not aligned.7

VirtuCache caches all blocks regardless of whether they are aligned or not.

Need to specify block size

You need to specify block size for each VM that you want to accelerate. This is the block size that the application running within that VM issues IO requests in. Assigning a different block size results in degraded storage performance. Additional effort and another storage utility are required to find out the block size for each VM application and then assigning it to each VMDK.8,9

VirtuCache automatically figures out the block size for all the applications running in VMs and caches blocks in the same size that the IO requests are issued in, even when the application block size might vary wildly (for example in databases). There is no need to manually define block size in VirtuCache.

ESXi editions supported

VFRC is available in Enterprise Plus edition of ESXi only.

VirtuCache is supported on all ESXi editions.

1 VFRC is Write-Through software. VirtuCache is Write-Back caching software. Write-Through Caching accelerates only reads. Write-Back caching accelerates both reads and writes. VFRC is not the only read caching software. There are other vendors as well like Infinio, Atlantis Computing, and Datrium. The main arguments from these vendors for why read caching suffices is that most traditional IT workloads are read dominated, and secondly they contend that by only caching reads, the storage appliance is freed up to better service writes. Both these statements are true, but they are not strong enough arguments to not cache writes. In fact not caching writes also slows down reads. Here is the reason. In all real world applications, reads and writes are interspersed on the same thread. Since these software do not cache writes, pending writes in the queue will slow down the read requests behind them that are on the same thread. So even if these reads by themselves could be accelerated by read caching software, because reads and writes are interspersed on the same thread the reads too are slowed down. Now keep in mind that if you run a synthetic testing tool like IOmeter you can configure reads and writes to be on separate threads, which will result in reads being accelerated independent of writes, but this is not a real life use case.

Secondly, it so happens that applications that are write intensive are also those that are of the highest value to the customer, as is the case with transaction processing, ERP, healthcare EMR, order processing, and such other applications. For instance, entering purchase orders (write intensive job) is possibly a higher value operation than running a report on historical purchase orders (read intensive job).

Hence both reads and writes need to be accelerated.


3 Search for term ‘Flash Read Cache is faulty or inaccessible’ on this link



6 Search for term ‘Horizon 7 does not support vSphere Flash Read Cache’ on this link

7 Search for term ‘Flash Read Cache filters out misaligned blocks’ in the release notes link below. The release note is for 5.5, however this aspect of the architecture hasn’t changed in subsequent releases, as can be proved by running IOmeter with misaligned blocks. Also this note from VMware incorrectly states that blocks are aligned to 4KB boundaries in newer versions of Windows and Linux. They are not, as can be easily cross referenced through various web articles on this topic.

8 Search for term ‘This should be made to be the same size as the most commonly used block of the application running inside the Guest OS.’ on this link

9 Search for term ‘Setting the correct block size’ on the below link. Even though this WP is for 5.5, this is still valid in later ESXi releases. There have been no more VFRC White Paper updates since 5.5.