Coder Legion - Recent posts tagged virtualization

KVM vs KVM - what is the question?

Tue, 28 Jul 2026 22:04:05 +0000

Last weekend I was looking for a new project for my Raspberry Pi. I was looking for ways to set up a KVM on my Pi5 since it has 8GB of RAM, which is beefy enough for additional virtualisation tasks. Once I started Googling how I should start this task, I would look up “KVM on Raspberry Pi”. Most of the search results were for another entirely different KVM.

A Keyboard, Video, and Mouse (KVM) switch is a hardware device that allows a user to control multiple computers or servers using a single set of keyboard, video display, and mouse devices. While the KVM switch is a great technology that allows you to control multiple computers using your existing setup, I currently use Tailscale for accessing my remote Pis via my home laptop. So that wasn’t what I was looking for. Instead, I was interested in seeing whether I could run a Kernel Virtual Machine (KVM) on my Pi5.

Despite sharing the same acronym, a KVM switch and the KVM software operate in entirely different realms of technology: one is a physical hardware device for managing physical computers, while the other is open-source software built into Linux to create and manage virtual machines. The KVM Switch routes peripheral and display signals between different systems with the press of a button or a keyboard shortcut.

What is a KVM VM?

Kernel-based VM is an open source virtualisation technology for Linux. With KVM, Linux can function as a hypervisor that runs multiple, isolated VMs. KVM was announced way back in 2006 and actually merged into the Linux kernel in 2007. Virtualisation, which lets you run an operating OS inside another OS, is possible thanks to hypervisors.

A hypervisor pools computing resources (like processing, memory, and storage) and reallocates them among VMs. The hypervisor can run multiple VMs at once, manage them, and support the creation of new ones. The physical hardware, when used as a hypervisor, is called the host, while the many VMs that use its resources are guests. Hypervisors need OS-level components such as memory management, process scheduling, I/O, device drivers, security management, a network stack, and more to run VMs.

KVM has all these components because it’s part of the Linux kernel. Every VM is implemented as a regular Linux process, scheduled by the standard Linux scheduler, with dedicated virtual hardware like a network card, graphics adapter, CPU, memory, and disks.

Similarities between KVM and KVM

Both technologies fundamentally exist to solve an efficiency problem: enabling a user to manage multiple OSs from a single workstation without buying duplicate input devices or displays. Whether toggling between two physical tower PCs or switching focus between multiple virtual instances, both implementations allow one operator to interact with distinct, isolated computing environments. Furthermore, both solutions preserve system isolation, ensuring that actions taken within one environment do not interfere with or crash the other operating systems running alongside it.

Differences

The key distinction lies in hardware physical routing versus software virtualisation. A KVM switch is a tangible piece of hardware that physically redirects signal cables (HDMI/DisplayPort and USB) so that a single set of peripherals can control multiple physically distinct servers or PCs. It does not alter how the computers operate; it merely changes which machine receives your keypresses and sends video output to your monitor.

In contrast, a Kernel-based VM is a software module integrated directly into the Linux kernel that turns the host OS into a Type-1 hypervisor. Instead of connecting separate physical machines, the kernel-based KVM partitions a single computer's underlying processor, memory, and storage to simulate entirely separate virtual computers (Guest VMs) on the same bare metal.

The question should’ve been KVM or Xen?

And that brings us to a totally different question. KVM and Xen - what are the differences and which one can I run on my Pi5 for virtualisation? While both KVM and Xen are open-source Type-1 hypervisors that deliver high-performance virtualisation, their core designs and operational structures differ significantly.

KVM is built directly into the Linux kernel as a standard kernel module (kvm.ko). Installing KVM turns an existing Linux OS into a hypervisor, granting you immediate access to standard Linux drivers, process schedulers, and existing system management tools without having to modify the host kernel. Conversely, Xen sits below the OS as a microkernel-based layer that boots first, before any OS. It relies on a special, privileged Guest VM known as Dom0 (Domain 0) to handle hardware access, boot management, and admin control over other Guest VMs (DomU).

