KubeVirt virtualisation & VDI · built in Europe

Run your VMs and desktops where your containers already live.

KubeVirt runs full virtual machines — real QEMU/KVM guests — as first-class Kubernetes workloads. One control plane schedules VMs, virtual desktops and containers across one network fabric and one storage layer. It is an open exit from per-core hypervisor licensing and a sovereign home for Windows and Linux VDI, without a big-bang rewrite.

  • Full VMs (QEMU/KVM) on Kubernetes
  • Windows & Linux VDI
  • GPU-accelerated desktops
  • Open, no hypervisor lock-in

EU-owned, in the Netherlands, on 100% renewable power · View pricing

KubeVirt virtualisation · VM & desktop poolPLATFORM STACKVMs, desktops & containersWindows & Linux guestsYOU OPERATEKubeVirt control planeQEMU/KVM · libvirt · virt-launcherGRN-MANAGEDNetworking fabricMultus · bridge/VLAN · SR-IOV · MetalLBGRN-MANAGEDStorage layerCDI · Ceph RWX/RWO · OpenEBS · VeleroGRN-MANAGEDHosts & hardwareKVM bare metal · GPUs · renewableGRN-MANAGED GRN.CLOUD

Overview

One platform for VMs, desktops and containers.

KubeVirt is a Kubernetes extension that runs a full virtual machine — QEMU/KVM under libvirt — inside a pod, described by a standard VirtualMachine resource. That single decision collapses two stacks into one: the same scheduler, the same network fabric and the same storage layer serve your containers, your server VMs and your virtual desktops.

The problem it solves. Most estates run two parallel platforms — a proprietary hypervisor for VMs and Kubernetes for containers — staffed, licensed and operated separately. The economics of that split changed sharply, and not in your favour.

  • Licensing upheaval and renewal shock — per-socket perpetual licences gave way to per-core subscription bundles, and renewal quotes that arrive as multiples, not increments.
  • Two stacks to staff and operate — a hypervisor team and a Kubernetes team, two upgrade calendars, two backup tools, two networking models.
  • VDI appliances that are costly and rigid — desktops locked to a proprietary broker and a hardware appliance, expensive to scale and hard to keep inside EU jurisdiction.
  • Lock-in to a proprietary hypervisor — VM formats, management APIs and tooling that only run on one vendor's platform, so the cost of leaving rises every year you stay.
  • Legacy VMs that can't containerise yet — appliances, monoliths and licensed software will stay VMs for years. They still need a home, just not an expensive one.
  • Modernisation stalls on the all-or-nothing leap — "containerise everything" is a multi-year programme few can fund at once. You need a path where VMs and containers coexist now.
bash — virtctl
$ kubectl get vm -n desktops
NAME             AGE   STATUS    READY
win11-pool-014   21d   Running   True
win11-pool-015   21d   Running   True
cad-gpu-03       9d    Running   True

# drain a host — the guest keeps its session
$ virtctl migrate cad-gpu-03
VM cad-gpu-03 was scheduled to migrate

# requires ReadWriteMany storage (Ceph RWX)

What GRN operates

Run and on-call for the virtualisation platform — the undifferentiated heavy lifting.

  • The KubeVirt control plane (virt-controller, virt-handler, virt-api) on a managed HA Kubernetes
  • The hypervisor hosts: KVM-enabled bare metal with virtualisation extensions and, where ordered, GPUs
  • Storage (Rook Ceph RWX/RWO, OpenEBS NVMe), CDI import, Multus networking and Velero backup plumbing
  • Live-migration orchestration, node maintenance drains and hardware replacement
  • The control-plane SLA, up to 99.99% on dedicated tiers, with named senior engineers

What you operate

Your VMs and desktops, fully in your hands — with full cluster-admin.

  • Your VirtualMachine definitions, guest OS images, desktop pools and instancetypes
  • Guest-OS patching, in-VM software, drivers and licensing (Windows / your distros)
  • Namespaces, RBAC, NetworkPolicy, VLAN attachments and resource quotas
  • Your GitOps pipeline (Argo CD / Flux), CI and image registry for VM templates
  • The decision to leave: export disk images and manifests to any KubeVirt cluster

