George Crump

by

For Immediate Release
ANN ARBOR, MICH. June 2, 2026

VergeIO, the developer of VergeOS, the private cloud operating system, today announced that Kit Colbert, former Chief Technology Officer of VMware and architect of its multi-cloud strategy, has invested in the company and joined its Board of Directors. VergeOS is the infrastructure software for a VMware exit today and for the container and AI workloads that come next.

Two Decades Setting VMware’s Technical Direction

Kit Colbert

Kit Colbert

Member, VergeIO Board of Directors

Colbert spent two decades at VMware. He joined in 2003 as technical lead for vMotion and Storage vMotion, then ran the Cloud-Native Apps business unit that became Tanzu and the Cloud Platform business unit. VMware named him Chief Technology Officer in September 2021, leading 2,400 engineers until Broadcom’s 2023 acquisition.

One Codebase, Not Layers Across Separate Modules

VergeOS is a private cloud operating system, or PCOS. A traditional virtualization stack runs a hypervisor from one vendor, a storage controller from a second, a software-defined network from a third, and a management plane from a fourth. Each layer carries its own license, update cadence, and compatibility matrix. VergeOS replaces all four with a single codebase in which virtualization, storage, networking, and tenancy are native functions. PCOS is the architecture for the next decade of private infrastructure ready for containers and AI, not another hypervisor swap.

Competitors

Integration behind a GUI

Separate software products from separate vendors, stitched together by one management interface. Each layer carries its own license, update cadence, and compatibility matrix.

→

VergeOS

Integration in the code itself

Virtualization, storage, networking, and tenancy run as native functions of one operating system. The architecture supports a VMware exit and lays the foundation for containers and AI.

Twenty years inside VMware taught me that the winner in private infrastructure is a tightly integrated product across compute, storage, networking, and management. VergeIO built a private cloud operating system from the ground up, applying everything the industry has learned over the years. The product is production grade, and its compact architecture runs from the data center to the edge, spanning traditional workloads to the latest container-based and AI applications.

Kit Colbert

Kit Colbert

Member, VergeIO Board of Directors

Kit helped define the modern virtualization era. His seat on the board confirms what we have told customers for years. The way out of the hypervisor tax is not a cheaper hypervisor, it is a Private Cloud Operating System.

Greg Campbell

Greg Campbell

Founder and CTO, VergeIO

Production at Many Mid-Market and Enterprise Customers, Including Topgolf

Customer Spotlight · Topgolf

Out of the entire VMware stack, across more than 100 venues, offices, and data centers.

100+

Venues, offices, and data centers running VergeOS

3

Products replaced: VMware, VxRail, Rubrik

1

Codebase managing the whole estate

“Broadcom’s acquisition of VMware put Topgolf in an awkward position, and an unsustainable cost trajectory. With the VMware platform and business model constantly pivoting, we chose to exit the entire VMware stack. VergeOS replaced VMware and Rubrik, and PowerEdge replaced VxRail across more than 100 venues, offices and data centers. Kit Colbert joining the VergeIO board further solidifies that Topgolf made the right decision to move forward with VergeIO. We picked the right architecture, and the right partner.”

Scott Forehand
Scott Forehand Manager, Global Infrastructure, Topgolf

Live Webinar · Jun 11, 2026

Beyond the Hypervisor Swap

Kit Colbert joins Greg Campbell on the broadcast.
Thursday, June 11 · 1:00 p.m. Eastern · 45 minutes

Register for the Webinar →

Architecture Datasheet

VergeOS 2026 Architecture Overview

A technical deep-dive into the architecture behind the announcement. How VergeOS unifies virtualization, storage, networking, and tenancy in a single codebase.

Read the Datasheet →

About VergeIO

VergeIO develops VergeOS, the private cloud operating system that runs virtualization, storage, networking, and tenancy as functions of one operating system, written from a single code base. Customers deploy VergeOS to replace legacy virtualization stacks, eliminate compounding licensing layers, and reduce the operational footprint of private infrastructure. The company is headquartered in Ann Arbor, Michigan and serves enterprise, government, and service-provider customers worldwide. For more information, visit verge.io.

Media Contact Judy Smith JPR Communications for VergeIO [email protected] · 818-522-9673

#   #   #

Filed Under: Press Release

by

Cascading drive failure is the storage scenario every IT operator wants to never live through. Picture this. A six-node hyperconverged environment running production workloads. A drive fails on one of the nodes. The rebuild starts. Mid-rebuild, a second drive fails. More rebuilds spin up. A third drive fails. Then a fourth. The cluster has now exceeded the tolerance of RF2, the standard two-copy synchronous replication model in VergeOS. It has also exceeded RF3 if you happened to be running it. On most platforms, this cascading drive failure has just ended the cluster, the VMs are stopped, and recovery is a tape-restore conversation.

Key Takeaways
  • Cascading drive failure is the dominant concurrent-failure pattern, not the exception. One drive fails, rebuilds kick off, surviving drives wear faster under the rebuild load, and the next failure arrives before the cluster has recovered from the first.
  • Hyperconverged and ultraconverged architectures raise the stakes on cascading drive failure. Compute and storage share nodes, so a node loss takes both layers down at once.
  • RF2 and RF3 absorb the first one or two losses. ioGuardian streams missing blocks inline beyond that. Live VM migration moves workloads off degraded nodes in parallel. Users see no interruption.