KVM relies purely on hardware-assisted virtualisation (using processor extensions like Intel VT-x or ARM Virtualisation Extensions) to run unmodified Guest OSs. Xen historically pioneered paravirtualisation (where guest kernels are modified to communicate directly with the hypervisor API for higher efficiency), though it now supports hardware-assisted virtualisation as well. Furthermore, Xen’s strict separation of the hypervisor microkernel from the control domain (Dom0) isolates hardware drivers away from guest VMs, which makes it a popular architecture for high-security environments like Qubes OS.

For almost all Raspberry Pi 5 use cases, KVM is the far more practical and seamless option.

In the case of the Raspberry Pi, you’ll need to verify hardware virtualisation support before doing anything. Check that ARM CPU virtualisation extensions are available. Check that the KVM hypervisor kernel module is present and accessible with the below command:

ls -l /dev/kvm

You should see an output showing crw-rw---- 1 root kvm ... /dev/kvm.
If /dev/kvm exists, hardware acceleration is supported and active.

The Raspberry Pi’s boot process relies on a proprietary EEPROM-based bootloader that loads GPU firmware and kernel binaries directly from an SD card or NVMe storage (often chainloaded through U-Boot for standard Linux environments). Because KVM is integrated into standard ARM64 Linux kernels (like Raspberry Pi OS 64-bit or Ubuntu), it requires no special bootloader tweaks or UEFI emulation layer. You simply install `qemu-kvm` (QEMU) and libvirt, and the Pi instantly acts as a hypervisor using built-in ARM hardware extensions, allowing me to easily spin up VMs using standard Linux tools like virt-manager or cockpit.

You can run the following command to install the hypervisor, daemon services, and CLI management tools like QEMU core binaries. Since I’m running Raspberry Pi OS Desktop with the graphical interface, I also appended virt-manager to the below command:

sudo apt install -y qemu-system-arm qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager

Once the packages are installed, I just need to startup/enable the libvirtd service to ensure the hypervisor daemon starts automatically on boot:

sudo systemctl enable --now libvirtd

Libvirt includes a default NAT network interface (virbr0) for guest VMs. As soon as the default virtual network was configured, I can simply create my first Guest VM on the Pi5 and use an Ubuntu ARM64 ISO image, sourced from the Canonical website. The virt-install looks a little like this:

virt-install \
  --name debian-vm \
  --memory 2048 \
  --vcpus 2 \
  --disk size=10,bus=virtio \
  --os-variant debian12 \
  --cdrom /path/to/debian-arm64.iso \
  --network network=default \
  --graphics vnc,listen=0.0.0.0

In contrast, setting up Xen on a Pi 5 requires a complex boot architecture. Because Xen acts as a microkernel that must load before any OS, booting it on an SBC (Single Board Computer) generally requires using U-Boot to load the Xen binary alongside device-tree overlays, a customised Dom0 control domain, and a secondary driver domain. While projects like Xen-Troops exist specifically to compile custom Yocto-based Xen images for embedded systems and automotive apps, setting this up for home or homelab experiments involves significant compilation overhead, non-standard driver configs, and manual partition setups. While maybe not suited to Pi5, it’s not impossible on previous versions like the Pi4, as stated on the Linux blog. For edge use-cases you can certainly stick with KVM for a smooth setup unless you specifically need Xen's compartmentalised driver architecture for complex embedded development. If you’d like to read why Edera specifically opted for Xen when building a secure microservice foundation, check out their blog post.

I Spent a Week Installing WSL2. The Fix Was Two Lines.

Wed, 06 May 2026 15:49:50 +0000

"WSL2? Five minutes, tops." — Me, seven days ago.

TL;DR

On Windows 11 25H2 (build 26200), enabling VirtualMachinePlatform hangs at 37.8%. Forever. The servicing stack is stuck on 24H2 (build 26100) while the OS moved to 25H2 (build 26200). Windows literally cannot service itself.

Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess

