A **Virtual Machine (VM)** is a software emulation of a complete computer system — with its own virtualised CPU, memory, storage, and network interfaces — running on top of a physical host through a **hypervisor**. Each VM runs a full guest operating system, fully isolated from other VMs on the same hardware. --- ### First Principle: Virtualise the hardware to share it safely. A single physical server sitting idle at 10% utilisation is wasteful. By running multiple VMs on one machine, each with its own OS and workload, you can push utilisation to 60–80% while maintaining strong isolation between tenants. The hypervisor arbitrates access to physical resources. --- ### Key Considerations - **Hypervisor Types**: **Type 1** (bare-metal) hypervisors like VMware ESXi, KVM, and Microsoft Hyper-V run directly on hardware. **Type 2** (hosted) hypervisors like VirtualBox run on top of a host OS. Data centers use Type 1 exclusively. - **Isolation Strength**: VMs provide hardware-level isolation — each has its own kernel, so a crash or compromise in one VM does not affect others. This is stronger than [[Docker Containers|container]] isolation. - **Overhead**: Each VM runs a full OS kernel, consuming 512MB–2GB+ of RAM just for the guest OS. This overhead means fewer workloads per host compared to containers. - **Live Migration**: VMs can be moved between physical hosts without downtime (vMotion, live migration), enabling maintenance and load balancing across the [[Clustering|cluster]]. - **GPU Virtualisation**: Technologies like NVIDIA vGPU and SR-IOV allow GPUs to be partitioned and assigned to individual VMs — bridging virtualisation with accelerated compute. --- ### Actionable Insights In [[Modular Data Center Design Principles|modular data center]] environments, VMs remain the standard for workloads requiring strong tenant isolation — particularly for enterprise customers and regulated industries. For AI workloads, the choice between VMs and [[Docker Containers|containers]] depends on the security boundary required: containers for internal microservices and inference pipelines, VMs for [[multi-tenancy|multi-tenant]] isolation where customers share physical hardware. Many deployments use both — containers running inside VMs — to get the density benefits of containers with the isolation guarantees of virtualisation. --- ### VM vs Container Comparison | Dimension | VMs | Containers | |-----------|-----|------------| | Isolation | Hardware-level (own kernel) | Process-level (shared kernel) | | Startup time | 30s–minutes | Milliseconds–seconds | | Overhead | 512MB–2GB+ per instance | 10–100MB per instance | | Density | 10s per host | 100s per host | | Use case | Multi-tenant, regulated | Microservices, CI/CD, inference | [[Bare Metal]] | [[Docker Containers]] | [[MIGs]] | [[multi-tenancy]] | [[Clustering]]