VMs and containers, one platform — open, with no lock-in. A KubeVirt VM and a container run side by side on the identical cloud-native foundation as our Virtual Private Cloud and Dedicated Private Cloud. The only difference between tiers is the isolation and dedication of the compute beneath them — shared-hardware VPC nodes, or single-tenant bare-metal DPC nodes for regulated, high-security desktops and VMs. KubeVirt is an open-source CNCF project, so nothing about the platform traps you here: your VMs are declarative YAML and portable disk images, not a proprietary appliance format.

Key features

Virtual machines as Kubernetes-native objects.

The VirtualMachine CRD

A declarative VirtualMachine resource defines the guest; KubeVirt reconciles it into a running VirtualMachineInstance. Start, stop, restart and live-migrate are API operations — not console clicks.

Real QEMU/KVM, not an emulation tax

Guests run on hardware-accelerated KVM under libvirt — the same hypervisor technology underneath most Linux virtualisation — for near-native performance, not slow software emulation.

Scheduled like a pod

Each VM runs in a virt-launcher pod, so node selection, taints, tolerations, affinity, quotas and priority all apply — VMs and containers compete for the same fleet on the same rules.

Instancetypes & preferences

Reusable VirtualMachineInstancetype and preference objects separate sizing (CPU/memory) from guest tuning — so "a medium Windows desktop" is one named, version-controlled shape.

Managed as YAML & GitOps

VMs live in Git like everything else. Define, review and roll out desktop fleets and server VMs through Argo CD or Flux — the same pipeline that ships your containers.

Coexistence with containers

A legacy database VM can sit in the same namespace as the containerised services that call it, sharing one network and one set of NetworkPolicies — no gateway between two platforms.

Platform capabilities

The OpenShift and KubeVirt capabilities powering your VMs and desktops.

Virtual Desktop Infrastructure, on the same platform

A virtual desktop is just a VM with a display protocol and a connection broker in front of it. KubeVirt makes that desktop a Kubernetes object — so the same platform that runs your server VMs runs Windows and Linux desktops for your users, GPU-accelerated where the work demands it, on infrastructure that stays in the EU.

Windows & Linux desktops

Full desktop guests — Windows or your preferred Linux — running as KubeVirt VMs, provisioned from version-controlled templates and instancetypes rather than hand-built golden images.

Pooled & on-demand

Desktop pools scale with demand on the shared fleet — spin up seasonal capacity, contractor desktops or a training lab as declarative resources, then tear them down.

GPU-accelerated

Attach a GPU to a desktop for CAD, 3D, GIS, video and graphics workloads — the engineering workstation experience, delivered from a sovereign data centre rather than a tower under a desk.

On the desktop broker and protocol, the honest version. KubeVirt provides the desktop VMs and console access; the user-facing connection broker and remote-display protocol (session brokering, gateway, client) is the piece to confirm for a production VDI rollout. We will tell you precisely what GRN provides versus what you bring or we contract as an add-on. Pending validation

Move running VMs without dropping the session

The operational test of any virtualisation platform is what happens on a Tuesday-night patch window. KubeVirt live-migrates a running guest off a host so you can drain it for maintenance — and reschedules VMs when a host fails. There is one hard requirement, and we state it plainly.

Live migration on RWX storage

A running VM moves between hosts with its memory state intact, for zero-downtime node drains and maintenance. This requires ReadWriteMany storage so both hosts reach the disk: we provide it via Rook Ceph RWX. Confirm GA

HA reschedule on node failure

If a host dies, affected VMs are rescheduled onto healthy nodes — a dead host becomes an event, not an outage, the same way it would for a container workload.

Eviction strategies

Per-VM eviction strategy (LiveMigrate or shutdown) tells the platform how to handle a node drain — migrate the stateful guests, cleanly stop the disposable ones.

The requirement, stated up front. Live migration needs shared ReadWriteMany storage so the source and destination hosts both reach the VM's disk — this is a property of how QEMU/KVM migration works, not a GRN limitation. We satisfy it with Ceph RWX. VMs on local-NVMe boot disks cannot live-migrate; they HA-reschedule with a restart instead. Choose the storage class per workload and you choose the failure behaviour with it.

GPUs for desktops and compute VMs

Graphics and compute desktops need a real GPU, not a software framebuffer. KubeVirt exposes host GPUs to guests two ways — full passthrough for a dedicated card, or mediated devices (NVIDIA vGPU) to slice one physical GPU across several desktops. We state which we offer rather than implying both.

GPU passthrough