If you just want the fix, there it is. If you want to know how it took a week and 10 failed attempts to arrive at two lines of PowerShell, keep reading.

Day 1: Innocence

Simple plan. Install WSL2. Set up Ubuntu 24.04. Do actual work.

wsl --install -d Ubuntu-24.04

37.8%.

I made coffee. Came back. 37.8%.

I had lunch. Came back. 37.8%.

37.8 is now my least favorite number.

The Crime Scene


OS	Windows 11 Pro 25H2 (Build 26200.8037)
CPU	Intel Core Ultra 9 275HX
DISM version	10.0.26100.5074
Servicing stack	10.0.26100.8035

See it? OS is build 26200. Servicing stack is build 26100. The mechanic has last year's manual for this year's car. If you spotted this, you already know the ending. I did not spot this on Day 1.

Days 2-6: The Parade of Failures

GUI — Stuck. Cancel also stuck.

"Turn Windows features on/off." Checked the box. Progress bar froze.

Clicked Cancel. Cancel froze.

A cancel button that cannot be cancelled. This is the operating system from the world's most valuable company.

Task Manager. End Process. Moving on.

DISM — 37.8%

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

37.8%. We meet again.

PowerShell — Same wall, different paint

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart

Calls DISM internally. Same result. Changing the wrapper doesn't change the candy.

Uninstalled BlueStacks — Wrong suspect

Found forum posts: "Android emulators conflict with Hyper-V." I had BlueStacks 10 installed. Uninstalled it completely. Registry cleanup. Folder purge. The works.

Result: 37.8%.

BlueStacks was innocent. And now I have to reinstall it later.

Offline install from 24H2 ISO — Version mismatch

"If the download is the problem, go offline."

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess /Source:D:\Sources\Install.wim

0x800f0912. The ISO is 24H2 (26100), the OS is 25H2 (26200). Windows refuses the source files because they're from "the wrong version." Self-compatibility is apparently optional.

Windows Update cache reset — No effect

net stop wuauserv
net stop bits
Remove-Item C:\Windows\SoftwareDistribution\Download\* -Recurse -Force
net start bits
net start wuauserv

Clean cache. Same 37.8%. Cleaning the house doesn't fix the plumbing.

Pending operations cleanup — Partial

dism /online /cleanup-image /revertpendingactions

Cleared the backlog. Feature still won't activate. Finishing your homework doesn't mean you'll pass the exam.

In-place repair install — Didn't downgrade

The nuclear option. Ran 24H2 ISO's setup.exe with "Keep personal files and apps."

40 minutes. Three reboots.

Result: OS stayed on 25H2 (26200). In-place install doesn't downgrade. But it did clean up the component store. This becomes a crucial plot point later.

Day 7: Reading the Logs (Finally Using My Brain)

A week of "try something else until it works." At this point, the question isn't what doesn't work — it's why.