VergeOS handles a cascading drive failure differently. As each drive fails and the failure surface widens, ioGuardian streams the missing blocks inline to the running VMs as the VMs request them. The platform also live-migrates the affected VMs off the most degraded nodes to surviving ones. By the time three or four servers have effectively crashed, the users are still accessing their applications and data. They never see the cascade happen.

The scenario above is a thought experiment built from common failure patterns. Same-batch drives age together. Rebuild storms stress surviving drives and accelerate the next failure. Correlated wear pushes the cascade forward. The pattern is not exotic, it is statistically expected on used media and possible on new media. The architecture that makes the outcome survivable is shipping today. Once you understand how it works, the case for using refurbished media on the right platform becomes a procurement decision rather than a courage test.

4 of 6Servers effectively crashed in the cascading drive failure scenario
0User-noticed service interruptions during the cascade
40–60%Refurbished enterprise SSD discount versus new pricing

Why Cascading Drive Failure Happens

Cascading drive failure is not exotic. Every hyperscaler operating at scale has documented this pattern in their published field data on flash drives. When one SSD fails inside a same-batch group, the probability that two or three more in that group fail within days is materially elevated. The drives shipped together, ran the same workload, and reached the same point on their wear curves at the same time. Rebuilds make it worse, not better, since the surviving drives carry the rebuild load and accelerate their own wear. This is true of new media. It is more true of refurbished media, where the wear distribution is tighter than a fresh procurement order.

Cascading drive failure from correlated wear curves accelerated by rebuild storms

The architectural answer is the same regardless of failure cause. Consider three causes: a same-batch firmware bug, correlated end-of-life on a single procurement order, and rebuild stress that propagates the next failure. All three look identical to the storage layer. The platform either absorbs the cascading drive failure without service interruption or it does not. Refurbished drives raise the prior probability of a cascade. They do not change the response model.

Converged architectures raise the stakes further. Hyperconverged and ultraconverged platforms run compute and storage on the same physical nodes, so the loss of a node takes both layers down at once. A cluster experiencing cascading drive failure across the same week is also watching three VM hosts wobble. The architectural answer has to absorb both halves of that failure surface, not just the storage half. Refurbished media on a converged platform without inline recovery compounds the problem in two dimensions at once. The protection model has to cover storage and compute simultaneously or it does not cover anything that matters.

How VergeOS Absorbs Cascading Drive Failure

VergeOS uses synchronous replication rather than erasure coding. RF2 maintains two copies of every block on different drives across different nodes. RF3 maintains three. A write only completes once the second or third copy acknowledges. The platform survives the loss of any drive, and at RF3 the loss of any two, with no parity calculation, no rebuild storm, and no degraded-mode performance penalty. The choice between RF2 and RF3 is a capacity question, not an architecture question. The replication model is the same.

VergeOS architecture for cascading drive failure: RF2 and RF3 synchronous replication, ioGuardian inline recovery, and live VM migration

ioGuardian extends the protection model beyond the replication tolerance. It is a separate node holding a complete asynchronous copy of the cluster, updated on every system snapshot. When a failure exceeds the configured RF level, ioGuardian does not attempt to rebuild the failed drives. It steps inline and delivers the missing blocks to the running VMs as the VMs request them. Recovery is not a process that runs in the background. Recovery is the data path itself.

The compute layer responds in parallel. As nodes degrade past the threshold where they can serve workloads reliably, VergeOS live-migrates the affected VMs to surviving nodes. The VMs themselves see no interruption. The combination of inline storage recovery plus continuous VM migration is what lets the cluster absorb the loss of multiple servers without service impact, even when the cascading drive failure exceeds both RF2 and RF3 tolerances.

The Ultra Converged Infrastructure model adds another dimension to cascade resilience. VergeOS supports heterogeneous node types in the same cluster: storage-heavy nodes packed with drives, compute-heavy nodes loaded with CPU and RAM, and classic hyperconverged nodes that balance both. A cluster running this mix spreads the cascade surface across different physical roles. When a same-batch cascade hits the storage-heavy nodes, the compute-heavy nodes keep running VMs uninterrupted. When a compute node fails, the storage nodes keep serving data. The same UCI flexibility that lets you scale compute and storage independently during normal operations also makes it structurally harder to lose a cluster to a single concentrated failure.

Two design consequences follow. The first is performance: the surviving drives never carry a rebuild storm, writes incur no parity recalculation tax, and the failed state holds production-level latency when the ioGuardian target runs on flash. The second is hardware flexibility. The ioGuardian server runs on its own license and its own hardware, and it does not need to match the production cluster in CPU family, generation, or media type. Customers run AMD ioGuardian targets behind Intel production environments, repurpose retired servers as ioGuardian capacity, and place a second ioGuardian instance at a cloud service provider for site-level resilience.

Key Terms
Cascading Drive Failure
A drive failure pattern in which one failure triggers conditions (rebuild stress, correlated wear) that make subsequent failures more likely. Common on same-batch media, more pronounced on refurbished media.
RF2 / RF3
VergeOS’s two-copy and three-copy synchronous replication models. Every write completes only after the additional copies acknowledge. Survives loss of one or two drives with no rebuild storm and no degraded-state performance penalty.
ioGuardian
A separate node holding a complete asynchronous copy of the cluster, updated on every system snapshot. Streams missing blocks inline to running VMs when failures exceed the configured RF level. Eliminates the rebuild process as a recovery mechanism.
Live VM Migration
VergeOS’s mechanism for moving running VMs off degraded nodes to surviving ones without service interruption. Works in parallel with ioGuardian during a cascade so the compute layer keeps serving even as storage absorbs the failure.
UCI Node Types
VergeOS supports storage-heavy, compute-heavy, and balanced hyperconverged nodes in the same cluster. Spreading workloads across heterogeneous node types makes the cluster structurally more resilient to a single concentrated failure pattern.

