Archive: Posts

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

VMware will discontinue VFRC starting in ESXi 7.0 to be released in Q4 2019. 0

Despite the end-of-life announcement for VFRC, if you still want to review the differences between VFRC and VirtuCache, below are the three most important ones.

  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.1

  2. We require no ongoing administration. Caching in our case is fully automated, and 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, requires knowledge of application block size, requires SSD capacity assignment per vdisk. Many other tasks require admin oversight as well.

  3. We provide easy to understand VM, cache, network, and storage appliance level metrics for throughput, IOPS, and latencies, and alerting to forewarn of failure events. VFRC doesn’t.

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



Virtunet VirtuCache

Caches Reads / Writes

Caches only reads.1

Caches both reads and writes.

Support for in host SSD or RAM

Can cache to only SSD.2

Can cache to SSD, RAM or a combination of the two.

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. 2

SSD/RAM needs to be assigned to VirtuCache only once. VirtuCache automatically understands application block size and dynamically allocates cache capacity per VM. No ongoing admin overhead.

What happens when SSD fails?

VMs stop working since all storage operations from VMs fail.3

VMs continue to work, though VMs go back to being as slow as they were before VirtuCache was deployed.

What happens when a host fails and HA 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.


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 only.

VirtuCache is supported on all ESXi editions.

0 – Announcement from VMWare about deprecating VFRC in vSphere 7.0 is here

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, Jetstream Software, and Datrium, who cache only reads. 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 though true, 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. As a simple example, 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.

2 – Search for ‘host-resident flash devices as a cache’

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

4 –

5 –

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.