Select-String -Path C:\Windows\Logs\CBS\CBS.log `
  -Pattern "Error|Failed|0x800f" -Context 2 | Select-Object -Last 20

The smoking gun:

Failed to get uup features from WU, sessionData: {
  "ModuleID":"FOD",
  "Features":[{
    "name":"Windows.HyperV.OptionalFeature.VirtualMachinePlatform.Client.Disabled~"
  }]
} [HRESULT = 0x800f0820 - CBS_E_CANCEL]

download source: 8, download time (secs): 1256, 
download status: 0x800f0820 (CBS_E_CANCEL)

1,256 seconds. Twenty-one minutes waiting for Windows Update to deliver a package it will never find.

From the DISM log, the confession:

Dism.exe version: 10.0.26100.5074
Target image: OS Version=10.0.26200.8037

The servicing stack (26100) is trying to service a newer OS (26200). It goes to Windows Update looking for FOD packages matching this combination. Those packages don't exist in the UUP catalog. So it waits. And waits. And times out at 37.8%.

A car mechanic with a 2023 catalog trying to order parts for a 2024 model. "This part number doesn't exist in our system, sir."

This is the servicing architecture of the world's largest software company.

The Fix: Use the Back Door

DISM can't download the FOD through its usual channel (UUP). But Add-WindowsCapability uses a different channel.

Same building. Front door is under construction. Back door is open. The sign only mentions the front door. Classic Windows UX.

# Step 1: Back door — install payload via alternative channel
Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"

# Step 2: Now activate using only local files (no internet needed)
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess

100%.

One hundred percent.

First three-digit number I've seen all week.

Why This Works

[Front door — BLOCKED]
DISM enable-feature
  → Needs FOD payload
  → Windows Update UUP channel
  → Servicing stack (26100) ≠ OS (26200)
  → "Part not found in catalog"
  → 21 min timeout → CBS_E_CANCEL

[Back door — OPEN]
Add-WindowsCapability  
  → Different download channel (bypasses UUP)
  → Payload installed locally ✓

DISM + /LimitAccess
  → "Internet? Don't need it."
  → Local files only
  → Success ✓

Both commands use the same Windows servicing system. But they fetch FOD packages through different channels. DISM goes through UUP, where the version mismatch kills it. Add-WindowsCapability takes a different route. The official docs don't mention this distinction. You're welcome.

If You Found This Article

You've probably already tried and failed multiple times. That means pending operations are likely piled up. Clean house first:

# Light cleanup
dism /online /cleanup-image /revertpendingactions
# → Reboot → Run the two-line fix

# If that's not enough (in-place repair)
# 24H2 ISO → setup.exe → "Keep personal files and apps"
# → Reboot → Run the two-line fix

Complete Flow (For Fresh Starts)

1. Enable virtualization in BIOS
   HP laptops: F10 → Security or Configuration → Enable VT-x
        ↓
2. Enable Hyper-V + WSL (these work fine, ironically)
   dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart
        ↓
3. Clean pending operations (if you've been trying things)
   dism /online /cleanup-image /revertpendingactions → reboot
        ↓
4. The actual fix
   Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"
   dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess
        ↓
5. Reboot → Install WSL2
   wsl --install -d Ubuntu-24.04

Is This Your Problem?

# Check version mismatch in DISM log
Get-Content C:\Windows\Logs\DISM\dism.log -Tail 100
# "version:" ≠ "image version:" → yes, this is your problem

# Check CBS log for the specific failure
Select-String -Path C:\Windows\Logs\CBS\CBS.log `
  -Pattern "Error|Failed|0x800f" -Context 2 | Select-Object -Last 20
# "CBS_E_CANCEL" → yes, this is your problem

# Verify CPU virtualization (prerequisite)
Get-CimInstance -ClassName Win32_Processor | 
  Select-Object VirtualizationFirmwareEnabled, VMMonitorModeExtensions

Summary


Symptom	VirtualMachinePlatform stuck at 37.8%
Root cause	25H2 OS (26200) + 24H2 servicing stack (26100) = FOD download mismatch
Fix	`Add-WindowsCapability` to bypass → `dism /LimitAccess` to activate
Prerequisite	Clear pending operations
Cost	One week of evenings. One wrongly accused BlueStacks. A lasting distrust of progress bars.

Lessons

Read the logs first. "Try random things until something works" is the scenic route to nowhere.
Windows Insider means signing up for this. 25H2 is a preview build. The servicing stack hasn't caught up. Now you know.
Same building, multiple doors. When DISM fails, Add-WindowsCapability exists. The docs won't tell you.
Feed your logs to AI. Nobody should read 160,000 lines of CBS log with their own eyes.

This troubleshooting session was done with Claude Code. It pulled the critical 6 lines from a 160,000-line CBS log and helped identify the Add-WindowsCapability back door. Without it, this would have ended with a format and reinstall.