Telemetry Prevents Failure Before It Starts

The cascading drive failure scenario makes the architecture vivid. It also makes the point in the wrong direction. The goal is not to absorb the failure event. The goal is to never reach it. VergeOS does both. The replication model, ioGuardian, and live migration handle the moment of failure. The telemetry layer makes sure the moment rarely arrives.

VergeOS SMART telemetry catching the early signature of cascading drive failure before the second drive fails

The platform tracks seven SMART attributes on every drive in real time: total writes, power-on hours, reallocated sectors, wear leveling, ECC errors, end-to-end errors, and temperature. The data flows through a subscription model. A subscription is a rule that fires an alert on a defined condition.

The obvious subscription watches a wear-level threshold, and most customers set the first alert at seventy percent. The more useful subscription watches rate of change. An alert that fires when a drive’s wear level jumps ten points within ten days catches drives at risk of failure days or weeks ahead of any fixed threshold. The same rate-of-change subscription catches the early signature of a cascading drive failure before the second drive in a batch fails.

This capability turns refurbished procurement into a verifiable transaction. A reputable supplier delivers drives with a stated wear level and chain-of-custody record. The buyer installs them, runs a stress workload for twenty-four hours, and lets the platform watch. A drive that arrives at ninety percent wear when the supplier represented twenty percent gets flagged before any production data lands on it. The drive goes back, the supplier gets the call, and the framework has been validated by the platform itself. Refurbished media stops being a faith-based purchase and becomes a quantifiable one.

VergeIO On-Demand Webinar
The Refurbished SSD Framework

George Crump and Aaron Richman walk through the secondary-market case, the procurement framework, and the architectural model that makes refurbished enterprise drives a procurement decision rather than a courage test.

Watch the Recording →

This is the two-sided coverage VergeOS delivers. The telemetry layer gives you everything you need to try to prevent the cascading drive failure from happening in the first place, through real-time SMART exposure, rate-of-change subscriptions, and verifiable supplier representations. If the cascade still arrives despite the early-warning systems, the architecture has the resiliency to withstand it, through synchronous replication, inline recovery, live migration, and heterogeneous UCI node distribution that keeps user workloads running through the failure. Both halves of the coverage matter. Most platforms leave the second half to you.

What This Means for Refurbished Procurement

The conventional argument against refurbished enterprise SSDs is elevated failure risk. The argument is correct. The platform decision is what changes the consequence of that risk. New media on a naive architecture faces a different set of stakes than refurbished media on a platform built to absorb cascading drive failure. Erasure coding controls protection at the cost of double-digit-hour rebuilds and a real chance that the next drive failure during rebuild ends the cluster. Synchronous replication, inline recovery, and live migration hold the cluster up regardless of failure cause or media age.

Stack the cost math on top of that architectural reality and the picture changes. Refurbished enterprise SSDs run forty to sixty percent below new pricing in the current market, a market whose underlying dynamics have been characterized as memory and flash prices that are not coming down. The reputable supply chain runs through R2v3-certified vendors who serialize inventory, perform NIST 800-88 sanitization, and stand behind their representations. Drives typically carry eighty to ninety-five percent of rated write life remaining. A buyer who runs SMART verification on intake, sets the rate-of-change subscription, and deploys behind RF2 with ioGuardian has answered the failure-risk question in three independent ways before any customer data lands.

Naive Architecture vs VergeOS for Cascading Drive Failure

 Naive ArchitectureVergeOS
Protection modelErasure coding with parity calculation overheadSynchronous replication with no parity overhead
Recovery on failure within toleranceMulti-hour rebuild storm on surviving drivesContinuous serving with no rebuild
Recovery on failure beyond toleranceRecover from backup, days of downtimeioGuardian inline streaming, no service interruption
Compute response during cascadeVMs stop on affected nodes, manual restart requiredLive migration moves VMs to surviving nodes automatically
Failure surface across node typesSymmetric nodes concentrate the cascadeUCI heterogeneous nodes spread the cascade across roles
Refurbished SSD verificationManual intake test, no continuous monitoringSeven SMART attributes monitored real-time, rate-of-change alerts

The cascade is what makes the scenario memorable. The architecture absorbs cascading drive failure for the same reason it absorbs a same-batch firmware bug, a bad refurbished batch, or a single drive that happened to fail on a busy day. The failure cause is not the variable. The platform is. A companion post, How VergeOS Makes Refurbished SSDs Safe to Run, catalogs the platform’s response to each of the four supplier-side refurb risks.

