Few build Hypervisors. We’re one of them.

There’s something that keeps popping up — and it’s hard to ignore. More and more companies (hosting providers, software vendors...) are claiming they master the stack… when in reality, they’re just using it.

Now, let’s be fair: there’s nothing wrong with using a piece of software without knowing every detail of how it works. We all do it. But using something isn’t the same as building it. And it’s definitely not the same as maintaining it, or understanding its internals well enough to make critical decisions under pressure. Pretending otherwise? That’s where things get murky.

I get it — I’ve been there. I spent years as a sysadmin, navigating complex systems, tweaking performance, automating processes. I felt like I knew the software I was working with. But looking back, I was just a very advanced user. And that’s not a problem — unless you start claiming you’re in control. Or worse, unless you build your business on that assumption.

Let’s ground this discussion in something I know intimately: hypervisors.

I’ve been working with Xen since 2005. My journey started with Debian packages and evolved through years of hands-on experience with XCP and XenServer. Over time, I got comfortable with the APIs, the performance tunings, the edge cases. I understood how to operate it well — and in many contexts, that looks like mastery.

But true mastery started much later — in 2018, when we forked XenServer and began building XCP-ng. That’s when we crossed a line: from user to maintainer. From integrator to builder.

Suddenly, we weren’t just consumers of someone else’s work. We were responsible for the whole stack — and everything that comes with it. Packaging, compatibility, testing, performance, security, upstream collaboration… the works. We had to understand every layer, and then own it.

That’s when things got real.

And it gave us a new lens to look at the entire ecosystem. We didn’t just discover challenges inside our own stack — we also began to see how other hypervisors were built. By comparison, we noticed a lot of shortcuts: tradeoffs made for performance at the cost of security, designs constrained by legacy architecture, or decisions shaped more by vendor convenience than user resilience.

In Xen, we saw something different. Yes, it’s a smaller project in terms of codebase and contributor count — but that’s part of its strength. It’s possible to actually understand it. To audit it. To reason about its behavior. That level of transparency is rare, and it matters — especially when you're building critical infrastructure.

Now contrast that with Linux/KVM. It’s everywhere — and it’s powerful. But unless you’re Google, IBM or Meta, odds are you have no control over its direction. And realistically, you don’t even have visibility. The Linux kernel is a massive organism with thousands of contributors and millions of lines of code. If something breaks in the parts you depend on, good luck figuring it out — let alone fixing it.

None of this is inherently bad — as long as you’re honest about the tradeoffs. But let’s not confuse usage with ownership. If your cloud product is built on KVM, and you’re not contributing upstream or tracking kernel internals, you don’t control your platform. You’re betting your business on someone else’s decisions. You’re hoping nothing breaks. You’re hoping nobody upstream drops a feature or introduces a regression that affects you.

And hope isn’t a strategy.

Meanwhile, some companies take it even further: extracting massive value from open source without contributing anything back. AWS is a textbook case — a masterclass in monetizing other people’s work. Efficient, yes. But sustainable? That’s a different question. Even AWS finally decided to invest on their platform later.

Back at Vates, we’ve taken a different path — a slower, harder one, but one we believe in. When we forked XenServer, we didn’t just want to build a new product. We wanted to master the entire stack. To be one of the few who truly understand how hypervisors work — and contribute meaningfully to the future of virtualization.

That journey has taken years. We started with a team of two. Today, we’re over 25 people, with specialists across the entire stack: platform engineers (yes, XCP-ng is its own Linux distro), hypervisor experts (and no, they don’t grow on trees), performance and security teams, storage and network specialists. And even now — after all this work — we’re still learning, still refining.

Interestingly, our experience building Xen Orchestra — a full orchestration layer — taught us something important: it’s far more visible and rewarding in terms of features (like backup, UI, automation), but also much cheaper to build than the virtualization platform itself. Yet, it’s the low-level foundation — the hypervisor and everything beneath — that requires the deepest commitment. It’s not sexy. But it’s critical. And that’s the path we chose to take, knowing full well how rare that is.

But we’ve reached a milestone: for the first time, I can say that we are independent. We can now survive even if the original project we forked, XenServer, disappeared tomorrow. That’s a big deal. Could we say the same for many (almost all) vendors?

And it didn’t happen by accident. It happened because we chose the hard path: contributing upstream, investing in real expertise, and putting in the work to actually understand what we ship.

That’s what it takes to master a stack.

Even if a hypervisor sounds like a commodity, it really isn’t. This piece of software sits at the absolute core of your infrastructure — and for several critical reasons, it’s anything but generic.

First, there’s security. A hypervisor is one of the highest-privilege components in your stack. If something goes wrong there, everything is at risk. And security isn’t static — new vulnerabilities, new attack surfaces, and even hardware-level flaws are discovered all the time. Think of Spectre and Meltdown: vulnerabilities that required not only OS updates, but also deep changes in how hypervisors handled isolation at the CPU level.

Second, hardware doesn’t stand still. Every year brings new CPU instructions, new features, new edge cases. Whether it's memory encryption (like SEV on AMD), confidential computing, nested virtualization, IOMMU changes, or exotic scheduling features — the hypervisor has to evolve constantly to support modern workloads. You don’t just "figure it out once" and move on. It's a living, breathing layer that must continuously adapt.

If you don't invest in that expertise — either in-house or via a vendor who actually understands the stack — the cost doesn’t disappear. It just shifts. You’ll pay it later in outages, security incidents, performance regressions, or dead ends when your hardware moves forward but your virtualization layer doesn’t.

That’s why calling hypervisors a commodity is a dangerous illusion. They're critical, complex, and constantly evolving. And treating them like they’re interchangeable is a good way to end up exposed — or stuck.

So here’s the real point: if you’re relying on a virtualization platform — for your cloud, your infrastructure, your business — ask yourself a simple question:

Who actually understands it?

Who can fix it when it breaks? Who knows how it’s built? Who’s paying attention to the low-level changes that might impact your security, your performance, your future? If you don’t know, you’re exposed. And if your vendor doesn’t know… well, good luck.

And for those of us in Europe: this question is even more important right now. Sovereignty isn’t just a buzzword — it’s about control, resilience, and trust. So ask yourself: which European companies actually have this kind of deep expertise?

Spoiler: not many.

But we’re proud to be one of them.