Proxmox LVM Notları

Fri, 24 Apr 2026 07:42:53 +0000

Tüm PVE makinelerde uygulanacaklar

Sanal makineye atanan disk silindiğinde üzerindeki verilerin sıfırlanmasını sağlar. Aksi durumda aynı aralığa denk gelen başka bir mantıksal alanda bir önceki mantıksal alanın verilerine erişim sağlanabilir.
sed -i 's/^\([ \t]*\)#*[ \t]*issue_discards[ \t]*=.*/\1issue_discards = 1/g' /etc/lvm/lvm.conf

Önerilen sanal makine disk yapılandırması

Tür	Seçenek
SCSI Controller	VirtIO SCSI Single
HDD Türü	scsi
Cache	Write through
Discard	seçili değil
IO thread	✔ seçili
Async IO	Default (io_uring)

LVM bölüm oluşturma ve diğer PVE makineler üzerinde devreye alma

İlk makinede

pvcreate /dev/mapper/ORNEK_LUN
vgcreate TEST-PVE-SHARED /dev/mapper/ORNEK_LUN

Diğer makinelerde

‌pvscan --cache -a ay
pvs # Diski görebilmeliyiz.
vgs # Hacim grubunu görebilmeliyiz.

LVM disk genişletme

Herhangi bir makinede

lsblk # Diskin genişletildiğini çekirdek algılamış mı diye bakılır. Algılamamışsa aşağıdaki komut çalıştırılır.
for HDD in $(ls -1 /dev/sd* | awk -F '/' '!/[0-9]/ {print $3}'); do echo 1 > "/sys/class/block/${HDD}/device/rescan"; done
sleep 5
systemctl reload multipathd.service
pvresize /dev/mapper/ORNEK_LUN

Kalan diğer makinelerde

for HDD in $(ls -1 /dev/sd* | awk -F '/' '!/[0-9]/ {print $3}'); do echo 1 > "/sys/class/block/${HDD}/device/rescan"; done
sleep 5
multipath -r

Depolama anlık görüntüsünden dönüş (Restore Storage Snapshot)

Multipath yapılandırması yapıldıktan sonra

pvscan --cache -a ay
vgimportclone -n YENI_VG_ADI /dev/mapper/YEDEK_ADI
vgchange -a y YENI_VG_ADI

Windows makinelerde yaşanan yedek alma sorununun çözümü

Sorun 2 nedenden kaynaklanıyor.

QEMU Guest Agent VSS Provider'ın VSS'i yönetme şeklinden kaynaklı.
Özellikle MSSQL Server ve MS Exchange bulunan sunucularda sorun yaşanıyor.

Numara İsim

1 VSS_BT_FULL

2 VSS_BT_INCREMENTAL

3 VSS_BT_DIFFERENTIAL

4 VSS_BT_LOG

5 VSS_BT_COPY

MSSQL Server ve MS Exchange gibi VSS duyarlı yazılımların en iyi çalıştığı seçenek VSS_BT_COPY yani 5 numaralı seçenek.
Aşağıdaki komut ile Kayıt Defteri üzerinde gerekli değişikliği yapabilirsiniz. Bilgisayarı yeniden başlattıktan sonra devreye girecektir.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider" -Name "VssOption" -Value 5 -Type DWord
Yedek alma işlemi başladığında Windows'taki VSS hizmeti yetki sorunu yaşıyor. Akabinde Olay Görüntüleyicide(Event Viewer) 8194 numaralı hata kaydı oluşuyor.
Bu sorunu düzeltmek için, Başlat(Start) (sağ tıklayın) → Çalıştır yoluyla dcomcnfg aracını çalıştırın. Konsol Kökü(Console Root) → Bileşen Hizmetleri(Component Services) → Bilgisayarlar(Computers) → Bilgisayarım(My Computer) (sağ tıklayın → Özellikler) yolunu izleyin. COM Güvenliği(COM Security) sekmesindeki Erişim İzinleri(Access Permission) bölümünde, varsayılan ayarları düzenleyin ve NETWORK SERVICE kullanıcısını ekleyerek Yerel Erişime(Local Access) izin verin.
Değişikliklerin geçerli olması için sanal makineyi yeniden başlatın.

