By George Crump, CMO, VergeIO
Ten years ago, almost every virtualization architect answered that question with a no, and the reason had a name. The I/O blender took the orderly reads and writes of dozens of VMs and mixed them into a random stream at the shared datastore. Hard drives handle sequential work well and random work poorly, so a datastore built on spinning disk slowed down as VM density climbed. Flash fixed the blender by making random I/O cheap, and a decade of falling flash prices made all-flash the default for every new cluster.
Flash Pricing Reopened the Question
Flash and memory prices reversed direction in 2026, climbing 70 to 95 percent through the first half of the year as AI buildouts absorbed supply. Street prices on September 28 put a 15.36 TB enterprise NVMe SSD at about $706 per terabyte and a 24 TB hard drive at about $56. That twelve-to-one gap applies to every terabyte a cluster adds at its next refresh, and it turns the old question around to which VMs need flash at all.
Most of a Virtual Environment Is Waiting
Open the performance history for any production cluster and sort the VMs by 30-day IOPS. A short list at the top does most of the work, usually database servers, a few application servers, and VDI during the morning login storm. Below them sits a long tail of VMs that consume capacity and very little I/O. Templates and ISO libraries, powered-off VMs kept for compliance, file servers, log retention, and dev and test copies fill the rest of the datastore.
In most clusters, the tail holds far more capacity than the active list, and it sits on flash for lack of anywhere else to put it. Running a virtual environment on hard drives means running that tail on hard drives, with the active VMs on flash in the same cluster. The engineering question is whether the platform can keep the blender away from the disks. Dave Vincent and I will walk through this audit live on October 7 in How to use HCI and Hard Drives to Fight Data Center Inflation.
What It Takes to Tame the I/O Blender
Four design requirements decide whether hard drives work in a modern virtual environment. Each one moves random I/O away from the platters or gives the IT team a fast way to correct a placement call.
Metadata Has to Live on Flash
Every read on a deduplicated, distributed storage system starts with a lookup that maps a VM’s block to its location. A lookup that touches a spinning disk adds a seek before the data read begins, and the blender multiplies that penalty across every VM. A platform that runs VMs on hard drives needs its metadata on a dedicated flash tier, so block lookups run at flash speed even for disk-stored data.
The Cache Has to Sit in the Host
A cache inside an external array answers a read only after the request crosses the storage network. A platform that runs storage in the same code base as the hypervisor can cache in RAM on the server running the VM, where a hit costs memory latency. Deduplication helps too, leaving fewer unique blocks competing for that cache.
Writes Have to Reach the Disk in Order
The blender does its worst damage on writes, where dozens of VMs interleave small updates into one scattered stream. The storage layer needs to reorder and group those writes into sequential runs before they reach the platter, turning the mixed stream back into the access pattern hard drives handle best.
Placement Has to Be a Per-VM Decision
Automated tiering algorithms make placement decisions for the IT team and react to change after users notice it. The IT team already knows which VMs are busy and when, so the platform should let it set placement for each VM drive and move a running VM between flash and hard drives on command, with no maintenance window.
The speed of that move is the most critical requirement on this list. A live move between tiers that finishes in seconds makes every placement call reversible, giving the IT team room to be aggressive. It can push the whole long tail to hard drives in the first week instead of moving a few VMs at a time and waiting a quarter to judge the results. If users of a file server or an application VM start to complain, a few seconds and one command put that VM back on flash. A move that takes hours or needs a maintenance window forces the team to play it safe, and playing it safe leaves capacity on flash that belongs on disk.
Large Drives Need a Recovery Plan
A 24 TB drive raises a fair question about rebuild exposure. Frequent snapshots in the same system keep recent recovery points for every VM on the hard-drive tier. A repair path that pulls missing or corrupted blocks from a second system covers the failures that exceed the cluster’s redundancy.
So, Can You?
For most of the environment, yes, on a platform that meets these four requirements. Random-I/O databases with working sets larger than memory stay on flash with their transaction logs and tempdb, and the 30-day IOPS report shows which VMs to move first. A cluster that runs its active VMs on flash and its long tail on 24 TB hard drives buys most of its capacity at $56 per terabyte instead of $706.
The Five-Year Math
Running flash and hard drives side by side takes some work and some planning up front. The IT team pulls the 30-day IOPS report, decides which VMs belong on each tier, and schedules the first round of moves. With software that live-migrates a running VM between tiers in seconds, that planning is a one-time exercise, and every later adjustment is a quick correction.
The payoff is large. Take a cluster with 100 TB of VM data on flash, growing 25 percent a year. In five years it reaches about 305 TB, and staying all-flash means buying roughly 205 TB of new flash, about $145,000 in raw media at today’s $706 per terabyte, before redundancy copies.
Assume 80 percent of that data is long tail and move it to hard drives. The 20 TB of active VMs grows to about 61 TB over the same five years, which fits in the flash the cluster already owns. The long tail grows to about 244 TB on hard drives at $56 per terabyte, roughly $13,700. The cluster delays its next flash purchase by five years and keeps about $131,000 in the budget, before counting what five more years of flash price increases add to the all-flash bill.
How VergeOS Meets Those Demands
VergeIO built VergeOS to meet each of these requirements in one code base that runs virtualization, storage, and networking together. Its vSAN keeps metadata on a dedicated NVMe tier and caches data in RAM on the VM’s host server. VergeOS reorders incoming writes into sequential runs before they reach the platter, and global inline deduplication runs across every tier.
Administrators set a preferred tier for each VM drive and move running VMs between flash and hard drives on command. VergeIO’s Technical Solutions Strategist, Dave Vincent, moved a live SQL workload from NVMe to spinning disk, and commit latency stayed under a millisecond on both tiers.
Hourly snapshots and ioGuardian, which pulls missing blocks from a synchronized remote VergeOS system, answer the rebuild question. VergeOS licenses per server, so the money saved on media stays in the budget instead of feeding a capacity meter.
Dave and I will show it live on Wednesday, October 7, at 2:00 PM ET, moving a running VM from flash to hard drives and back. Register for How to use HCI and Hard Drives to Fight Data Center Inflation.