Frequently Asked Questions
What is ioGuardian and how is it different from a backup system?
ioGuardian is a VergeOS data-protection node that holds a complete asynchronous copy of the production cluster, updated on every system snapshot. When a failure exceeds the configured RF protection level, ioGuardian streams the missing blocks inline to running VMs as the VMs request them. The VMs never stop serving. ioGuardian replaces rebuild as the recovery mechanism for failures beyond replication tolerance. It does not replace backup. It eliminates rebuild as the primary recovery path.
Can VergeOS handle a cascading drive failure that exceeds RF2 and RF3?
Yes. RF2 absorbs the first drive loss, RF3 absorbs the first two. When a cascading drive failure exceeds the configured RF level, ioGuardian streams missing blocks inline to running VMs while live migration moves workloads off the most degraded nodes to surviving ones. The UCI node-type flexibility spreads the failure surface across compute-heavy, storage-heavy, and balanced nodes, so the cascade rarely takes the whole cluster. The cluster keeps serving even when concurrent failures take out a majority of nodes.
Why is cascading drive failure protection more critical on HCI and UCI than on split architectures?
Hyperconverged and ultraconverged platforms run compute and storage on the same physical nodes. The loss of a node takes both layers down at once. A cluster experiencing cascading drive failure is also watching three or four VM hosts wobble. The architectural answer has to absorb both halves of that failure surface, not just the storage half. ioGuardian and live migration were designed for that combined blast radius.
How does VergeOS verify that a refurbished drive’s stated wear level is accurate?
VergeOS exposes seven SMART attributes per drive in real time and lets administrators define subscription rules. A wear-level threshold subscription alerts when any drive crosses a defined value. A rate-of-change subscription alerts when wear increases faster than expected, catching drives that arrived in worse condition than the supplier represented. Both subscriptions fire before production data is at risk.
Does ioGuardian require the same hardware as the production cluster?
No. The ioGuardian server runs on its own license and its own hardware. It does not need to match the production cluster in CPU family, generation, or storage media. Customers run AMD ioGuardian targets behind Intel production environments, repurpose retired servers as ioGuardian capacity, and place a second ioGuardian instance at a cloud service provider for site-level resilience.
What happens if a same-batch firmware bug takes out multiple drives at once?
The architectural response is the same as cascading drive failure from any other cause. RF2 or RF3 absorbs the first one to two failures within tolerance. ioGuardian absorbs the rest by streaming inline, and live migration moves VMs off the affected nodes. The cluster keeps serving. The corrective action with the manufacturer or supplier happens on a normal-business-hours schedule rather than a 3 AM emergency.

Filed Under: Storage Tagged With: , , , , , , ,

by

VergeIO Principal Engineer David Zarzycki provisions a fresh Kubernetes cluster from inside the Rancher UI, on top of VergeOS, in under three minutes. Recorded on a two-core, four-GB lab node — click to running, end to end. The flow exercises the VergeOS UI extension, the Rancher node driver, and the three upstream Helm charts that wire in from the verge-io Cluster Repository on the way up. No forked Kubernetes, no proprietary CRDs, no second console.

Filed Under: Videos

by

Live webinars produce one piece of data no white paper captures cleanly. That data is the audience poll. On May 20, the first poll on Kubernetes Without the VMware Tax asked attendees how their team runs Kubernetes in production today. Roughly half answered the same way. Kubernetes is still in the evaluation column, not yet running in production.

May 20 webinar poll results showing roughly half of attendees still evaluating Kubernetes

The trade press paints a picture of every enterprise running Kubernetes for years, and the poll told a different story. For a team in that evaluating column, the exit from VMware has become the new priority. The real question is whether the team can evaluate Kubernetes and exit VMware at the same time.

The argument is straightforward. The platform underneath the Kubernetes layer decides more of the long-run operations math than the distribution does. The full architectural case lives in Collapsing the Kubernetes Stack, the long-form companion paper to this post, and the dollar math gets walked separately in The Kubernetes VMware Exit Math, Explained. Pick the platform last, and the distribution choice locks in the storage layer, the snapshot policy, and the vendor count. Pick it first, and the distribution choice becomes a distribution choice.

Key Takeaways
  • Pick the platform first. Exiting VMware to a platform that understands containers answers the foundation question and the distribution question inside the same project.
  • Running Kubernetes on a hypervisor not designed for container workloads adds a translation tax in storage, networking, and lifecycle, and that tax compounds at every renewal.
  • VergeOS publishes three Helm charts from a single Cluster Repository on GitHub, ships persistent volumes natively from the same storage that runs the VMs, and presents both workload types through Rancher. One platform, one support contract, two workload types.

Does the environment need Kubernetes?

The hardest question for a team evaluating Kubernetes is not which distribution to pick. The hardest question is whether the environment needs Kubernetes at all. Plenty of environments need Kubernetes for the right reasons. Plenty of others do not, and the honest answer matters more than the marketing.

The honest answer in the room on May 20 came from David Zarzycki, the engineer who did most of the work on the VergeOS Kubernetes integration. His phrasing was the right one. Is your environment complex enough to warrant the complexity of running Kubernetes at all?

Kubernetes earns its keep when applications change frequently, when teams ship daily, when multi-tenancy is real, when GPU scheduling matters, and when developer self-service is a stated requirement. A two-tier ERP application with a six-month release cycle does not need Kubernetes. A microservices platform with twenty deploy events per day does. Most production environments have both kinds of workloads sitting side by side, and that mix is exactly why the foundation question matters more than the distribution question.

A clean example of a Kubernetes-shaped workload looks like a retail analytics platform that ingests several million transaction events per hour, runs a dozen microservices scaling independently against the event stream, and ships code multiple times a day with feature flags and blue-green rollouts. Storage demand spikes during peak hours. Compute demand spikes around marketing campaigns. The engineering team treats every service as independently deployable. That workload pattern is what Kubernetes was built for, and the platform underneath has to keep up with it. The two-tier ERP application sitting next to that platform does not need any of that machinery, and asking Kubernetes to run it is the wrong tool for the wrong job.