Numara	İsim
1	VSS_BT_FULL
2	VSS_BT_INCREMENTAL
3	VSS_BT_DIFFERENTIAL
4	VSS_BT_LOG
5	VSS_BT_COPY

Önemli Notlar

Farklı sürümler arası sorunsuz geçiş için mevcut ana sürümlerin en güncel haline getirilmesi gerekmektedir.

Proxmox 9'a geçiş öncesi LVM'deki anlık görüntü(snapshot) özelliği devredışı kalmalıdır. Kümedeki eski sürüm Proxmox makinelerde LVM bölüm için söz dizimi(syntax) hatası veriyor.

HA yapılandırmasında öncelik değeri belirtilmezse HA kuralı çalıştığında sistem, kaynağın en müsait olduğu düğüme(node) sanal makineyi taşır.

Scale Computing Unifies Edge Infrastructure with Single-Platform Architecture

Mon, 02 Feb 2026 15:56:16 +0000

At the 66th IT Press Tour, Scale Computing presented its consolidated edge computing platform following its merger with Acumera. The company now manages over 100,000 sites and 250,000 edge computing workloads through a unified software stack.

Technical Architecture

Scale Computing's platform consists of four integrated components that handle everything from virtualization to network security:

SC//HyperCore combines compute, storage, and virtualization into a single software layer. The system runs on any x86 server and includes self-healing automation that detects and recovers from infrastructure issues without manual intervention.

SC//Fleet Manager provides centralized orchestration through a cloud-based management interface. Zero-touch provisioning automates deployments across the entire fleet. You can push application updates to thousands of locations without site-by-site scripting.

SC//Reliant Platform delivers edge computing as a service with an API-powered management system. The platform supports both VMs and containers on dedicated server environments.

SC//AcuVigil handles managed network services with SDWAN and next-generation firewall capabilities. The service includes hardened network devices deployable in high-availability configurations.

Running AI at the Edge

Scale Computing positions its platform as infrastructure for decentralized AI systems. The edge deployment model addresses four specific requirements:

Reduced latency for real-time processing
Data privacy through local processing
Deployment speed with zero-touch provisioning
Scalability across distributed locations

The Yum! Brands' case study demonstrates this approach. Taco Bell deployed proprietary Voice AI technology on the Reliant Platform across hundreds of drive-thru locations. The system processes natural language orders locally and integrates with POS systems and digital menu boards.

Development and Deployment

For developers working with edge applications, the platform supports standard containerized workloads alongside traditional VMs. The Advance Auto Parts deployment shows this flexibility—they replaced single-server POS systems with SC//Platform to support their container strategy while maintaining existing VM workloads.

Breedon Group's implementation illustrates the infrastructure approach. They run Kubernetes nodes on NVMe-powered clusters dedicated to data analytics, connecting remote IoT devices through Azure IoT Hub and serving Power BI users across the organization.

The platform handles replication between sites automatically. Snapshots and failover mechanisms operate without custom scripting.

Integration Points

SC//Platform integrates with common enterprise tools:

Cloud providers for hybrid deployments
Container orchestration platforms
Analytics and BI tools
PCI compliance tools and security scanning
Payment processing systems
Network monitoring and traffic analysis

The architecture separates the management plane from the edge platform, enabling centralized configuration and policy management while maintaining local processing capabilities.

Deployment Scale

Scale Computing operates in 30+ countries with 4,000 customers. The platform scales beyond 10,000 locations from a single management interface.

Performance metrics from customer deployments show uptime above 99%, a 70% reduction in overall costs, and a 50% improvement in operational efficiency.

The company holds 30+ patents related to edge computing and network security technologies.