A whole physical GPU is bound to a single VM via VFIO for maximum, dedicated performance — for heavy CAD, rendering, simulation or a GPU compute VM that needs the entire card.

vGPU via mediated devices

One physical GPU is partitioned into mediated devices (NVIDIA vGPU) and shared across several desktops — the cost-efficient route for a fleet of accelerated VDI seats. Confirm mode

GPU node pools, stated honestly. GPU desktops and compute VMs schedule onto dedicated GPU node pools. The exact NVIDIA models, the choice between passthrough and licensed vGPU, and per-seat sizing depend on current hardware — tell us the workload and we will confirm what is available. Confirm GPU models

VM lifecycle, managed end to end

Import

CDI / DataVolume imports VMDK, qcow2 or raw disks into a Ceph volume

Template

Capture it as a reusable instancetype + preference your team can stamp out

Operate

Run via kubectl / virtctl and Argo CD / Flux; we keep the hosts healthy

Back up

Scheduled Velero backups and CSI volume snapshots to your RPO/RTO

Migrate

Drain hosts with live migration on RWX, grow pools, move to GPU nodes

Exit

Export disk image and YAML to any KubeVirt cluster — a copy, not a contract

Day-2, addressed honestly. Host patching, KubeVirt upgrades and hardware replacement are ours, run with live migration so guests stay up where storage allows. Guest-OS patching, in-VM software and licensing stay yours — KubeVirt does not manage what runs inside the VM, and we will not pretend it does. Backups are only as good as their last successful restore, so we size and test them against the RPO/RTO you give us. Confirm cadence

Isolation at the hardware boundary, layered

A VM's strongest property is its isolation boundary: a guest runs behind the KVM hardware-virtualisation line, with its own kernel, not a shared one. KubeVirt keeps that boundary and adds the Kubernetes primitives your team already audits against.

  • KVM hardware-virtualisation boundary — each guest runs its own kernel, isolated from the host
  • sVirt / SELinux confinement of each virt-launcher process and its QEMU instance
  • RBAC across VMs, namespaces and resources, with full audit logging
  • Default-deny micro-segmentation between VMs and pods via standard NetworkPolicy
  • Identity integration via OAuth / OIDC — bring your own IdP
  • TLS issued and rotated automatically via cert-manager
  • Encrypted storage at rest on Ceph; Secrets with encryption at rest
  • Single-tenant bare-metal (DPC) node pools for the strongest hardware + kernel + network boundary

From VMware to cloud-native, without the big bang

The fear is a forced rewrite. The reality should be a phased move: bring the VMs across as VMs, run them next to your containers, and modernise the ones worth modernising on your own timeline. KubeVirt is the bridge that makes coexistence the default, not the exception.

  • Migrate from VMware / vSphere — move workloads off vSphere with the Migration Toolkit for Virtualization (Forklift), which imports VMs and their disks into KubeVirt, or import disk images directly via CDI. Pending validation
  • Phased coexistence — run migrated VMs and new containers in the same cluster, on the same network, behind the same policies. Nothing forces you to containerise a workload before it is ready.
  • The strangler pattern — peel functionality off a legacy VM into containers one service at a time, with the VM and its replacements side by side. Modernise incrementally; never schedule a single high-risk cutover.

On compliance, the honest version. The platform runs under EU-only data residency with a signed DPA and no US Cloud Act exposure — the substantive part of most regulated requirements, and a real advantage for desktops handling personal data. We will support PCI-DSS and HIPAA-aligned, NIS2-ready deployments on dedicated, isolated infrastructure — but we do not claim certifications we do not hold. Tell us your compliance scope and we will tell you precisely what we can and cannot attest to.

Benefits

The operational and commercial differences you can verify.

Sovereign & secure

EU-owned infrastructure under Dutch jurisdiction — not a US hyperscaler's "European region", which stays subject to the US Cloud Act regardless of where the disk images sit. Your desktops and VM data stay in the EU, with KVM hardware isolation and a signed DPA.

Affordable & transparent

No per-socket, per-core or per-VM hypervisor licence. Storage is a published €/GB-month, networking functions are included free, and annual commitments take 10% off. The Broadcom renewal shock is replaced by an open stack with a price you can read off a page.

Sustainable

Hosted in the Netherlands on 100% renewable solar energy, with server heat reused to warm nearby buildings and peak-shaving to ease grid congestion. Sustainability with a mechanism behind it, not a logo.

Open source, no hypervisor lock-in