Key Terms
Foundational Platform
The compute, storage, and networking substrate underneath the Kubernetes cluster. A true foundational platform combines hypervisor, storage system, network fabric, and container orchestration on a single code base, with one management plane and one support contract for both VM and container workloads. The foundational platform sets the operational ceiling for everything running on top of it.
Kubernetes distribution
A packaged version of upstream Kubernetes with vendor support, lifecycle tools, and sometimes additional CRDs. Examples include Tanzu Kubernetes Grid, Red Hat OpenShift, SUSE Rancher Prime, and upstream RKE2 or K3s.
Cluster Repository
A registered Helm chart source that Rancher can pull from. VergeOS publishes a single Cluster Repository on the verge-io GitHub. One Rancher registration brings the node driver and pins the three platform charts (CSI, Cloud Controller, Cluster Autoscaler) to verified upstream versions.
Overlay storage
A separate storage system layered on top of the hypervisor storage to give Kubernetes pods persistent volumes. Longhorn, Portworx, OpenEBS, and Rook/Ceph are common examples. The deeper case for treating Kubernetes persistent storage as an architectural coordination problem sits in the analyst piece on StorageSwiss. Overlay storage is the classic indicator the underlying platform does not natively support container workloads.
Translation tax
The operational and architectural cost of bridging between a Kubernetes layer and a hypervisor layer not built together. Shows up as duplicate snapshot policies, separate networking control planes, two backup systems, and three support contracts.

The foundation question, not the distribution question

Kubernetes evaluations almost always start with the distribution shortlist. The standard candidates are Tanzu, OpenShift, Rancher Prime with RKE2 or K3s, and upstream Kubernetes on bare metal. Tanzu’s long goodbye makes that grading harder for any team still committed to vSphere. Each shortlist gets graded against developer experience, ecosystem depth, support contracts, and price. The platform underneath the cluster nodes is a separate conversation. The hypervisor, the storage layer, and the network fabric get graded last, if at all.

The dual mandate of running VMs and Kubernetes containers on a single integrated platform

That order is backward. The platform underneath decides how persistent volumes get carved, how cluster nodes scale, how snapshot and replication policies coordinate across VMs and pods, and how many vendor support contracts the operations team carries forever. The Kubernetes distribution determines which API the developer interacts with. Both matter, and the platform decides more.

The reason the order keeps getting reversed is that the distribution choice is louder. There are conferences for Tanzu and conferences for OpenShift. There is no conference for “the platform underneath.” Teams evaluating Kubernetes hear the loudest voices first and rank the platform later. The five-year math punishes that order.

The platform question reduces to a simple test. Count the support contracts the operations team will carry once the evaluation is over. Count the snapshot engines. Count the storage systems. Count the network control planes. Every number greater than one in that list is a translation tax line item. Every one of those line items comes from picking the distribution first and letting the distribution dictate the platform.

What changes when the platform underneath is integrated

VergeOS as a unified foundation for both VMs and Kubernetes containers

VergeOS treats VMs and Kubernetes containers as workloads on the same code base. The hypervisor, the storage layer, the network fabric, and the Kubernetes integration share one platform. Three Helm charts pulled from one Cluster Repository on the verge-io GitHub. A CSI driver provisions persistent volumes from VergeFS directly, with no overlay storage layer between the pod and the disk. A Cloud Controller Manager handles networking and node lifecycle events through the standard Kubernetes interface. A Cluster Autoscaler handles node-count management through the same upstream project every other distribution uses.

What that means in practice. Rancher remains the management plane the operations team already knows. The cluster object stays standard. The persistent volume comes off the same storage fabric the VMs use, with no Longhorn to license and no Portworx contract to manage. The Kubernetes distribution is whichever flavor Rancher provisions, usually RKE2 or K3s, both upstream. The platform underneath handles the rest, on the same code base it uses to run the VM side of the house. The Kubernetes Without the VMware Tax datasheet lays the architecture diagram and the deployment flow side by side for teams that want the one-page reference.

The typical vSphere Kubernetes stack vs an integrated platform

Capability Typical vSphere Kubernetes Stack VergeOS
Hypervisor licensing VCF subscription, per-core pricing Included in the platform
Kubernetes distribution Tanzu, OpenShift, or Rancher Prime, separate contract RKE2 or K3s via Rancher, no separate licensing
Persistent volumes (CSI) Vendor CSI driver, overlay storage often required (Longhorn, Portworx) Native VergeOS CSI driver, no overlay storage
Networking and load balancing Vendor CNI plus separate load-balancer contract Cloud Controller Manager via standard Kubernetes interface
Snapshot and replication Two policy engines, one for VMs, one for K8s One snapshot and replication engine, both workload types
Vendor support contracts Three or more One
Cluster create time (May 20 live demo) Variable, often 15 to 20 minutes Six minutes, on a lightweight lab system

Why Rancher?

VergeOS works with any Kubernetes distribution that runs on standard upstream nodes. The integration is upstream by design, three Helm charts and a node driver, no fork and no proprietary kernel extension. A team already running OpenShift or Tanzu can keep that distribution and put VergeOS underneath it.

