Split View: [가상화] 09. 가상화 플랫폼 비교: QEMU vs VirtualBox vs VMware vs KubeVirt

[Virtualization] 09. Virtualization Platform Comparison: QEMU vs VirtualBox vs VMware vs KubeVirt

• Introduction
• Platform Overview
  • QEMU/KVM
  • VirtualBox
  • VMware ESXi
  • KubeVirt
• Comprehensive Comparison Table
• GPU Support Comparison
  • Detailed GPU Feature Comparison
  • GPU Passthrough Method Comparison
  • vGPU Support Comparison
• Performance Comparison
  • CPU Overhead
  • I/O Performance
  • Memory Overhead
• Management and Operations
  • Management Complexity
  • Automation Level
• Licensing and Cost
  • License Model Comparison
  • TCO (Total Cost of Ownership) Considerations
• Decision Guide
  • When to Choose Each Platform
    • Choose QEMU/KVM when:
    • Choose VirtualBox when:
    • Choose VMware ESXi when:
    • Choose KubeVirt when:
  • Recommended Platform by Workload
• Migration Paths
  • VMware to KubeVirt
  • VirtualBox to QEMU/KVM
• Future Outlook
  • Development Direction by Platform
• Conclusion

Introduction

Choosing a virtualization platform significantly impacts infrastructure performance, cost, and operational complexity. This post compares QEMU/KVM, VirtualBox, VMware ESXi, and KubeVirt across multiple dimensions.

Platform Overview

QEMU/KVM

• Type 1 hypervisor (KVM) built into the Linux kernel + hardware emulator (QEMU)
• Open source (GPL v2)
• Managed via libvirt, virsh, virt-manager

VirtualBox

• Type 2 hypervisor managed by Oracle
• Specialized for desktop virtualization
• Cross-platform (Windows, macOS, Linux)

VMware ESXi

• Enterprise Type 1 hypervisor by VMware (Broadcom)
• Centralized management through vCenter Server
• Commercial license

KubeVirt

• Kubernetes-native VM orchestration
• Uses QEMU/KVM internally
• CNCF Incubating project

Comprehensive Comparison Table

GPU Support Comparison

Detailed GPU Feature Comparison

GPU Passthrough Method Comparison

QEMU/KVM:
+----------+     +--------+     +--------+
| IOMMU    | --> | VFIO   | --> | VM     |
| config   |     | bind   |     | GPU    |
+----------+     +--------+     +--------+
Manual setup required, maximum flexibility

VMware ESXi:
+----------+     +------------+     +--------+
| ESXi     | --> | DirectPath | --> | VM     |
| config   |     | I/O        |     | GPU    |
+----------+     +------------+     +--------+
Easy setup via vCenter UI

KubeVirt:
+----------+     +-------------+     +---------+     +--------+
| GPU      | --> | VFIO        | --> | Sandbox | --> | VM     |
| Operator |     | Manager     |     | Plugin  |     | GPU    |
+----------+     +-------------+     +---------+     +--------+
Automated setup, K8s API integrated

VirtualBox:
+----------+
| Not      |
| supported|
+----------+
No GPU passthrough support

vGPU Support Comparison

QEMU/KVM:
- Requires NVIDIA vGPU Manager (licensed)
- Mediated Device (MDEV) framework
- Manual MDEV creation and management

VMware ESXi:
- Best-in-class enterprise vGPU support
- vGPU profile management via vCenter
- Full MIG-backed vGPU support
- DRS (Distributed Resource Scheduler) integration

KubeVirt:
- Automated via GPU Operator
- Scheduling via Sandbox Device Plugin
- Declarative management via ClusterPolicy

VirtualBox:
- vGPU not supported

Performance Comparison

CPU Overhead

I/O Performance

Performance figures are percentages relative to bare metal.

Memory Overhead

Management and Operations

Management Complexity

Easy                                                    Complex
|------|------|------|------|------|------|------|------|
       VBox          VMware       QEMU/KVM     KubeVirt

VirtualBox: GUI-centric, create VMs with a few clicks
VMware: vCenter web UI, intuitive enterprise management
QEMU/KVM: CLI/XML config, steep learning curve
KubeVirt: YAML/kubectl, K8s knowledge required

Automation Level

Licensing and Cost

License Model Comparison

TCO (Total Cost of Ownership) Considerations

Annual Cost (10 GPU servers, estimated)

QEMU/KVM:
  Hardware: XXXX
  Software: 0 (open source)
  vGPU license: Separate
  Operations staff: High (specialists needed)

VMware vSphere:
  Hardware: XXXX
  Software: vSphere + vCenter licenses
  vGPU license: Separate
  Operations staff: Medium (UI-based management)

KubeVirt:
  Hardware: XXXX
  Software: 0 (open source)
  vGPU license: Separate
  Operations staff: High (K8s specialists needed)
  Note: Includes K8s cluster operation costs

Decision Guide

When to Choose Each Platform

Choose QEMU/KVM when:

• Maximum performance is needed on Linux
• Near-native performance via GPU passthrough is required
• You want to reduce costs with open source
• High customization is needed

Choose VirtualBox when:

• Desktop virtualization for dev/test
• Cross-platform support is needed
• GPU acceleration is not required
• Quick and simple VM creation is needed

Choose VMware ESXi when:

• Enterprise production environments
• Best-in-class vGPU support is needed
• Advanced features like vMotion, DRS are required
• Vendor technical support is important

Choose KubeVirt when:

• You already operate Kubernetes infrastructure
• You want unified container and VM management
• GitOps/IaC-based VM management is needed
• You are planning migration from VMware

Recommended Platform by Workload

Migration Paths

VMware to KubeVirt

1. Export VM disk (VMDK format)
   |
   v
2. Convert to QCOW2 with qemu-img
   qemu-img convert -f vmdk -O qcow2 vm-disk.vmdk vm-disk.qcow2
   |
   v
3. Import image via CDI (HTTP or S3)
   |
   v
4. Write KubeVirt VM CRD
   |
   v
5. Verify network/storage mappings
   |
   v
6. Start VM and validate

VirtualBox to QEMU/KVM

1. Convert VDI disk to QCOW2
   qemu-img convert -f vdi -O qcow2 disk.vdi disk.qcow2
   |
   v
2. Create VM with virsh/virt-manager
   |
   v
3. Install virtio drivers (for Windows)
   |
   v
4. Reconfigure networking

Future Outlook

Development Direction by Platform

Conclusion

Each virtualization platform has its own strengths and limitations. For performance-focused workloads choose QEMU/KVM, for desktop environments choose VirtualBox, for enterprise environments choose VMware, and for cloud-native environments choose KubeVirt.

The recent Broadcom acquisition of VMware and associated license changes have significantly increased interest in open-source alternatives like KubeVirt.

In the next post, we will look at the future of virtualization technology, covering next-generation topics like confidential computing, GPU disaggregation, and WebAssembly.