Run of Show · Beyond the Hypervisor Swap

VergeIO Live Webinar · Thursday, June 11, 2026 · 1:00 PM ET · 45 minutes
Campaign
Beyond the Hypervisor Swap — VergeOS 2026 Architecture
Format
Moderated panel, architect-led conversation
Backdrop
7-slide deck — ►Open the Deck
Recording
Yes — published to verge.io on-demand page within 24 hours
Q&A
Chat throughout; Aaron surfaces questions in Block 6 and ad hoc
Goal
Reset the conversation from “VMware alternative” to “Private Cloud Operating System”; demonstrate Kit + Greg architectural alignment

Roles

Aaron Richman
Field Evangelist, VergeIO · Moderator
Drives the arc with open architecture questions. Does not narrate slides — the deck plays behind the conversation. Times segments. Surfaces chat Q&A. Closes the session.
Greg Campbell LEAD
Founder & CTO, VergeIO · Architect of VergeOS
Architecture lead. Defends the design decisions behind a single-code-base Private Cloud OS. Owns the technical narrative: integration overhead, stack collapse, Kubernetes as a workload.
Kit Colbert LEAD
Board Member, VergeIO · Former CTO, VMware
Credibility voice. Speaks from twenty years inside VMware engineering. Frames the post-Broadcom moment, the GUI-integration vs code-integration distinction, and why this architecture is right for the next decade of containers and AI.
George Crump
CMO, VergeIO · Panelist
Customer-side translation. Short interjections on commercial impact (cost, ops, “what does this mean for my bill”). Defers architecture answers to Kit + Greg. Handles “how do I get started” questions in Q&A.
Emphasis rule. This session lives or dies on Kit + Greg. Aaron’s job is to give them the floor and stay out of the way. Open the door, then step aside. George keeps interjections to 60–90 seconds and only when commercial translation adds something architects can’t say themselves.

Segments at a Glance

Block Title Length Window Slide
01 Open / Welcome 3 min 1:00–1:03 Slide 1
02 Why Now — The Wrong Exit 7 min 1:03–1:10 Slide 2
03 Integration Overhead 7 min 1:10–1:17 Slide 3
04 What We Built — One Code Base 12 min 1:17–1:29 Slide 4
05 Kubernetes + AI: The Next Decade 8 min 1:29–1:37 Slides 5–6
06 Live Q&A + Close 8 min 1:37–1:45 Slide 7

Block 01 · Open / Welcome Slide 1

01
Open / Welcome
1:00–1:03 · 3 MIN
Aaron sets the room. Frame the session as a conversation between two architects with a CMO to translate. Get out of the way fast.
Welcome & framingAaron · 90 sec
“Welcome to Beyond the Hypervisor Swap. I’m Aaron Richman, and I’ve got two of the most important infrastructure software architects working today on this call with me.”
  • Why this session: the post-Broadcom moment has every IT team asking the wrong question
  • What we’re going to do: 45 minutes, conversation not slides, architecture not marketing
  • Q&A in chat throughout — we’ll get to as many as we can in the last segment
  • Recording goes out within 24 hours; white paper link is in chat now
IntrosAaron · 90 sec
  • Greg Campbell — founder and CTO of VergeIO, wrote the VergeOS code base, will defend every architecture decision live
  • Kit Colbert — former CTO at VMware through Broadcom, joined the VergeIO board in June, here to talk about why the architecture matters for the next decade
  • George Crump — CMO, will translate from architecture to commercial impact when needed
Cue. Aaron, do not say “let’s walk through the slides.” Say “let’s get into it” and pivot to Block 02.

Block 02 · Why Now — The Wrong Exit Slide 2

02
Why Now — The Wrong Exit
1:03–1:10 · 7 MIN
Establish the premise. A hypervisor swap is the wrong exit. Kit opens with VMware-side credibility, Greg follows with the architectural read.
Question to KitAaron · opens
“Kit, you ran engineering at VMware for two decades. You watched the Broadcom transition from the inside. When you look at the IT teams moving today — to Nutanix, to Proxmox, back to bare metal — what is everyone getting wrong?”
Kit answersKit · 3 min
  • The post-Broadcom moment is real; pricing and renewals are forcing decisions
  • But the decisions being made are mostly product swaps, not architecture changes
  • Moving from VMware to Nutanix is moving from one bolted-together stack to another
  • The constraint isn’t the vendor — it’s the architecture pattern
  • Why this matters: the next decade isn’t just VMs, and the stack-of-products pattern doesn’t scale into it
Question to GregAaron · pivots
“Greg, when a VMware customer tells you they’re moving to Nutanix or Proxmox, what’s the architectural problem they haven’t solved?”
Greg answersGreg · 3 min
  • They’ve changed the hypervisor and kept the architecture — hypervisor plus storage plus networking plus backup as separate products
  • That architecture costs you in three places: integration overhead, hardware overhead to hide that overhead, and ops headcount
  • None of those costs go away because the hypervisor brand changed
  • The exit that actually matters is the exit from the bolted-together pattern, not from the brand