A team that has not committed to a distribution yet should start with Rancher. The reasoning is practical. Rancher carries the lightest commercial weight of the major management planes, with no separate licensing layer attached to RKE2 or K3s. The node driver integration is the cleanest path to a working cluster on VergeOS. The cluster lifecycle, upgrade, and visibility story all sit in one console the operations team learns quickly. Standing up a first cluster on Rancher takes minutes, and the resulting cluster is upstream Kubernetes. No fork, no proprietary distribution to retrain against, and no vendor exit story to plan for later.

Production proof, named on the live call

Two customers got named on the May 20 webinar, and both are cleared for public use. NGAMING / Nesine in Turkey runs a regulated sports-betting platform on VergeOS, with over 180 Kubernetes nodes carrying live transaction workload. The same production validation appears in the VergeIO Kubernetes general availability announcement.

Production VergeOS Kubernetes deployments at NGAMING / Nesine and Topgolf

Their feedback in the rollout was that the engineering response cycle felt like having a software development shop on call, even across time zones. That kind of feedback is rare, and it came up for one reason. The engineers who wrote the VergeOS SDKs are the same engineers who wrote the Kubernetes integration. Same team, same code base, same release cadence.

Topgolf is the second name. Over a hundred VergeOS sites across the United States, replacing VMware. The reason Topgolf gave for choosing VergeOS was not the platform alone. It was the platform plus the partnership, agile enough to respond at scale and capable enough to run the full environment. Both customers are evidence that the integrated-platform argument scales from a 180-node Kubernetes cluster in Turkey to a hundred-site VMware replacement in the United States, on the same code base.

How to start evaluating Kubernetes the right way

The clean path for a team evaluating Kubernetes from a standing start looks like this. Stand up VergeOS as the platform. Register the verge-io Cluster Repository in Rancher. Provision a test cluster through the Rancher UI. Run workloads on it. Cluster creation took six minutes on the live demo, on a lightweight home-lab system with two cores and four gigabytes of RAM per node. Production environments run faster. The three Helm charts come from the same repository. The persistent volumes come from VergeOS storage. The Rancher cluster object behaves exactly the way it would on any other Rancher node driver.

Keep going on Kubernetes Without the VMware Tax

The webinar walks the live demo on real hardware. The white paper walks the full architectural argument.

Watch the on-demand webinar
Read the white paper

From there the distribution question becomes which flavor of upstream Kubernetes Rancher provisions for the team, with RKE2, K3s, or upstream Kubernetes as the practical options. The platform decision is already made. The vendor count is one. The migration question other teams are still working through does not show up at all. There is nothing to migrate from. The team that picks the platform first gets to keep the evaluation focused on the part that matters, which is whether Kubernetes fits the workload, not whether the storage layer fits the Kubernetes distribution.

The fastest way to validate the foundation argument against a specific environment is a 30-minute architecture overview with one of the engineers who built the integration. Aaron Richman, Field Evangelist at VergeIO and one of the presenters on the May 20 webinar, runs these sessions directly. The agenda is the team’s environment, the workloads under consideration, and the path from the current VMware footprint to a VergeOS deployment that handles VMs and Kubernetes on one platform. No slide deck. The session works against a real environment. Book a session and the conversation starts where the webinar left off.

Why this matters to a team still evaluating Kubernetes

The CloudBolt CII study and the most recent CNCF surveys both show the same pattern. Teams deploying Kubernetes on top of a hypervisor not designed for container workloads spend more on storage, more on vendor support, and more on operations than teams picking an integrated platform from the start.

The gap widens at every renewal. Most evaluations get the order wrong, and the reason is consistent. The distribution choice is louder, and the platform choice shapes the next five years.

The teams in the evaluating column during the May 20 webinar still have a chance to get this order right. The teams that have already moved are working through the migration version of the same question. The order matters more than the urgency.

Frequently Asked Questions
We are not running Kubernetes yet. Do we still need to think about a platform like VergeOS now?
Yes. The platform underneath the cluster decides storage, networking, snapshot policy, and vendor count. Picking the platform after the distribution locks in choices harder to reverse than the distribution decision itself.
Can VergeOS run alongside our existing VMware environment during evaluation?
Yes. VergeOS runs on standard x86 hardware and supports parallel deployment. Most evaluations stand up a VergeOS cluster on dedicated hardware, run the Kubernetes workload on it, and migrate VMs over on the team’s timeline.
Which Kubernetes distribution does VergeOS provision?
Rancher provisions the distribution. The default Rancher choices are RKE2 and K3s, both upstream Kubernetes. VergeOS does not fork or modify the distribution. The three platform Helm charts (CSI, Cloud Controller, Cluster Autoscaler) work with the upstream cluster.
Do we have to commit to Rancher to use VergeOS Kubernetes support?
Rancher is the supported management plane today. The Helm charts themselves are upstream and run on any Kubernetes cluster the operations team chooses to manage with kubectl. Rancher is the recommended path for three reasons. UI continuity for operations, node driver integration, and the full cluster lifecycle story in one place.
What happens to our existing VMs when we add Kubernetes workloads?
VMs and Kubernetes containers run on the same VergeOS code base. The same storage. The same networking. The same snapshot and replication policies. The operations team manages one platform, one console, one support contract.
How long does a real production cluster take to provision?
On the May 20 live demo, a three-node RKE2 cluster came up in six minutes on a lightweight home-lab system. Production environments with proper resource allocation typically come up faster. The time is dominated by Rancher provisioning the cluster runtime on the VMs, not by VergeOS provisioning the VMs themselves.

Next steps