What This Means for Edge Development

Edge computing infrastructure is consolidating. Instead of managing separate systems for virtualization, networking, security, and application deployment, you can work with a unified platform.

The shift to zero-touch provisioning changes how you approach edge deployments. Applications need to support automated deployment and configuration without onsite technical staff.

Container support at the edge opens standard DevOps workflows for distributed environments. You can use the same tools and processes you use in the data center.

Network security integration at the platform level reduces the complexity of securing edge applications. The infrastructure handles SDWAN, firewall rules, and compliance requirements.

Scale Computing's approach reflects where edge computing is headed—toward platforms that handle the full stack from hardware management to application deployment.

VergeIO's Unified Architecture: A Developer's Alternative to VMware

Sun, 01 Feb 2026 00:42:58 +0000

At the 66th IT Press Tour, VergeIO Chief Marketing Officer George Crump presented what might be the most compelling technical argument against traditional IT stacks I've heard in years. The pitch wasn't about incremental improvements or feature parity. It was about fundamentally rethinking how infrastructure software gets built.

The Code Base Argument

Here's the number that caught my attention: 400,000 lines of code.

That's the entire VergeIO code base. Compare that to a typical VMware stack, which includes vSphere, vSAN, NSX, and vCenter. Add it all up, and you're looking at roughly 30 million lines of code.

VergeIO delivers comparable functionality with 1.3% of the code. That's not a typo.

This efficiency comes from a single unified kernel that handles compute, storage, networking, and management. No separate teams writing separate code bases. No integration layers trying to make disparate systems work together. Just one team in Ann Arbor, Michigan writing one piece of software.

Architecture That Actually Makes Sense

Traditional infrastructure stacks look like this:

Compute Layer: vSphere/ESXi
Storage Layer: vSAN or dedicated array
Network Layer: NSX or physical switches
Automation Layer: Terraform/Ansible scripts
Management Layer: vCenter

Each layer has its own code base, its own metadata structures, and its own inefficiencies.

VergeIO collapses this into a single software layer called VergeOS. Install one thing, get everything: complete virtualization (KVM/QEMU based), robust storage (VergeFS), full Layer 2/Layer 3 networking (VergeFabric), and integrated management.

The advantage goes beyond simplicity. With a unified metadata structure controlling the entire environment, VergeIO understands memory allocation, storage patterns, and network traffic in ways that orchestrated stacks can't match.

The Storage Story

VergeFS includes global inline deduplication that works differently than traditional storage systems. Pure Storage and others run deduplication at the backend—data gets written, processed through their algorithm, and deduplicated blocks are stored. When you recall that data, it needs to be rehydrated before sending it back up the network.

VergeIO deduplicates at the kernel level. Every node understands the metadata. Data moves between nodes without rehydration. RAM cache gets deduplicated. Storage gets deduplicated. Memory gets deduplicated.

Crump cited examples of customers running 30,000 to 40,000 IOPS off consumer-grade NVMe SSDs on micro servers. The efficiency gains are real.

Disaster Recovery Done Right

Here's where things get interesting from an engineering perspective.

VergeIO includes IO Guardian—a local protection system that acts as a standalone VergeOS instance designed purely to receive snapshot data. If you lose multiple drives in a catastrophic failure, the system pulls missing blocks from the IO Guardian server in real time.

Crump shared a story about a customer where a service technician mistakenly ejected drives from three out of four servers. The system automatically restarted affected VMs and started pulling data from IO Guardian. The customer's customers never noticed. No data loss, no downtime.

The disaster recovery feature, IO Replicate, takes this further. It's WAN-optimized, leveraging the same deduplication system. If five sites replicate to one location, only unique data crosses the wire.

Virtual Data Centers and Multi-Tenancy

VergeIO's approach to multi-tenancy is built around Virtual Data Centers (VDCs). Think of it as VMware's encapsulation of individual VMs, but applied to entire data centers.

