Overview

---
name: overview
description: "Domain router and cross-technology expert for server virtualization and hypervisor platforms. Covers Type-1 and Type-2 hypervisors, hardware-assisted virtualization, live migration, HA/FT, VM storage, VM networking, technology selection, and V2V migration. Use for \"virtualization\", \"hypervisor\", \"virtual machine\", \"VM\", \"which hypervisor\", \"vSphere vs Proxmox\", \"virtualization comparison\", \"vMotion\", \"live migration\", \"Type-1 vs Type-2\", or when the platform is ambiguous or spans multiple technologies. Do NOT use for platform-specific how-to or troubleshooting once the platform is known — use the matching sibling skill (`vmware`, `proxmox`, `kvm`, `citrix`, `nutanix`, `cloud-vms`). Do NOT use for Hyper-V specifics — that's the `os` plugin's `hyper-v` skill; this skill covers Hyper-V only in cross-platform comparison tables."
license: MIT
---

# Virtualization Domain Overview

This skill is the domain router and cross-technology reference for server virtualization. It covers the full landscape of hypervisor platforms -- from bare-metal enterprise solutions to lightweight open-source stacks and cloud-hosted VM services.

## Technology Router

When a request targets a specific platform, use the matching sibling skill:

| Signal | Skill | Covers |
|---|---|---|
| vSphere, ESXi, vCenter, PowerCLI, vMotion, vSAN, DRS, VCSA, VMFS | `vmware` | VMware vSphere 8.x, 9.x |
| Proxmox, PVE, qm, pct, pvesh, vzdump, PBS, Ceph on Proxmox | `proxmox` | Proxmox VE 8.x, 9.x |
| KVM, QEMU, libvirt, virsh, virt-install, qemu-img, virt-manager | `kvm` | KVM/QEMU with libvirt |
| XenServer, Citrix Hypervisor, XCP-ng, xe, XAPI | `citrix` | Citrix Hypervisor, XCP-ng |
| Nutanix, AHV, Prism, Acropolis | `nutanix` | Nutanix AHV |
| EC2, Azure VM, Compute Engine, cloud VM | `cloud-vms` | AWS/Azure/GCP VMs |
| Hyper-V, Failover Clustering (Windows) | `hyper-v` skill in the `os` plugin | Microsoft Hyper-V |

When the technology is ambiguous or the user asks for a comparison, handle it directly using the cross-technology knowledge below.

## How to Approach Tasks

1. **Identify the platform** -- Look for technology-specific keywords in the request. If found, read the matching sibling skill instead of this one.
2. **Cross-platform questions** -- When the user asks "which hypervisor should I use" or compares platforms, use the comparison framework below.
3. **Architecture questions** -- For generic virtualization concepts (Type-1 vs Type-2, live migration theory, NUMA), answer directly from the foundational knowledge section.
4. **Migration questions** -- For V2V (virtual-to-virtual) conversions between platforms, provide guidance using the migration section.

## Cross-Technology Concepts

### Type-1 vs Type-2 Hypervisors

**Type-1 (Bare-Metal)** -- Runs directly on hardware without a host OS. The hypervisor IS the OS. Lower overhead, better security isolation, production-grade.
- VMware ESXi, Microsoft Hyper-V (Server role), Citrix Hypervisor, Nutanix AHV

**Type-2 (Hosted)** -- Runs as an application on a host OS. Depends on the host for hardware access. Higher overhead, simpler setup, desktop/dev use.
- VMware Workstation/Fusion, Oracle VirtualBox, Parallels Desktop

**Hybrid models** -- KVM is technically Type-1 (kernel module) but runs within a full Linux OS, giving it characteristics of both. Proxmox VE packages KVM inside Debian Linux with a management layer, making it a practical Type-1 platform.

### Hardware-Assisted Virtualization

All modern x86 virtualization depends on CPU extensions:

| Vendor | Extension | CPU Flag | Nested Page Tables |
|---|---|---|---|
| Intel | VT-x | `vmx` | EPT (Extended Page Tables) |
| AMD | AMD-V | `svm` | NPT (Nested Page Tables) |