The Collapsing the Kubernetes Stack white paper, the Kubernetes Without the VMware Tax datasheet, and the on-demand recording of the May 20 webinar all live in the Kubernetes Without the VMware Tax research center. The fastest way to validate the foundation argument is on your own hardware, with your own workloads. Take a Test Drive Today and provision a Kubernetes cluster through Rancher on VergeOS the same way David showed live.

Filed Under: Private Cloud Tagged With: , , , , , ,

by

See how VergeOS turns NVIDIA vGPU 20 deployment into a point-and-click operation, with pass-through, vGPU, and MIG partitions configured through the same interface IT teams already use for compute, storage, and networking.

Filed Under: Videos

by

Six weeks ago our team sat down with NVIDIA to walk through the vGPU 20 release and what it means in combination with VergeOS. The questions we expected before the webinar and the questions arriving now no longer match. That gap is the most interesting data point coming out of the last six weeks. If you missed it, you can watch it on-demand now or review the presentation. No registration is required for either.

vGPU 20 VergeOS deployment plan reviewed by an IT director

The audience that registered for the session was the audience we expected. IT directors, infrastructure architects, virtualization admins. The framing they brought was the framing the GPU virtualization market has carried for the last decade. The first question was whether the budget could absorb GPU-per-VM economics. The second was whether existing staff could run it. The third was whether deployment required rebuilding the data center.

Six weeks of follow-up conversations have replaced that framing with something narrower and more practical. Teams want to know where to deploy first. That shift is the entire point of the vGPU 20 plus VergeOS release, and it deserves a longer look at what changed in the platform to produce it.

Key Takeaways
  • vGPU 20 is the first NVIDIA release with engineered VergeOS support and bidirectional escalation between the two engineering teams.
  • RTX Pro 6000 Blackwell is the first data center GPU to combine universal MIG with vGPU in a single SKU, supporting up to four hardware-isolated slices and up to 48 VMs per card.
  • Pass-through, vGPU, and MIG run through one VergeOS form with no CLI required.
  • One driver upload produces the guest ISO automatically, which VergeOS attaches at VM boot.
  • Snapshot and replication carry the GPU device configuration with the VM, so DR inherits GPU state.
  • The trial license covers 128 seats for 90 days from the NVIDIA licensing portal.

The vGPU 20 and VergeOS Integration That Aged Well

The first thing the webinar covered was the integration story itself. NVIDIA released vGPU 20 with official VergeOS support as a host platform. The detail that matters is not the support statement. The detail is the engineering relationship behind it.

NVIDIA vGPU 20 driver stack integrated with the VergeOS host platform

NVIDIA and VergeIO now share dual-direction escalation paths. New driver features and new GPU classes move into VergeOS faster than they moved into the platforms that came before. Six weeks of feature requests have already run through that channel. The integration is not a logo on a slide. It is an active engineering relationship with named contacts on both sides.

That structural change is the part of the announcement that has aged the best in the field. Customers who picked VergeOS as a host two years ago for unrelated reasons now find themselves on the receiving end of features they did not pay for in their original evaluation.

RTX Pro 6000 Blackwell: The vGPU 20 Hardware Foundation

The RTX Pro 6000 Blackwell is the first data center GPU to combine universal MIG with vGPU in a single SKU. That one sentence is the entire technical story for vGPU 20 hardware. Universal MIG means the card partitions itself into up to four hardware-isolated slices, and each slice runs both compute and graphics workloads through vGPU. The arithmetic stops at 48 VMs on a single card, with hardware-allocated frame buffer and hardware-allocated compute.

RTX Pro 6000 Blackwell partitioned into MIG slices on VergeOS

The noisy neighbor argument that has haunted GPU virtualization for a decade no longer applies on this hardware. Latency-sensitive workloads, inference at the edge, and interactive design sessions finally have a deterministic GPU model. The frame buffer is reserved at the silicon layer. The compute slice is reserved at the silicon layer. Both allocations are guaranteed by the chip, not by the hypervisor scheduler. VergeOS surfaces these slices through the standard vGPU 20 configuration form, so the silicon-level isolation is available without specialist tools.

That last point matters more than the seat count. The teams asking sharper questions in the last three weeks are the teams that read the spec sheet, ran the math, and recognized that the underlying isolation model has changed. A hardware-reserved 1/4-slice on a single Blackwell card outperforms most full GPUs from two generations ago in determinism, which is the metric inference and interactive workloads care about.

Key Terms
MIG (Multi-Instance GPU)
Hardware partitioning that divides a single physical GPU into isolated slices, each with reserved frame buffer and compute. Allocation happens at the silicon layer rather than through software scheduling.
vGPU
NVIDIA’s software-driven sharing model that allows multiple VMs to share a physical GPU or a MIG slice through a guest driver.
Pass-through
Direct assignment of an entire physical GPU to a single VM with no sharing layer. The simplest model, used for workloads that need an entire card.
Heterogeneous Profiles
Running AI inference, knowledge-worker VDI, and CAD or visualization workloads on the same physical GPU at the same time, each with its own profile.
Frame Buffer
The GPU memory allocated to a workload. Hardware-reserved under MIG, software-allocated under classic vGPU.

vGPU 20 in VergeOS: Three Modes, One Form, No CLI

The vGPU 20 configuration model in VergeOS landed hardest with the audience. Pass-through, vGPU, and MIG all run through the same VergeOS form. The form replaces the CLI, the vendor-specific manager, and the second tool that other platforms ship with. The admin who configures a pass-through GPU configures a MIG slice the same way. GPU virtualization takes three forms with different tradeoffs in flexibility and isolation, and a single configuration model removes the operational tax of running all three.