TransitionAaron · 30 sec
“OK, so a hypervisor swap is the wrong exit. Greg, talk to me about what that integration actually costs.”

Block 03 · Integration Overhead Slide 3

03
Integration Overhead
1:10–1:17 · 7 MIN
Slide 3 is doing visual work behind the conversation — animated vCenter lines showing every product talking to every other product. Greg names the cost, Kit confirms from the VMware side, George translates to the bill.
Question to GregAaron · opens
“Greg, you and I have argued about the word ‘integrated’ before. Walk us through what integration actually costs at the architecture layer.”
Greg answersGreg · 3 min
  • “Integrated” in the stack-of-products world means orchestrated — vCenter talks to vSAN, vSAN talks to NSX, every product talks to every other product
  • That orchestration runs continuously and consumes CPU, memory, and network bandwidth that doesn’t show up on a workload chart
  • The overhead has to be hidden by overbuying hardware — more memory, more cores, more GPU than the workload actually needs
  • This is why “the integration is fine” customers also have racks running at 30% utilization
Question to KitAaron · pivots
“Kit, you had to defend exactly this architecture as CTO. From inside VMware, what did the customer actually pay for that integration?”
Kit answersKit · 3 min
  • Credibility moment — Kit can validate the overhead claim from the engineering side
  • The “integrated” GUI was real value, but the underlying products were independent code bases with independent release cycles
  • Customers paid in three places: license stack complexity, hardware headroom, and a non-trivial ops team to keep the orchestration coherent
  • That model worked when VMs were the workload. It doesn’t scale to mixed VM + container + AI workloads
Brief interjectionGeorge · 60–90 sec
  • Customer-side translation: the bill goes up, the team gets bigger, the rack utilization stays low
  • Forced restraint: do not pitch. Just name the commercial pattern and hand back to Aaron
TransitionAaron · 30 sec
“So integration is overhead. Greg — you built something different. Walk us through what you actually built.”

Block 04 · What We Built — One Code Base Slide 4

04
What We Built — One Code Base
1:17–1:29 · 12 MIN
This is the heart of the session. Slide 4 plays the stack-collapse animation behind them — five converging arrows from a six-layer VMware stack into the VergeOS Unified Platform. Greg leads, Kit validates, George closes with commercial impact. Keep this clean.
Question to GregAaron · opens
“Greg, walk us through VergeOS. Not the marketing version — the architecture version. What did you actually build?”
Greg answersGreg · 5 min
  • One code base. Virtualization, storage, networking, and data protection from a single operating system
  • No third-party SAN, no third-party backup product, no parallel container stack
  • Why a single code base matters: one upgrade path, one release cycle, one set of failure modes to reason about
  • The collapse: six product layers become four functional capabilities inside one OS — control plane, virtualization, vSAN-class storage, VNet networking, with backup/DR as snapshots and automation built in
  • What you lose: nothing the customer was actually paying for. What you gain: the headroom that integration overhead was eating
Question to KitAaron · pivots
“Kit, you evaluated this technically before you joined the board. What convinced you this isn’t just another marketing claim of ‘integration’?”
Kit answersKit · 5 min
  • The distinction that matters: integration in the GUI vs integration in the code itself
  • Most “integrated platforms” are independent products with a shared management plane. VergeOS is integrated in the code — the storage layer and the virtualization layer share data structures, not API calls
  • What this means architecturally: latency, failure modes, and upgrade paths are not coordination problems anymore
  • Why this is the right architecture for the next decade: container and AI workloads don’t survive the coordination tax that VM workloads have been absorbing for fifteen years
  • Why he joined the board: the architectural bet is right, and the team can defend it under scrutiny
Brief interjectionGeorge · 60 sec
  • Customer translation: one license per physical server, one upgrade for the whole stack, no separate appliance to manage
  • Do not pitch the commercial program here. Just close the loop: this is what “Private Cloud Operating System” actually means on the bill
Watch the clock. Block 04 has the most slack on purpose. If Kit and Greg are in a good groove, let them run. If they’re tight on time, cut George’s interjection and move on.

Block 05 · Kubernetes + AI: The Next Decade Slides 5–6

05
Kubernetes + AI: The Next Decade
1:29–1:37 · 8 MIN
Move the conversation forward in time. Slides 5 and 6 are the backdrop. Kit opens with the “next decade” framing, Greg answers with the technical mechanism. This is where the architecture argument has to earn the room.
Question to KitAaron · opens
“Kit, the next decade isn’t just VMs. It’s containers, it’s AI inference, it’s mixed workloads on the same infrastructure. Does the architecture need to change again, or is what Greg built already there?”
Kit answersKit · 3 min
  • The workload mix shifts dramatically: a typical 2030 rack will run VMs, containers, and AI inference side by side
  • The current pattern — hypervisor for VMs, Kubernetes cluster as a parallel stack, GPU appliance for AI — multiplies the coordination tax by three
  • A single OS that treats containers and AI as just another workload class is the only architecture that scales
  • This is why VergeIO matters now and not five years ago: the workload mix has finally caught up to the architecture