**What these provide:**
- Ring -1 execution: hypervisor runs below the OS kernel privilege level
- Hardware VM exits: privileged guest instructions trap to hypervisor without binary translation
- EPT/NPT: two-level address translation (guest virtual -> guest physical -> host physical) in hardware, eliminating software shadow page tables
- IOMMU (Intel VT-d / AMD-Vi): direct device assignment (passthrough) to VMs with DMA isolation

**Verification:**
```bash
# Linux
grep -E 'vmx|svm' /proc/cpuinfo
# or
lscpu | grep Virtualization

# ESXi
esxcli hardware cpu global get
```

### Live Migration

Live migration moves a running VM between physical hosts with minimal or zero downtime. All major hypervisors support it:

| Platform | Feature Name | Shared Storage Required | Storage Migration |
|---|---|---|---|
| VMware | vMotion | Yes (or use Storage vMotion) | Storage vMotion |
| Proxmox | Live Migration | Yes (Ceph/NFS) or --with-local-disks | With local disk copy |
| KVM/libvirt | virsh migrate --live | Yes (NFS/Ceph) or --copy-storage-all | copy-storage-all |
| Hyper-V | Live Migration | Yes (CSV/SMB) or storage migration | Storage Live Migration |
| Nutanix AHV | Live Migration | Built-in (distributed storage) | Automatic |

**Common requirements across platforms:**
- Compatible CPU features (same vendor, similar generation)
- Network connectivity between hosts (dedicated migration network recommended)
- Matching virtual network configuration on destination
- Sufficient memory and CPU on destination host

### High Availability and Fault Tolerance

| Capability | VMware | Proxmox | KVM/libvirt | Hyper-V |
|---|---|---|---|---|
| Auto-restart on host failure | vSphere HA | HA Manager | Pacemaker/corosync | Failover Clustering |
| Zero-downtime protection | Fault Tolerance (FT) | Not built-in | Not built-in | Hyper-V Replica (near-zero) |
| Load balancing | DRS | Manual/scripts | Manual/scripts | SCVMM dynamic optimization |
| Quorum mechanism | Datastore heartbeat | Corosync votes | Corosync votes | Witness disk/cloud |
| Minimum nodes for HA | 2 (3 recommended) | 3 (2 + QDevice) | 3 (2 + QDevice) | 2 + witness |

### Storage for Virtual Machines

**Local storage types:**
- Raw/LVM: best performance, no built-in snapshots (except LVM snapshots)
- ZFS: checksumming, snapshots, compression, send/receive; ideal for single-node
- LVM-thin: thin provisioning with snapshot support; good balance
- Directory (qcow2/vmdk files): simplest; snapshot support varies by format

**Shared storage types:**
- NFS: simple, widely supported, good for templates/ISOs; performance depends on network
- iSCSI: block-level, better latency than NFS for random I/O
- Fibre Channel: lowest latency, highest cost, enterprise SAN
- Ceph RBD: distributed, self-healing, scales horizontally; ideal for clusters
- vSAN: VMware-specific hyper-converged; pools local disks across ESXi hosts
- GlusterFS: distributed filesystem; alternative to Ceph for simpler setups

### Networking for Virtual Machines

| Concept | VMware | Proxmox | KVM/libvirt |
|---|---|---|---|
| Virtual switch | vSS / vDS | Linux bridge / OVS | Linux bridge / OVS / macvtap |
| VLAN support | Port group VLAN ID | VLAN-aware bridge | Bridge VLAN filtering |
| SDN/overlay | NSX (GENEVE) | SDN zones (VXLAN/EVPN) | OVS + OVN |
| SR-IOV | Supported | Supported | Supported |
| Bandwidth control | NetIOC (vDS) | tc / OVS QoS | tc / OVS QoS |
| Distributed firewall | NSX DFW | Built-in (iptables/nftables) | nftables / OVS ACLs |

## Technology Comparison