KubeVirt is a CNCF project and your VMs are portable disk images plus declarative YAML. There is no proprietary VM format or vendor-only management API in the path — which is the whole argument for moving off a closed hypervisor.

One operational surface

One scheduler, one network fabric, one storage layer, one backup tool and one upgrade calendar for VMs, desktops and containers — instead of two parallel platforms staffed and licensed separately.

Contractual SLA

The control-plane SLA scales with tier, up to a contractual 99.99% on dedicated infrastructure — backed by redundant control-plane nodes, an etcd quorum and live migration for maintenance.

Architecture

A layered, cloud-native stack — every layer a portable component.

Your VMs, desktops and containers on top, KVM-enabled renewable-powered hosts at the bottom. Every layer is a named component you could reproduce on any KubeVirt cluster; none of it is a black box you can only run here.

VMs, desktops & containers

Your workloads
You operate

Windows and Linux VMs, pooled virtual desktops and containers — all described as standard Kubernetes resources, deployed via kubectl, virtctl or Argo CD / Flux against one API.

KubeVirt virt control plane

QEMU/KVM · libvirt · on Kubernetes
GRN-managed

KubeVirt's virt-controller, virt-handler and virt-api turn a VirtualMachine CRD into a running VirtualMachineInstance — a QEMU/KVM guest under libvirt, scheduled into a pod like any other workload. CDI imports and clones disk images.

Networking fabric

Multus · bridge / VLAN · SR-IOV · MetalLB
GRN-managed

Multus attaches multiple NICs to a VM: pod-network for cloud-native traffic, plus bridge, VLAN or SR-IOV attachments for line-rate, layer-2 reachability your VMs expect. MetalLB advertises services and desktop endpoints — included free.

Storage layer

CDI · Ceph RWX/RWO · OpenEBS NVMe · Velero
GRN-managed

CDI / DataVolumes import VMDK and qcow2 disks; Rook Ceph provides ReadWriteMany volumes for live migration and ReadWriteOnce for boot disks; OpenEBS serves local NVMe for latency-sensitive guests; Velero handles VM snapshots and backup.

Hosts & hardware

Netherlands · KVM · GPUs · 100% renewable
GRN-managed

Bare-metal hosts with CPU virtualisation extensions (Intel VT-x / AMD-V) and, where ordered, NVIDIA GPUs for VDI and compute VMs — EU-owned, in the Netherlands, on 100% renewable solar with server-heat reuse.

Every layer uses standard, portable components — KubeVirt, Ceph, Multus, Velero — nothing proprietary you cannot reproduce on another Kubernetes cluster.

Common use cases

What teams run on it.

VMware migration / Broadcom exit

Move VMs off vSphere onto an open, Kubernetes-native stack with no per-core hypervisor licence — replacing a renewal shock with a published price.

VDI / remote desktops

Windows and Linux virtual desktops for staff and contractors, pooled and provisioned from templates, with data kept inside EU jurisdiction.

Hybrid VM + container apps

A legacy database or appliance VM running next to the containerised services that call it — one namespace, one network, one set of policies.

Legacy app hosting

Licensed or unportable software that will stay a VM for years — given a modern, automated home without a forced rewrite.

GPU workstations

CAD, 3D, design and AI workstations as GPU-accelerated desktops — the power of a tower under the desk, delivered from a sovereign data centre.

Regulated / sovereign VM workloads

Finance, healthcare and government VMs and desktops on EU-sovereign, single-tenant infrastructure with a signed DPA — subject to your compliance scope. Review

Technical highlights

The detail a virtualisation engineer actually evaluates.

Items tagged for review are confirmed against a live cluster before publishing — we would rather leave a value open than print one we cannot stand behind.

VirtualisationKubeVirt (QEMU/KVM under libvirt) on managed Kubernetes
Guest OS supportWindows & Linux VMs Confirm matrix
VM definitionVirtualMachine / VirtualMachineInstance CRDs
SizingInstancetypes + preferences; cx1 / m1 / n1 / o1 / rt1 families
Live migrationRequires ReadWriteMany (Ceph RWX) Confirm GA
Storage classesCeph RWX / RWO, OpenEBS local NVMe, Ceph S3
Disk import formatsVMDK, qcow2, raw via CDI / DataVolume
NetworkingMultus multi-NIC, bridge / VLAN, SR-IOV, MetalLB
GPUPassthrough (VFIO) and/or vGPU (mediated devices) Confirm mode
Backup / DRVelero, CSI snapshots, cross-region replication
Migration toolingMigration Toolkit for Virtualization (Forklift) Pending validation / CDI import
SecurityKVM isolation, sVirt/SELinux, RBAC, NetworkPolicy
API & automationStandard Kubernetes API, virtctl, GitOps
TenancyShared-hardware (VPC) or single-tenant bare-metal (DPC)
Control-plane SLAUp to 99.99% (tier-dependent)
RegionNetherlands (EU), 100% renewable-powered