Question to GregAaron · pivots
“Greg, walk us through how VergeOS handles Kubernetes — not as a parallel stack, but as a workload. And what does that mean when an AI team shows up wanting GPUs?”
Greg answersGreg · 4 min
  • Kubernetes runs as a workload class inside VergeOS — no parallel control plane, no separate storage, no separate networking
  • The K8s cluster gets storage from the same vSAN-class layer that VMs use, networking from the same VNet, and isolation from the same OS
  • For AI: GPU-bearing nodes are just nodes; an AI workload is just a workload class with GPU requirements; the OS schedules it the way it schedules everything else
  • What this means for the customer: one platform, one team, one upgrade path — for VMs, containers, and AI on the same hardware
TransitionAaron · 30 sec
“Let’s get to questions. We’ve got a lot in the chat.”

Block 06 · Live Q&A + Close Slide 7

06
Live Q&A + Close
1:37–1:45 · 8 MIN
Aaron drives. Architecture questions to Kit or Greg. Commercial questions to George. Close on time.
Q&A routing rulesAaron · ongoing
  • “How does X work?” — route to Greg
  • “What about VMware’s roadmap / what did VMware do / how does this compare to vSphere?” — route to Kit
  • “How do I get started / what does it cost / how do I evaluate this?” — route to George
  • If a question has both architecture and commercial threads, Kit or Greg first, then George closes the loop
  • Keep answers to ~90 seconds. If a question needs more, mark it for the follow-up email
CloseAaron · 60 sec
  • “Three things to take away” — one each: Kit’s “next decade” framing, Greg’s “one code base” framing, George’s “one license, one upgrade” framing
  • White paper URL in chat one more time: https://www.verge.io/vergeio-architectural-white-paper/
  • Recording lands in registrants’ inboxes within 24 hours
  • “Thank you Kit, Greg, George”

Moderator Question Bank (Backup)

Use these if a beat runs dry or a panelist hands back early. Pre-cleared with both architects. Don’t ask Aaron to ad-lib hard architecture questions live — pull from this list.

For Kit — VMware perspective

  • “Inside VMware, what was the moment you knew the bolted-together stack pattern had hit its ceiling?” (if Block 02 runs short)
  • “You were architecting the multi-cloud strategy when Broadcom acquired VMware. Knowing what you know now, what would you have built differently?” (advanced — only if Kit has space)
  • “Why does a single code base matter more for AI workloads than it did for VM workloads?” (Block 05 backup)
  • “What does the VergeIO architecture do that VMware would have needed five more years to build?” (strong if Kit signals he’s open to it)

For Greg — Architecture deep cuts

  • “Walk us through what happens to a write inside VergeOS — from VM, through the storage layer, to disk. Show us where the code-level integration shows up.” (if a chat question goes deep)
  • “Where in VergeOS is the hardest engineering problem you’ve had to solve?” (crowd-pleaser)
  • “What’s the failure mode in a single-code-base architecture that customers don’t think about until they hit it — and how does VergeOS handle it?” (advanced)
  • “You support oVirt-compatible backup with Veeam. Why not roll your own backup product?” (commercial-architecture bridge)

For George — Commercial

  • “What does a typical evaluation look like?”
  • “How do customers measure ROI six months in?”
  • “What’s the smallest deployment that makes sense?”
  • “Where do I send my team after this session?”

Cross-panel — for when chat goes hot

  • “Kit, Greg — if you had to defend one architecture decision against a skeptical CIO right now, which one would it be and how would you defend it?”
  • “Where do you two disagree on architecture? Where is the live debate inside VergeIO?” (only if the rapport is there — powerful if it lands)

Pre-Show Checklist

  • T−30 min — Aaron, Kit, Greg, George in green room. Audio check on each line.
  • T−20 min — Webinar presentation deck loaded — ►Open the Deck — fullscreen tested on the screen-share laptop. Slide 1 visible.
  • T−20 min — Backup deck location confirmed: standalone HTML in workspace at /Users/georgeacrump/.../outputs/beyond-the-hypervisor-swap-presentation.html.
  • T−15 min — Q&A chat moderator briefed: surface architecture questions to Aaron in real time; flag any commercial-only questions for George at Block 06.
  • T−10 min — White paper URL ready to paste into chat at Block 01 close: https://www.verge.io/vergeio-architectural-white-paper/
  • T−10 min — Confirm Greg and Kit have the panelist link, not the attendee link.
  • T−5 min — Aaron confirms Block 01 open language with all three panelists; quick rapport check.
  • T−2 min — Slide 1 backdrop up. Aaron on camera. Standby.
  • T+0 — Go live. Aaron opens.

Post-Show

  • Confirm recording captured cleanly.
  • Build on-demand playback page using the on-demand-webinar skill (playback page + session content page).
  • Swap internal hub featured webinar URL from registration to on-demand playback (Stage 4 of hub lifecycle).
  • Send thank-you note to Kit and Greg.
  • Q&A overflow — route to the right owner; send follow-up email within 48 hours.
  • Update Canonical URLs record with on-demand URL (v9).
VergeIO · Ann Arbor, MI · Run of Show · Beyond the Hypervisor Swap · June 11, 2026