| Criterion | VMware vSphere | Proxmox VE | KVM/QEMU + libvirt |
|---|---|---|---|
| **Type** | Type-1 (ESXi) | Type-1 (KVM on Debian) | Type-1 (kernel module) |
| **License** | Subscription (Broadcom) | AGPL (free) + optional support | GPL (free) |
| **Management UI** | vSphere Client (HTML5) | Web UI (port 8006) | virt-manager / Cockpit |
| **Clustering** | vCenter + DRS/HA | Corosync + HA Manager | Pacemaker + Corosync |
| **Live migration** | vMotion | qm migrate --online | virsh migrate --live |
| **Storage** | VMFS, vSAN, NFS, vVols | ZFS, LVM, Ceph, NFS | LVM, qcow2, NFS, Ceph |
| **Containers** | vSphere Pods (Tanzu) | LXC (first-class) | Podman/Docker (separate) |
| **Automation** | PowerCLI, REST API, govc | pvesh REST API, Terraform | virsh, Terraform, Ansible |
| **GPU passthrough** | vGPU, DDA, GPU-P (2025) | PCIe passthrough, vGPU | VFIO passthrough, MDEV |
| **Best for** | Enterprise, compliance | Homelab to mid-enterprise | Linux-native, embedded |
| **Support model** | Broadcom commercial | Proxmox Server Solutions | Distro vendor (RHEL, Ubuntu) |
| **Learning curve** | Moderate (GUI-driven) | Low-Moderate (web UI) | Higher (CLI/XML-driven) |

### When to Choose What

**VMware vSphere** -- Choose when: enterprise support contracts are required, existing VMware investment, need for vSAN hyper-convergence, regulatory compliance demanding vendor-backed SLAs, Windows-heavy environments with mature backup ecosystem (Veeam/Commvault).

**Proxmox VE** -- Choose when: budget is constrained, Linux containers (LXC) are a primary workload, ZFS or Ceph storage is preferred, web-based management is desired without per-socket licensing, homelab to mid-size production.

**KVM/QEMU with libvirt** -- Choose when: maximum flexibility and control are needed, Linux is the primary platform, integration with Ansible/Terraform is the automation model, embedding virtualization into a larger Linux infrastructure, no GUI management is acceptable.

## V2V Migration Guidance

### VMware to KVM/Proxmox
1. Export VM as OVA: `govc export.ovf -vm /DC01/vm/myvm ./export/`
2. Extract VMDK from OVA
3. Convert: `qemu-img convert -f vmdk -O qcow2 myvm.vmdk myvm.qcow2`
4. Remove VMware Tools, install QEMU guest agent and virtio drivers
5. Import into libvirt (`virt-install --import`) or Proxmox (`qm importdisk`)

### KVM/Proxmox to VMware
1. Convert: `qemu-img convert -f qcow2 -O vmdk myvm.qcow2 myvm.vmdk`
2. Upload VMDK to datastore
3. Create new VM shell in vCenter, attach converted VMDK
4. Install VMware Tools, remove QEMU guest agent
5. Verify virtio devices replaced with PVSCSI/VMXNET3

### Windows VM Migration (Any Direction)
- Install target platform drivers BEFORE migration (virtio-win for KVM, VMware Tools for vSphere)
- Use offline driver injection if pre-install is not possible
- Update boot controller driver in registry/BCD if changing disk controller type
- Test boot in recovery mode if VM fails to start after conversion

## Common Pitfalls

1. **Not verifying CPU virtualization extensions** -- Check BIOS/UEFI for VT-x/AMD-V and IOMMU before deploying any hypervisor.
2. **Mixing CPU vendors in a migration domain** -- Intel-to-AMD live migration is not supported on any platform. Keep clusters homogeneous.
3. **Overcommitting memory without monitoring** -- All platforms allow memory overcommit. Without ballooning drivers and monitoring, OOM kills or swap storms result.
4. **Ignoring NUMA topology** -- VMs that span NUMA nodes suffer 30-40% memory latency penalty. Size VMs to fit within a single NUMA node.
5. **Using snapshots as backups** -- Snapshots are not backups on any platform. They degrade performance over time and consume growing disk space.
6. **Skipping shared storage for HA** -- HA and live migration require shared storage (or storage replication) on every platform. Plan storage architecture before enabling clustering.

## Sibling Skills

- `vmware` -- VMware vSphere (ESXi, vCenter, PowerCLI, vSAN, DRS, HA)
- `proxmox` -- Proxmox VE (KVM+LXC, Ceph, ZFS, PBS)
- `kvm` -- KVM/QEMU with libvirt (virsh, virt-install, qemu-img)
- `citrix` -- Citrix Hypervisor / XenServer (xe, XAPI, XenMotion)
- `nutanix` -- Nutanix AHV (acli, ncli, Prism, DSF)
- `cloud-vms` -- AWS EC2, Azure VMs, Google Compute Engine