Run your VMs and virtual 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 a credible, open exit from VMware and Broadcom licensing, and a sovereign home for Windows & Linux VDI — without a big-bang rewrite. Bridge traditional virtualisation with cloud-native: coexist first, modernise on your timeline. EU-owned, in the Netherlands, on 100% renewable power.
KubeVirt Virtualisation & VDI
VMs, desktops & containers, one platform · up to 99.99% SLA
- VirtualisationKubeVirt (QEMU/KVM) on Kubernetes
- GuestsWindows & Linux VMs
- DesktopsVDI, GPU-accelerated
- Live migrationYes — on RWX storage Confirm GA
- GPUPassthrough / vGPU Confirm mode
- StorageCeph (RWX) + NVMe via CDI
- SLAUp to 99.99% (tier-dependent)
Managed with standard kubectl & GitOps
EU-owned — Netherlands
SLA up to 99.99%
100% renewable-powered
Built on three guarantees
The same three guarantees behind every GRN product — here, applied to your VMs and virtual desktops. They are the things a proprietary hypervisor and a US hyperscaler cannot match on all three axes at once.
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 Data Processing Agreement.
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.
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. We operate the virtualisation control plane and the plumbing; you operate the VMs and desktops as declarative YAML. Here is exactly where the line sits.
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
VirtualMachinedefinitions, 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.
Why teams are rethinking the hypervisor
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 shockPer-socket perpetual licences gave way to per-core subscription bundles — and renewal quotes that arrive as multiples, not increments. The budget line you planned for is no longer the budget line you get.
- Two stacks to staff and operateA hypervisor team and a Kubernetes team, two upgrade calendars, two backup tools, two networking models — double the operational surface for one set of workloads.
- VDI appliances that are costly and rigidTraditional VDI stacks lock desktops to a proprietary broker and a hardware appliance — expensive to scale, awkward to automate and hard to keep inside EU jurisdiction.
- Lock-in to a proprietary hypervisorVM 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 yetPlenty of workloads — appliances, monoliths, licensed software — will stay VMs for years. They still need a home, just not one that costs a fortune.
- Modernisation stalls on the all-or-nothing leap“Containerise everything” is a multi-year programme few can fund at once — so modernisation never starts. You need a path that lets VMs and containers coexist now.
Platform architecture
A layered, cloud-native stack — your VMs, desktops and containers on top, KVM-enabled renewable-powered hosts at the bottom. Every layer is a portable, named component you could reproduce on any KubeVirt cluster; none of it is a black box you can only run here.
Windows & 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’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.
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.
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.
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.
Virtual machines as Kubernetes-native objects
A KubeVirt VM is not a container pretending to be a VM. It is a real QEMU/KVM guest with its own kernel, its own virtual hardware and a full guest OS — wrapped in a Kubernetes object so the same scheduler, RBAC and GitOps workflow govern it as govern your containers.
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 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.
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.
Disks and networks built for VMs
VMs make heavier demands than containers: bootable disk images imported from your existing estate, ReadWriteMany volumes for migration, and real layer-2 networking with VLANs. Every function below uses a standard, named component and is billed transparently.
Storage for virtual machines
| Storage class | Implementation | Best for | Price |
|---|---|---|---|
| Shared file (RWX) | Rook Ceph FS | Live-migratable VM & desktop disks | € 0.044 / GB-mo |
| Block (RWO) | Rook Ceph RBD | General VM boot & data disks | € 0.044 / GB-mo |
| Local NVMe | OpenEBS LocalVolume | Latency-sensitive guests (HA-reschedule) | € 0.044 / GB-mo |
| Disk import / clone | CDI + DataVolume |
Importing VMDK / qcow2 / raw images | Included |
| S3 object | Ceph ObjectBucketClaim |
Image registries, artefacts, archives | € 0.044 / GB-mo |
| Cross-region replication | Ceph VolumeReplication |
Geo-redundancy / DR for VMs | € 0.0465 / GB-mo |
| Snapshots & backup | Velero + CSI snapshots | Scheduled VM backup to meet RPO/RTO | € 0.008 / GB-mo |
Networking for virtual machines
| Function | Implementation | Price |
|---|---|---|
| Multi-NIC attachment | Multus CNI (additional NetworkAttachmentDefinitions) |
Included |
| Layer-2 / bridge & VLAN | Bridge / VLAN attachments — VMs on your existing subnets | Included |
| Line-rate networking | SR-IOV virtual functions for throughput-bound VMs | Included |
| Load balancing / ingress to VMs | MetalLB (Layer 2 / BGP) | Included |
| Pod-network & policy | CNI + NetworkPolicy (default-deny capable) |
Included |
| Public / floating IPv4 | MetalLB-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.
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
The interesting question about a virtualisation platform is not how you create the first VM — it is who owns the maintenance window, the backup that has to restore, and the migration off your old hypervisor. Here is the lifecycle we operate, declaratively.
Import / Provision
Import an existing disk with CDI / DataVolume, or provision fresh from a template — VMDK, qcow2 or raw, cloned into a Ceph volume.
Template
Capture the result as a reusable instancetype + preference — a named, version-controlled VM or desktop shape your team can stamp out.
Operate (GitOps)
Run the VM through kubectl / virtctl and Argo CD / Flux; we keep the virt control plane and hosts healthy underneath.
Snapshot / Backup
Scheduled Velero backups and CSI volume snapshots to your RPO/RTO — consistent disk state you can actually restore.
Live-migrate / Scale
Drain hosts with live migration on RWX, grow desktop pools, or move VMs to dedicated GPU or bare-metal nodes — no rebuild.
Decommission / Exit
Retire a VM cleanly, or export its disk image and YAML to any KubeVirt cluster — the off-ramp is 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 — defence in depth, with nothing you have to take on trust.
- KVM hardware-virtualisation boundary — each guest runs its own kernel, isolated from the host
- sVirt / SELinux confinement of each
virt-launcherprocess 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
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.
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.
No big-bang, and no hand-waving about tooling. The cleanest path off VMware is the Migration Toolkit for Virtualization (Forklift); the always-available path is CDI importing your VMDK/qcow2 disks into Ceph volumes. We will confirm exactly which migration tooling GRN runs as a managed capability versus what you drive yourself — rather than imply a one-click conversion that does not exist for your estate. Pending validation
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 | VMware vSphere / VCF | Nutanix AHV | Proxmox VE | Hyperscaler VMs |
|---|---|---|---|---|---|
| Licensing model | No hypervisor licence; published €/GB + tiers | Per-core subscription bundles | Per-core/node subscription | Open-source; paid support optional | Metered per-VM-hour |
| Open source / no lock-in | Yes (KubeVirt, CNCF) | Proprietary | Proprietary | Yes (AGPL) | Proprietary platform |
| VMs + containers unified | Yes, one control plane | ~ via add-on (Tanzu) | ~ via add-on (NKP) | ~ VMs + LXC, not K8s-native | ~ separate services |
| Kubernetes-native API | Yes — VMs as CRDs | vCenter API | Prism API | Proxmox API | Cloud-specific API |
| EU sovereignty (non-US-owned) | Yes (Netherlands) | US-owned (Broadcom) | US-owned | EU-developed (open) | US-owned |
| Live migration | Yes, on RWX Confirm GA | Yes (vMotion) | Yes | Yes | ~ varies / often opaque |
| GPU passthrough / vGPU | Yes Confirm mode | Yes (vGPU) | Yes | ~ passthrough; vGPU manual | Yes (GPU instances) |
| Pricing transparency | Published €/GB, flat tiers | Quote / bundle-gated | ~ quote-based | Public | ~ complex metering |
| Managed control-plane SLA | Up to 99.99% | You operate it | You operate it | You operate it | Cloud SLA varies |
| 100% renewable-powered | Yes | Depends on your DC | Depends on your DC | Depends on your DC | ~ varies by region |
Compiled from public product & pricing pages, June 2026; vendor features and licensing change — verify before quoting. Yes = supported, ~ = partial/conditional, No = not available.
Technical specifications
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 definition
VirtualMachine/VirtualMachineInstanceCRDs - SizingInstancetypes + preferences;
cx1/m1/n1/o1/rt1families - 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-HW (VPC) or single-tenant bare-metal (DPC)
- Control-plane SLAUp to 99.99% (tier-dependent)
- RegionNetherlands (EU), 100% renewable-powered
What teams run on it
Each of these is well-served because KubeVirt makes a VM a first-class Kubernetes object — on infrastructure that happens to be sovereign and renewable.
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 & 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
The questions a virtualisation engineer actually asks
What is KubeVirt?
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?
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?
How does live migration work, and what does it require?
Can I migrate off VMware / vSphere?
How do I get my existing VM disks in?
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?
How do VMs get onto my VLANs?
How are VM backup and DR handled?
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?
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’s the performance versus a bare hypervisor?
How does licensing and cost compare to VMware?
Will I be locked into GRN?
What is the SLA?
Is this really sovereign, or “sovereignty-washing”?
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
