---
title: "Why we chose KubeVirt for our VM sandboxes"
description: "BoxCompute chose KubeVirt for its VM sandboxes because workloads need a real Linux machine with a guest kernel, systemd, and machine-level workflows that process-oriented environments do not fully provide. KubeVirt adds VM resource types and controllers to Kubernetes, while launcher Pods run QEMU/KVM and the guest on a worker. The arrangement keeps placement, lifecycle, permissions, storage, and cleanup within the Kubernetes model, avoiding a separate VM management platform, although resource accounting and readiness still require sandbox-specific work. The post stresses that full virtualization does not automatically provide security: the platform still needs deliberate controls for host access, guest traffic, credentials, persistence, and cleanup after failures."
---

# Why we chose KubeVirt for our VM sandboxes

[Boxcompute](https://yomu.fyi/company/boxcompute) · boxy · Sep 15, 2026

**Type:** Explainer

## Summary

BoxCompute chose KubeVirt for its VM sandboxes because workloads need a real Linux machine with a guest kernel, systemd, and machine-level workflows that process-oriented environments do not fully provide. KubeVirt adds VM resource types and controllers to Kubernetes, while launcher Pods run QEMU/KVM and the guest on a worker. The arrangement keeps placement, lifecycle, permissions, storage, and cleanup within the Kubernetes model, avoiding a separate VM management platform, although resource accounting and readiness still require sandbox-specific work. The post stresses that full virtualization does not automatically provide security: the platform still needs deliberate controls for host access, guest traffic, credentials, persistence, and cleanup after failures.

## Context

The decision is framed around agent workspaces that may need background services, service managers, normal Linux boot behavior, and other machine-level workflows. Kubernetes was already the foundation for workload management, so the team wanted VM lifecycle management to remain within that ecosystem rather than coordinate a separate platform.

## Approach / What changed

KubeVirt supplies Kubernetes VM resource types, controllers, and lifecycle reconciliation. A VirtualMachine describes the desired machine and lifecycle, a VirtualMachineInstance represents an instance, and a launcher Pod runs QEMU/KVM on a worker. Kubernetes handles placement and surrounding management, while the guest Linux system runs the workload; sandbox-specific code still defines readiness, security, persistence, and cleanup.

## Takeaways

- KubeVirt provides a real guest kernel and systemd environment, which supports machine-level workflows such as starting services, inspecting logs, and changing configuration.
- KubeVirt keeps VM placement and lifecycle connected to Kubernetes resources, controllers, scheduling, policy, networking, and storage interfaces instead of adding a separate VM management API.
- The Kubernetes and guest boundaries do not complete the sandbox design: resource overhead, elevated host access, credential protection, guest traffic restrictions, persistence, and failure cleanup remain operational responsibilities.

## FAQ

### Why use full VMs instead of ordinary Linux containers for these sandboxes?

Containers isolate processes but share the host kernel, while a VM supplies its own guest kernel and can boot a complete Linux environment with systemd. The choice targets workloads that need machine-level behavior, not only individual commands.

### What does KubeVirt contribute beyond QEMU/KVM?

QEMU/KVM runs the virtual machine, while KubeVirt connects it to Kubernetes through VM resource types, controllers, launcher Pods, scheduling, and lifecycle reconciliation. This keeps placement and VM management in the Kubernetes model.

### Does KubeVirt provide a complete security model for the sandbox?

No. KubeVirt adds controllers and node-level components, some requiring elevated host access, and the sandbox still needs controls for credentials, guest traffic, persistence, authentication, and cleanup after failures.

**Tags:** [Kubernetes](https://yomu.fyi/topic/kubernetes), [KubeVirt](https://yomu.fyi/topic/kubevirt), [Linux](https://yomu.fyi/topic/linux), [QEMU/KVM](https://yomu.fyi/topic/qemu-kvm)

- Source: [Boxcompute](https://boxcompute.ai/blog/why-we-chose-kubevirt)
- Source URL: https://boxcompute.ai/blog/why-we-chose-kubevirt
- Ingested by Yomu: 2026-09-18T03:35:00.945Z

[Read original post](https://boxcompute.ai/blog/why-we-chose-kubevirt)