Storage for virtual machines

Storage classImplementationBest forPrice
Shared file (RWX)Rook Ceph FSLive-migratable VM & desktop disks€ 0.044 / GB-mo
Block (RWO)Rook Ceph RBDGeneral VM boot & data disks€ 0.044 / GB-mo
Local NVMeOpenEBS LocalVolumeLatency-sensitive guests (HA-reschedule)€ 0.044 / GB-mo
Disk import / cloneCDI + DataVolumeImporting VMDK / qcow2 / raw imagesIncluded
S3 objectCeph ObjectBucketClaimImage registries, artefacts, archives€ 0.044 / GB-mo
Cross-region replicationCeph VolumeReplicationGeo-redundancy / DR for VMs€ 0.0465 / GB-mo
Snapshots & backupVelero + CSI snapshotsScheduled VM backup to meet RPO/RTO€ 0.008 / GB-mo

Networking for virtual machines

FunctionImplementationPrice
Multi-NIC attachmentMultus CNI (additional NetworkAttachmentDefinitions)Included
Layer-2 / bridge & VLANBridge / VLAN attachments — VMs on your existing subnetsIncluded
Line-rate networkingSR-IOV virtual functions for throughput-bound VMsIncluded
Load balancing / ingress to VMsMetalLB (Layer 2 / BGP)Included
Pod-network & policyCNI + NetworkPolicy (default-deny capable)Included
Public / floating IPv4MetalLB-advertised address€ 3.00 / mo
BYO-IP / BYO-ASN (BGP)MetalLB BGP peering€ 50.00 / mo

Dual-stack IPv4 / IPv6 throughout. All storage classes are dynamically provisioned and expandable. Prices in EUR, ex VAT; 10% discount on annual commitment. Verify current rates on the pricing page before quoting.

Against the incumbents, on the axes that matter

An objective capability comparison against the major virtualisation platforms. Subjective claims ("faster", "simpler") are left out — only things you can check on a product page or in a licence agreement.

Capability GRN.CLOUD KubeVirt Traditional hypervisors Hyperscaler
VMware vSphere / VCFNutanix AHVProxmox VEHyperscaler VMs
Licensing modelNo hypervisor licence; published €/GB + tiersPer-core subscription bundlesPer-core/node subscriptionOpen source; paid support optionalMetered per-VM-hour
Open source / no lock-in KubeVirt, CNCF Proprietary Proprietary AGPL Proprietary platform
VMs + containers unified one control plane~ via Tanzu add-on~ via NKP add-on~ VMs + LXC, not K8s-native~ separate services
Kubernetes-native API VMs as CRDsvCenter APIPrism APIProxmox APICloud-specific API
EU sovereignty (non-US-owned) Netherlands US-owned (Broadcom) US-owned EU-developed (open) US-owned
Live migration on RWX Confirm GA vMotion~ varies / often opaque
GPU passthrough / vGPU Confirm mode vGPU~ passthrough; vGPU manual GPU instances
Pricing transparencyPublished €/GB, flat tiersQuote / bundle-gated~ quote-basedPublic~ complex metering
Managed control-plane SLAUp to 99.99%You operate itYou operate itYou operate itCloud SLA varies
100% renewable-poweredDepends on your DCDepends on your DCDepends on your DC~ varies by region

yes · ~ partial · no. Compiled from public product & pricing pages, June 2026; vendor features and licensing change — verify before quoting.

FAQ

The questions a virtualisation engineer actually asks.

What is KubeVirt?

KubeVirt is an open-source CNCF project that extends Kubernetes to run virtual machines as first-class workloads. It manages QEMU/KVM guests through standard VirtualMachine resources, so the same cluster schedules VMs, virtual desktops and containers on one control plane. GRN runs it on its managed OKD/OpenShift-based platform.

Are these real VMs or just containers?