You can snapshot an entire VDC—capturing VMs, network configuration, IP addresses, everything—in a perfectly consistent state. That snapshot replicates to your DR site as a single coherent unit. Recovery typically takes under an hour. According to Crump, VergeIO maintains a 100% success rate on disaster recovery.

For cloud service providers, each customer gets their own VDC. No need to buy new hardware for each customer—just allocate resources from the shared infrastructure. Each VDC can have different service levels, and customers can log into their own isolated environment.

Sub-tenancy is supported too. One service provider uses VergeIO to provide infrastructure to other service providers, who then create their own customer VDCs.

API-First Design

The GUI is entirely driven by the API. If the interface can do it, the API can do it.

More importantly, the API has remained stable for 12 years. Your Terraform and Ansible scripts don't break when you upgrade hardware or change storage configurations. Write to one API instead of juggling separate interfaces for compute, storage, and networking.

VergeIO supports the full Infrastructure-as-Code ecosystem: Terraform, Ansible, Python, PowerShell, Packer. There's a Prometheus exporter for observability tools like Grafana.

The VxRail Opportunity

Dell recently announced that VxRail is "no more," recommending customers move to Dell Private Cloud—which essentially means buying new Dell hardware and new software licenses.

VergeIO offers a different path: VxRail modernization instead of VxRail replacement. Install VergeOS on existing VxRail hardware and get better performance and efficiency without replacing servers.

The company has about a dozen customers who've done this, the largest being Topgolf. With memory and flash storage prices increasing, extending the life of existing hardware makes financial sense.

Technical Specs Worth Noting

Hypervisor: KVM/QEMU based with VergeIO extensions
Scalability: Unlimited nodes per system, petabyte-scale storage
Networking: 10Gb/25Gb/100Gb Ethernet, Open vSwitch integration
Storage Media: NVMe (hot tier), SSD/SATA (warm tier), HDD (cold capacity)
Management: HTML5 web interface and full REST API

The Licensing Model

VergeIO charges by physical server. Not by processor count, not by cores, not by storage capacity. You build the server however you want—four processors, 200 cores, a petabyte of capacity—same price.

This pricing model encourages customers to consolidate onto fewer, denser servers in their second hardware refresh cycle. Fewer servers means savings on power, cooling, rack space, and operational overhead.

What This Means for Developers

If you're responsible for infrastructure, this architecture matters.

Single API to learn instead of three or four. Code that doesn't break when hardware changes. Consistent metadata structure across compute, storage, and networking. Deduplication that actually reduces your infrastructure footprint instead of just your storage footprint.

VergeIO runs on commodity hardware. Mix and match server vendors, CPU generations, even Intel and AMD in the same cluster. The software abstracts away the complexity.

For organizations running AI workloads, you can hard-allocate GPUs to specific VDCs. Only that tenant can use those GPUs—no sharing, no scheduling conflicts.

Market Reality

VergeIO is growing at roughly one customer every two to three days. The company is based in Ann Arbor, Michigan, self-funded, and cash flow positive. Less than 100 employees. No Silicon Valley funding rounds.

Their primary competition is VMware (80% of replacements), with some Nutanix and Scale Computing migrations. The company reports 100% customer satisfaction and zero customer losses except for non-payment.

Notable customers include University of Michigan (their largest research facility), Boeing, Raytheon, and various military installations. The Vietnam airport system runs on VergeOS.

The Bottom Line

VergeIO represents a genuinely different approach to infrastructure software. Not better versions of existing tools, but a fundamental rethinking of how infrastructure code should be written.

400,000 lines instead of 30 million. One code base instead of five. One API instead of a dozen integration points.

For organizations looking to move away from VMware or modernize aging VxRail deployments, VergeIO offers a technically sound alternative. For developers tired of wrestling with orchestrated stacks, it's worth a look.

The software is there. The architecture makes sense. The pricing model is straightforward. What remains to be seen is whether the market rewards fundamental innovation or sticks with what it knows.