VergeOS administrative form showing pass-through, vGPU, and MIG configuration on a single screen

Paul Hodges ran the live MIG configuration demo during the session. The reaction in the chat was the reaction we have been hearing in every follow-up call. The point-and-click form removed the specialist requirement from the buying decision.

That observation has held. The teams moving fastest in the last six weeks are the teams that opened those calls with a sentence we used to hear in every GPU conversation. We do not have GPU expertise on staff. Those are the same teams that have deployed first. The form removed the gating factor. The engineers who would have spent a quarter learning a vendor-specific GPU management tool spent an afternoon learning a VergeOS form and moved on.

One Upload, DR-Aware Deployment

The vGPU 20 deployment model in VergeOS is the second piece that has produced unexpected follow-up. Upload the NVIDIA driver bundle and the client config token once. VergeOS generates the guest driver ISO. The ISO attaches to the VM on first boot. There are no portal round-trips, and the manual driver install per guest disappears. The driver and license token live with the VM lifecycle, not outside it.

VergeOS automated workflow building a guest driver ISO and replicating GPU state to the DR site

Snapshot and replication carry the GPU device configuration with the VM. That detail did not appear on the original webinar slide titled “what is new.” It came out during an audience question. Six weeks later, that single point has moved to the top of the evaluation list for almost every team past the initial demo.

A DR site that inherits the GPU assignment with the VM removes one of the longest-standing operational gaps in GPU virtualization. The traditional answer to “what happens to GPU workloads at the DR site” has been a runbook full of manual reassignment steps. The VergeOS answer is that the GPU assignment is part of the VM record, replicated alongside the disk and configuration. Failover carries it.

Old GPU Virtualization vs vGPU 20 + VergeOS

Capability Traditional GPU Virtualization vGPU 20 + VergeOS
Configuration interface Multiple tools, CLI required Single VergeOS form, no CLI
Driver deployment Portal trip per guest, manual install One upload, ISO auto-generated and attached at boot
Frame buffer isolation Software best-effort Hardware-reserved via MIG
Mixed workload on one card Limited or unsupported AI, VDI, and CAD concurrent on one card
DR with GPU state Manual runbook reassignment Snapshot and replication carry the GPU configuration
Specialist staff required Yes No
Trial license Varies by vendor and SKU 128 seats, 90 days, NVIDIA portal

The Cost Conversation Has Flipped

The cost conversation has flipped. Six weeks ago the first question from every IT director on a GPU call was a variant of “we cannot justify a GPU per VM.” That question has not arrived once in the last three weeks of follow-up calls. The question now is the inverse. How many more workloads can we put on this single card.

Once a team sees a single RTX Pro 6000 Blackwell run AI inference, twenty knowledge-worker desktops, and a handful of CAD seats concurrently, the cost-per-workload math becomes the easy answer. Three projects, three budget lines, three vendor evaluations collapse into one platform decision. That collapse is what has compressed the deployment timeline.

Paul Hodges, VergeIO’s Field CTO on the webinar, put it cleanly during Q&A. Once customers see VergeOS working with NVIDIA the conversation shifts from “can we afford to do this” to “when do we start.” Six weeks of field calls have proved that the moment an IT director sees MIG configured through a point-and-click form, that observation is accurate.

The mixed-workload use case is the conversation that closes the loop. AI strategy, VDI refresh, and CAD modernization stop being three separate budgets in three separate quarters. They become one platform decision evaluated on one card.

What To Do Next

Teams ready to put this in front of their own workloads have a 128-seat, 90-day trial license available through the NVIDIA licensing portal. Pair the trial with a VergeOS test drive and the full configuration model is on screen inside an afternoon. The fastest path to validating the field observations in this post is to recreate them on a single card.

The next six weeks will produce more data. Our prediction, based on the pattern of the first six, is that the mixed-workload pilot becomes the standard first deployment shape. The teams running AI inference against a single MIG slice today will be running VDI and CAD against the same card next quarter. That is the architecture vGPU 20 plus VergeOS was built for.

Frequently Asked Questions
Does MIG eliminate noisy neighbor in every scenario?
MIG eliminates noisy neighbor for frame buffer and GPU compute, the two resources that produced the most disruption in shared GPU deployments. PCIe and host CPU contention are separate considerations, handled by the VergeOS scheduler at the host layer.
Can VMs sharing a single GPU live on different hosts?
No. The vGPU and MIG models require the VMs sharing a card to run on the host that owns the card. VergeOS placement policies handle host affinity automatically.
Does VergeOS support over-provisioning of vRAM on the GPU?
No. vRAM allocation is one-to-one with the profile. The frame buffer reservation is the foundation of the deterministic latency model, and over-provisioning would break it.
Is the RTX Pro 4500 Blackwell supported under vGPU 20 with VergeOS?
Yes. The same driver set covers the 4500 Blackwell. The MIG and vGPU configuration model in VergeOS is identical across both cards.
Does VergeOS expose an API for GPU configuration automation?
Yes. The same configuration available through the form is available through the VergeOS API, which integrates with Terraform and other infrastructure-as-code workflows.
How do I get the 128-seat trial license?
NVIDIA provides a 128-seat license valid for 90 days through its licensing portal. Pair it with a VergeOS evaluation to see the configuration model end to end.

Filed Under: GPU Tagged With: , , , , , ,