Real VMs. Each guest is a full QEMU/KVM virtual machine with its own kernel and virtual hardware, running under libvirt — not a container with a VM-shaped label. KubeVirt wraps that guest in a virt-launcher pod so Kubernetes can schedule and manage it, but the isolation boundary is the hardware-virtualisation line, exactly as in a traditional hypervisor.

Is Windows supported?

Yes — KubeVirt runs Windows guests as well as Linux, which is what makes it viable for VDI and for legacy app hosting. You remain responsible for Windows licensing and in-guest patching.

How does live migration work, and what does it require?

A running VM moves between hosts with its memory state preserved, for zero-downtime maintenance. It requires ReadWriteMany storage so both the source and destination host can reach the disk — we provide that via Rook Ceph RWX. VMs on local-NVMe disks cannot live-migrate; they HA-reschedule with a restart instead.

Can I migrate off VMware / vSphere?

Yes. The cleanest path is the Migration Toolkit for Virtualization (Forklift), which imports vSphere VMs and disks into KubeVirt; the always-available path is importing your disk images directly with CDI. We will confirm which we run as a managed capability for your estate rather than promise a one-click conversion.

How do I get my existing VM disks in?

The Containerized Data Importer (CDI) imports and clones disk images — VMDK, qcow2 or raw — into Ceph-backed DataVolumes that your VMs boot from. Importing is the same declarative workflow as everything else: describe the source, and CDI provisions the disk.

Is GPU passthrough or vGPU available?

KubeVirt supports both full GPU passthrough (a whole card bound to one VM via VFIO) and vGPU via mediated devices (NVIDIA vGPU, one card shared across desktops). Which GRN offers, on which GPU models, depends on current hardware — tell us the workload and we will confirm.

How do VMs get onto my VLANs?

Multus attaches additional NICs to a VM beyond the pod network — bridge or VLAN attachments put a guest directly on your existing layer-2 subnets, and SR-IOV virtual functions give throughput-bound VMs line-rate networking. It is included free.

How are VM backup and DR handled?

Scheduled Velero backups and CSI volume snapshots capture VM disk state; cross-region replication via Ceph VolumeReplication covers geo-redundancy. Backup storage is €0.008/GB-month and cross-region replication €0.0465/GB-month, sized to your RPO/RTO targets.

Can I manage VMs with kubectl and GitOps?

Yes — that is the point. VMs are declarative YAML, so kubectl, virtctl and Argo CD / Flux manage them exactly as they manage containers. Define a desktop fleet in Git, review it as a pull request, and roll it out through your existing pipeline.

What is the performance versus a bare hypervisor?

Guests run on hardware-accelerated KVM under libvirt — the same technology underneath most Linux virtualisation — so compute is near-native, not emulated. The KubeVirt layer orchestrates the VM; it does not sit in the data path of CPU or memory. Use SR-IOV and local NVMe where a workload is network- or disk-bound.

How does licensing and cost compare to VMware?

There is no per-socket, per-core or per-VM hypervisor licence. You pay for the compute tier and published €/GB-month storage, with networking functions included and 10% off on annual commitment — so the Broadcom renewal multiple is replaced by a price you can read off the pricing page. KubeVirt itself is open source.

Will I be locked into GRN?

No. KubeVirt is an open CNCF project and your VMs are portable disk images plus declarative YAML — export them to any KubeVirt cluster. There is no proprietary VM format or vendor-only management API in the path, which is the whole argument for moving off a closed hypervisor in the first place.

What is the SLA?

The control-plane SLA scales with tier, up to a contractual 99.99% on dedicated infrastructure — backed by redundant control-plane nodes, an etcd quorum and live migration for maintenance. Guest-level availability also depends on your storage choice and eviction strategy, which we design with you.

Is this really sovereign, or "sovereignty-washing"?

Genuinely EU-owned infrastructure under Dutch jurisdiction — not a US hyperscaler's "European region", which remains subject to the US Cloud Act regardless of where the desktops and disk images live. EU-only residency, a signed DPA, and no US ownership in the chain.

Your open, sovereign alternative to a closed hypervisor.

Run VMs and virtual desktops next to your containers on KubeVirt — an open, Kubernetes-native platform with no per-core licence — or talk to our engineers about a phased exit from VMware without a big-bang rewrite.

100% renewable energy · EU data residency · No US Cloud Act exposure · Open source, no hypervisor lock-in