VirtualBox KVM Public Release

Original Article ↗ Hacker News Discussion ↗

A new KVM-based backend for VirtualBox lets Linux users run VirtualBox VMs on the in-kernel KVM hypervisor instead of Oracle’s own vboxdrv module, promising better compatibility with new kernels, access to modern CPU virtualization features and potentially improved security. Commenters weigh this against existing KVM/front-end tools like virt‑manager, praising VirtualBox’s polished UI, feature set (snapshots, guest integration, OVA/OVF import) and new support for VFIO/GPU passthrough, while voicing concern over Oracle’s licensing practices and the long-term maintainability of a third‑party fork. Many see it as a way to combine KVM’s robustness — widely used in cloud environments — with VirtualBox’s usability, especially on bleeding‑edge Linux systems.

Overview of VirtualBox-KVM Release

  • Fork of VirtualBox that replaces the proprietary vboxdrv kernel module with Linux’s built‑in KVM hypervisor backend.
  • Aims to keep VirtualBox’s UI, device model, and features (snapshots, suspend/resume, multi‑monitor, shared clipboard, USB, etc.) while using KVM for CPU virtualization.
  • Existing VirtualBox VMs (.vbox + .vdi) can be switched between the original and KVM backends.

What KVM Is (vs. Other Approaches)

  • KVM = Kernel-based Virtual Machine, the standard Linux hypervisor API using hardware virtualization (Intel VT, AMD‑V).
  • Different from User Mode Linux: UML ran a modified kernel as a userspace process, slower and less secure; largely obsolete except as curiosity.
  • Different from the “KVM switch” (keyboard-video-mouse hardware); just name collision.

Security & Performance Considerations

  • KVM code is widely used in clouds (e.g., by large providers) and heavily reviewed; VirtualBox’s vboxdrv is seen as lower‑quality with risky design (userspace code upload, lots of emulation in kernel).
  • KVM supports newer CPU virtualization features (e.g., APICv/AVIC) that stock VirtualBox lacks.
  • Performance trade-offs:
    • KVM backend tends to win on interrupt‑heavy and modern setups.
    • Stock VirtualBox can be faster for some legacy devices (e.g., SATA) due to in‑kernel emulation.
    • Reported gains around ~10% in some benchmarks, but workload‑dependent.

Features: Passthrough, Nesting, Graphics

  • Experimental VFIO PCI/GPU passthrough via VBoxManage --attach-vfio; demoed with Intel GPUs (SR‑IOV); still rough.
  • Traditional VirtualBox PCI passthrough (via extension pack) is separate and license‑encumbered.
  • 3D/accelerated video adapters work but are described as flaky; not a replacement for full GPU passthrough.
  • Nested virtualization (e.g., Hyper‑V inside a Windows guest) is not yet supported in the KVM backend; on the roadmap with expected modest performance.

Licensing, Oracle, and Upstreaming

  • Project uses the same open‑source VirtualBox OSE license; maintainers plan to clarify this in the README.
  • They do not intend a hard fork; KVM support is a pluggable backend with minimal core changes, and they hope (but do not expect) Oracle will upstream it.
  • Commercial model is support and consulting around KVM/virtualization; no change to Oracle’s proprietary extension pack terms.

Why People Care (or Don’t)

  • Enthusiasts:
    • Like VirtualBox’s “fisher‑price easy” GUI, appliance/OVA/OVF support, and guest integration, but dislike third‑party kernel modules and extension‑pack licensing.
    • See big value on Linux hosts with fast‑moving kernels and immutable distros, where out‑of‑tree modules are painful.
    • Appreciate being able to use VirtualBox side‑by‑side with other KVM tools (qemu, libvirt) now that they share the same hypervisor.
  • Skeptics:
    • Argue that QEMU/KVM with libvirt, virt‑manager, Boxes, or other frontends already solve the problem, and VirtualBox is “too late” or “obsolete.”
    • Some refuse to touch anything Oracle‑branded due to aggressive licensing/auditing around the VirtualBox extension pack and other Oracle products.

GUI and Ecosystem Context

  • Several comments criticize libvirt GUIs (especially virt‑manager) as buggy, limited (e.g., past HiDPI issues, awkward IPv6 configuration, GPU passthrough complexity), and far from VirtualBox’s polish.
  • Others counter that virt‑manager has improved (including IPv6 and HiDPI), already supports many advanced features, and that better GUIs are hard to build without deep virtualization knowledge.
  • Desire expressed for VirtualBox‑like ease on top of KVM, without proprietary or legally risky components.