In short
Virtualisation lets one physical server run many isolated virtual machines (VMs), each with its own operating system, by inserting a thin software layer called a hypervisor between the hardware and the guests. It exists because a bare-metal server typically idles at 5-15% utilisation; consolidating 10-20 workloads onto one host cuts hardware, power, rack space and provisioning time from weeks to minutes, and it is the foundation on which every public cloud (AWS, Azure, Google Cloud, NIC MeghRaj) is built. The two dominant enterprise platforms in India are VMware vSphere/ESXi and Microsoft Hyper-V, with KVM, Nutanix AHV and Proxmox growing fast. It is examined in Operating Systems, Cloud Computing and Computer Architecture papers (university and placement tests ask hypervisor types, memory translation and isolation; it is not in the GATE CS/DA syllabus), and it is a standing interview area for infrastructure, cloud and DevOps roles at TCS, Infosys, Wipro, HCLTech, LTIMindtree, Tech Mahindra and every Indian data-centre operator.
Explained
What virtualisation is, and its types
- Virtual machine: a software container presenting virtual CPU, memory, disk, NIC and firmware to a guest OS, which believes it owns real hardware. The hypervisor (VMM, Virtual Machine Monitor) multiplexes real hardware among guests.
- Popek and Goldberg criteria (1974) — a correct VMM must give equivalence (guest behaves as on real hardware), resource control (guest cannot touch resources not allocated) and efficiency (most instructions execute directly on the CPU, not emulated).
- Their theorem: a VMM can be built if the set of *sensitive* instructions is a subset of *privileged* instructions. Classic x86 violated this — 17 instructions (SGDT, SIDT, SLDT, SMSW, PUSHF/POPF, LAR, LSL, STR, etc.) are sensitive but execute silently in user mode instead of trapping.
- Type 1 (bare-metal / native): hypervisor installs directly on hardware — VMware ESXi, Microsoft Hyper-V, Xen, KVM, Nutanix AHV. Low overhead, used in production.
- Type 2 (hosted): runs as an application on a host OS — VMware Workstation/Fusion, Oracle VirtualBox, Parallels. Used for labs, development, college practicals.
- Other virtualisation layers: OS-level (containers — Docker, LXC), application (App-V, ThinApp), desktop (VDI — VMware Horizon, Citrix, Azure Virtual Desktop), storage (vSAN, Storage Spaces Direct), network (NSX, SDN/NFV), and emulation (QEMU, Android emulator — translates a different ISA, so it is slow).
How the CPU, memory and I/O are virtualised
- Full virtualisation by binary translation (early VMware): the guest kernel is *deprivileged* to ring 1 or 3; the VMM scans kernel code and rewrites unsafe instructions on the fly. Unmodified guests, but translation overhead.
- Paravirtualisation (Xen, and the PV drivers everyone now uses): the guest kernel is modified to call the hypervisor explicitly (hypercalls) instead of issuing privileged instructions. Faster, but needs a modified/enlightened guest.
- Hardware-assisted virtualisation (Intel VT-x, AMD-V; from 2005-06): adds VMX root mode ("ring −1") for the hypervisor and non-root mode for guests. State is kept in a VMCS/VMCB; a sensitive event causes a VM exit to the hypervisor, which handles it and does a VM entry back. This made Popek-Goldberg hold on x86 and is mandatory for ESXi and Hyper-V — it must be enabled in BIOS/UEFI (Intel VT-x / AMD-V, plus VT-d for I/O).
- Memory, two-level translation: guest maps guest-virtual → guest-physical; the hypervisor maps guest-physical → host-physical. Originally done with shadow page tables (expensive, every guest page-table write traps). Now done in hardware by nested paging — Intel EPT, AMD RVI/NPT — with tagged TLBs (VPID/ASID) so TLB need not be flushed on every world switch.
- Memory over-subscription techniques (VMware reclaims in this order): transparent page sharing (dedupe identical pages; inter-VM sharing is off by default since 2014 for security), ballooning (a driver inside the guest,
vmmemctl, inflates to force the guest to page out), memory compression, then hypervisor swapping (slowest, avoid). Hyper-V uses Dynamic Memory — Startup/Minimum/Maximum RAM, memory buffer %, memory weight — with hot-add plus ballooning, and Smart Paging only during VM restart. - I/O models: (1) full emulation of a legacy device (Intel E1000, IDE) — compatible, slow; (2) paravirtualised/synthetic devices — VMware VMXNET3 and PVSCSI, Hyper-V VSP/VSC pairs talking over the VMBus ("enlightened I/O"); (3) direct assignment / passthrough using the IOMMU (Intel VT-d, AMD-Vi) — VMware DirectPath I/O, Hyper-V Discrete Device Assignment; (4) SR-IOV, where one physical NIC exposes many Virtual Functions mapped straight into VMs — lowest latency, but blocks live migration unless carefully configured.
- NUMA awareness: large "wide" VMs are given a vNUMA topology so the guest scheduler keeps memory local; crossing NUMA nodes costs latency. Hyper-V exposes a NUMA-spanning setting.
VMware vSphere — architecture and features
- ESXi: the Type-1 hypervisor; its kernel is the VMkernel, with a small footprint (no Linux parent OS), managed by DCUI/host client/API. A VMM/VMX process is created per VM.
- vCenter Server: the central management plane for clusters, templates, roles and licensing — most features (vMotion, DRS, HA) need it.
- vMotion: live migration of a running VM between hosts with no perceptible downtime, by iteratively pre-copying memory pages, then a brief stop-and-copy switchover. Storage vMotion moves the disks; Enhanced vMotion moves both with shared-nothing storage. Requires compatible CPUs (handled by EVC — Enhanced vMotion Compatibility — masking newer CPU features).
- DRS (Distributed Resource Scheduler): balances VMs across cluster hosts using vMotion; automation levels manual/partial/full; affinity and anti-affinity rules. DPM powers idle hosts off.
- HA (High Availability): if a host dies, its VMs restart on surviving hosts (a reboot, not zero downtime). Admission control reserves spare capacity. Fault Tolerance keeps a shadow VM in lockstep for truly zero downtime, with strict vCPU limits.
- Storage: VMFS clustered file system or NFS datastores; VMDK virtual disks — thin, thick lazy-zeroed, thick eager-zeroed (needed for FT); RDM for raw LUNs; vSAN pools local disks into a shared datastore (HCI).
- Networking: vSphere Standard Switch (per host) and vDS (Distributed Switch, cluster-wide), port groups, VLAN tagging (EST/VST/VGT), teaming and failover policies; NSX adds overlay networks, distributed firewall and micro-segmentation.
- Operations: templates, cloning, OVF/OVA portable appliances, snapshots (a delta/child disk plus memory state — a point-in-time, *not* a backup), resource pools with shares / reservations / limits, VMware Tools for drivers, quiescing and graceful shutdown.
- Commercial note: after Broadcom acquired VMware (Nov 2023), perpetual licences were withdrawn in favour of subscription bundles (VMware Cloud Foundation, vSphere Foundation) priced per core with a per-CPU core minimum. The resulting cost increases have pushed many Indian enterprises and MSPs to evaluate Hyper-V, Nutanix AHV, Proxmox and KVM — editions and pricing keep changing, so verify current terms rather than quoting a figure.
Microsoft Hyper-V — architecture and features
- Architecture: enabling the Hyper-V role on Windows Server pushes the existing OS into a parent (root) partition that sits above the hypervisor; VMs run in child partitions with no direct hardware access. Child partitions reach devices through VSCs that talk over the VMBus to VSPs in the parent, and make hypercalls to the hypervisor. It is therefore a Type-1 hypervisor despite looking like a Windows feature.
- Generation 1 vs Generation 2 VMs: Gen 1 uses legacy BIOS, emulated IDE boot and a legacy NIC for PXE; Gen 2 uses UEFI, SCSI boot, Secure Boot, faster boot, VM TPM, and supports only newer 64-bit guests. Generation cannot be changed after creation.
- Disks: VHD (2 TB limit) and VHDX (up to 64 TB, 4 KB logical sector alignment, log-based corruption resistance, online resize) in fixed, dynamically expanding or differencing form; plus pass-through disks and shared VHDX/VHD Set for guest clusters.
- Virtual switch types: External (bridged to a physical NIC), Internal (host + VMs only), Private (VMs only). Features: VLAN tagging, port ACLs, bandwidth management, VMQ, SR-IOV, SET (Switch Embedded Teaming) and virtual switch extensions.
- Mobility and resilience: Live Migration (shared storage, SMB 3.0 or shared-nothing), Storage Live Migration, Failover Clustering with Cluster Shared Volumes for host-failure restart, and Hyper-V Replica — asynchronous replication of a VM to a second site at 30-second, 5-minute or 15-minute intervals with planned/unplanned/test failover.
- Checkpoints: *Standard* (includes memory state) and *Production* (VSS/fsfreeze-consistent, application-safe) — production is the default on Windows Server.
- Other: Dynamic Memory, nested virtualisation (run Hyper-V or a lab hypervisor inside a VM), Shielded VMs with the Host Guardian Service and BitLocker-encrypted VHDX, integration services, and management through Hyper-V Manager, Windows Admin Center, PowerShell or SCVMM. The free standalone "Hyper-V Server" product ended with the 2019 release; the hyperconverged line is now Azure Local (formerly Azure Stack HCI).
- Licensing: Windows Server is licensed per core — minimum 8 cores per processor and 16 cores per server. Standard entitles 2 VMs (OSEs) per fully licensed host and can be stacked; Datacenter allows unlimited Windows VMs on that host. The hypervisor itself is free; the Windows guests are what you pay for.
VMs versus containers, and where each fits
- A VM virtualises hardware and runs a full guest kernel (GBs, boots in tens of seconds, strong isolation). A container virtualises the OS, sharing the host kernel via namespaces and cgroups (MBs, starts in milliseconds, weaker isolation, must match the host kernel family).
- Containers do not replace hypervisors — in practice Kubernetes nodes are themselves VMs (EKS, AKS, GKE, OpenShift on vSphere), giving both density and isolation.
- Middle ground: Kata Containers, Firecracker microVMs, Windows Hyper-V isolated containers — container packaging with hypervisor-grade isolation.
Benefits, limitations and Indian practice
- Benefits: consolidation and cost reduction, rapid provisioning from templates, hardware independence and easy migration, snapshots for safe patching, isolation of test from production, cluster-level high availability, and the basis of IaaS/self-service clouds.
- Limitations: hypervisor overhead (usually 2-10%, more for I/O-heavy workloads); the host is a single point of failure unless clustered; VM sprawl and licence creep; noisy-neighbour contention; complex troubleshooting across layers; licensing and skill cost; cross-VM security risks (VM escape, side channels such as Spectre/Meltdown/L1TF, for which hypervisor patches and scheduler mitigations exist).
- Indian context: MeitY/STQC-empanelled cloud providers and the NIC MeghRaj national cloud run on virtualised estates; CtrlS, Yotta, Sify, NxtGen, ESDS and Netmagic sell virtualised and HCI hosting; CERT-In's April 2022 directions require synchronised clocks (NTP from NPL/NIC), ICT logs retained for 180 days within India and incident reporting within 6 hours — hypervisor and vCenter logs fall squarely under this; the DPDP Act 2023 and RBI/IRDAI/SEBI outsourcing and IT-framework circulars drive data-localisation and audit requirements for where VMs and their replicas may reside. Common certifications: VMware VCP-DCV, Microsoft AZ-800/AZ-801, Red Hat RHCSA/Virtualization.
Key points
- Hypervisor - the layer that multiplexes physical hardware among virtual machines; Type 1 is bare-metal, Type 2 runs on a host OS.
- Popek-Goldberg - a VMM needs equivalence, resource control and efficiency; feasible when sensitive ⊆ privileged instructions.
- VT-x / AMD-V - hardware root/non-root modes with VM exits and VM entries; mandatory for ESXi and Hyper-V.
- EPT / NPT - hardware nested paging that removes shadow page tables; VPID/ASID tag TLB entries to avoid flushes.
- Paravirtualised drivers - VMXNET3/PVSCSI (VMware) and VSP-VSC over VMBus (Hyper-V) replace slow emulated devices.
- SR-IOV / IOMMU - direct device access for near-native I/O, at the cost of easy live migration.
- Overcommitment - allocating more vCPU/memory than the host physically owns; safe only because workloads peak at different times.
- Ballooning - the guest is coaxed into releasing pages; it precedes compression and hypervisor swapping in VMware's reclaim order.
- vMotion / Live Migration - iterative pre-copy of memory then brief stop-and-copy; zero perceived downtime, needs shared or migrated storage and CPU compatibility (EVC).
- HA vs FT - HA restarts VMs after a host failure (minutes of downtime); Fault Tolerance runs a lockstep shadow VM (zero downtime).
- DRS - automatic load balancing across cluster hosts using vMotion, with affinity/anti-affinity rules.
- Generation 2 VM - Hyper-V UEFI VM with Secure Boot, SCSI boot and vTPM; cannot be converted from Gen 1.
- VHDX vs VMDK - Hyper-V's 64 TB log-protected disk format versus VMware's VMDK (thin / lazy-zeroed / eager-zeroed thick).
- Snapshot/checkpoint - a delta disk and optional memory state for quick rollback; never a substitute for backup, and a performance drag if left for days.
- Hyper-V Replica - built-in asynchronous VM replication at 30 s / 5 min / 15 min intervals to a secondary site.
- VM vs container - hardware virtualisation with a full kernel versus OS-level isolation sharing the host kernel; Kubernetes nodes are usually VMs.
- Windows Server licensing - per core, 16-core minimum per host; Standard = 2 VMs (stackable), Datacenter = unlimited.
- Consolidation ratio - VMs per physical host; typical enterprise ranges from about 10:1 to 30:1 depending on workload.
Formulas and examples
vCPU : pCPU ratio = Σ vCPUs allocated / physical cores available (threads if HT counted); typical safe range 3:1 to 6:1
%CPU Ready = [ ready-time summation (ms) ] / [ sample interval (ms) × number of vCPUs ] × 100 ; vSphere real-time sample = 20,000 ms. Target < 5% per vCPU
Usable host memory = installed RAM − hypervisor overhead − Σ per-VM overhead
Memory overcommit ratio = Σ configured VM memory / usable host memory
Hosts required (N+1) = ceil( total workload demand / per-host usable capacity ) + 1
HA slots per host = min( host CPU capacity / largest CPU reservation , host memory / largest memory reservation )
Live-migration time T ≈ M / (R − D), downtime ≈ (D × T_last)/R, where M = VM RAM (GB), R = effective transfer rate (GB/s), D = memory dirty rate (GB/s), R > D
Availability A = MTBF / (MTBF + MTTR) ; annual downtime (min) = (1 − A) × 525,600
Cost per VM per month = (amortised hardware + licence + power + support) / VMs
Example 1 — Consolidation and host sizing. 40 physical servers, each 8 cores at 10% average CPU and 32 GB RAM at 40% used. Target hosts have 2 × 24 cores and 512 GB RAM; plan to utilisation ceilings of 70% CPU and 80% memory (i.e. 30% / 20% headroom).
- CPU demand = 40 × 8 × 0.10 = 32 core-equivalents. Usable per host = 48 × 0.70 = 33.6 cores → 1 host covers CPU.
- Memory demand = 40 × 32 × 0.40 = 512 GB. Usable per host = 512 × 0.80 = 409.6 GB → ceil(512/409.6) = 2 hosts.
- Memory is the binding constraint: 2 hosts + 1 for N+1 = 3 hosts. Consolidation ratio = 40/3 ≈ 13.3 : 1.
Example 2 — CPU Ready. A 4-vCPU VM reports a ready summation of 8,000 ms over a 20,000 ms sample.
- Total %RDY = 8,000 / 20,000 × 100 = 40%; per vCPU = 40/4 = 10%.
- 10% per vCPU is well above the 5% warning level — the host is over-subscribed, or the VM has too many vCPUs for its work (co-scheduling cost). Fix by right-sizing to 2 vCPUs or by vMotioning VMs off the host.
Example 3 — Memory overcommitment. Host with 256 GB RAM, 24 GB taken by the hypervisor and VM overheads; 20 VMs configured at 16 GB each.
- Usable = 256 − 24 = 232 GB; configured = 20 × 16 = 320 GB → overcommit ratio = 320/232 ≈ 1.38 : 1.
- If average active memory is 40%, actual demand = 0.40 × 320 = 128 GB — comfortably inside 232 GB, so ballooning should not trigger.
- If the VMs later run at 85% active = 272 GB > 232 GB, the host enters reclamation: TPS → ballooning → compression → swapping, and latency rises sharply.
Example 4 — Live migration time. VM with 16 GB RAM, 10 GbE migration network at 80% efficiency, dirty rate 100 MB/s.
- R = 10 Gbps / 8 = 1.25 GB/s × 0.80 = 1.0 GB/s; D = 0.1 GB/s.
- T ≈ 16 / (1.0 − 0.1) = 17.8 s total. Pass-wise: 16 s → 1.6 s → 0.16 s → 0.016 s (geometric, ratio 0.1), so the final stop-and-copy is ~16 MB ≈ 16 ms of actual downtime — below TCP timeouts, hence "no perceptible interruption".
- If the VM dirtied memory at 1.1 GB/s (> R), pre-copy would never converge and the hypervisor would force a switchover or abort.
Example 5 — Hyper-V licensing break-even. Host with 2 × 16 = 32 cores. Assume list prices of ₹85,000 per 16-core Standard pack and ₹5,00,000 per 16-core Datacenter pack (indicative only — Indian reseller and EA pricing varies, verify current rates).
- Covering 32 cores needs 2 packs: Standard = ₹1,70,000 for 2 VMs; Datacenter = ₹10,00,000 for unlimited VMs.
- Break-even = 10,00,000 / 1,70,000 = 5.88 → the 6th stack tips it: 11-12 VMs need 6 Standard stacks costing ₹10,20,000 ≥ Datacenter, so from about 11 Windows VMs per host Datacenter is cheaper — and it is mandatory in practice if live migration / failover clustering moves VMs freely across hosts.
| Feature | VMware vSphere / ESXi | Microsoft Hyper-V |
|---|---|---|
| Hypervisor type | Type 1, purpose-built VMkernel | Type 1, parent partition on Windows Server |
| Management | vCenter Server, vSphere Client, PowerCLI | Hyper-V Manager, Windows Admin Center, SCVMM, PowerShell |
| Disk format | VMDK (thin / lazy / eager-zeroed thick) | VHD, VHDX (dynamic / fixed / differencing) |
| Live migration | vMotion, Storage vMotion, EVC | Live Migration, Storage/Shared-Nothing Migration |
| Load balancing | DRS, DPM | SCVMM Dynamic Optimization / Power Optimization |
| Host failure recovery | vSphere HA, Fault Tolerance | Failover Clustering with CSV |
| Built-in replication | vSphere Replication, SRM (extra licence) | Hyper-V Replica (included) |
| Memory techniques | TPS, ballooning, compression, swap | Dynamic Memory, Smart Paging |
| Cluster file system | VMFS / NFS / vSAN | CSV on NTFS-ReFS, SMB 3.0, Storage Spaces Direct |
| Cost model | Per-core subscription bundles (post-Broadcom) | Hypervisor free; Windows Server per-core, Standard vs Datacenter |
| Typical fit | Mixed Linux + Windows estates, mature tooling | Windows-heavy estates, Azure-aligned, lower licence cost |
| Type 1 hypervisor | Type 2 hypervisor | Container | |
|---|---|---|---|
| Runs on | Bare metal | Host OS | Host OS kernel |
| Overhead | Low | Higher | Near zero |
| Boot time | Tens of seconds | Tens of seconds | Milliseconds |
| Isolation | Strong (hardware) | Strong | Weaker (shared kernel) |
| Guest OS | Any supported OS | Any supported OS | Same kernel family only |
| Example | ESXi, Hyper-V, KVM | VirtualBox, Workstation | Docker, LXC, containerd |
Where it is used
- Enterprise data centres and IT services: TCS, Infosys, Wipro, HCLTech, LTIMindtree and Tech Mahindra run large managed-virtualisation practices for global clients — roles such as VMware/Hyper-V administrator, cloud infrastructure engineer, SRE and L2/L3 data-centre support.
- Indian hosting and colocation: CtrlS, Yotta, Sify, NxtGen, ESDS, Netmagic and AWS/Azure/Google India regions sell virtual machines as a product; MeitY-empanelled providers host state and central government workloads, with NIC's MeghRaj serving e-governance applications.
- BFSI and regulated sectors: banks, NBFCs and insurers virtualise core-adjacent applications under RBI/IRDAI IT and outsourcing guidelines, with clustered hosts, replicated sites and strict log retention under CERT-In's 2022 directions.
- Engineering and campus labs: VirtualBox/VMware Workstation for OS, networking, cybersecurity and Linux practicals; nested virtualisation for Kubernetes and penetration-testing labs.
- VDI and remote work: VMware Horizon, Citrix and Azure Virtual Desktop deliver locked-down desktops to BPO, contact-centre and offshore delivery-centre seats where data must not leave the data centre.
- DevOps and platform teams: Kubernetes clusters, CI runners and ephemeral test environments provisioned as VMs through Terraform, Ansible and vRealize/Azure Automation.
Interview questions
- Q: What is the difference between a Type 1 and Type 2 hypervisor? A: A Type 1 hypervisor installs directly on hardware and manages it itself (ESXi, Hyper-V, KVM); a Type 2 runs as an application on an existing host OS (VirtualBox, Workstation) and is slower, so it is used for labs rather than production.
- Q: Is Hyper-V a Type 1 hypervisor even though it needs Windows Server? A: Yes — enabling the role moves the running Windows instance into a parent partition above the hypervisor; the hypervisor owns the hardware, and the parent only provides device drivers and management through VSPs on the VMBus.
- Q: Why was x86 hard to virtualise before 2005? A: Seventeen sensitive instructions executed in user mode without trapping, breaking the Popek-Goldberg condition; VMware solved it with binary translation and Xen with paravirtualisation until VT-x and AMD-V added a root mode in hardware.
- Q: What do EPT and NPT do? A: They add a hardware second-level page table mapping guest-physical to host-physical addresses, removing the cost of software shadow page tables; VPID/ASID tags let the TLB survive world switches.
- Q: How does vMotion achieve near-zero downtime? A: It pre-copies memory to the target host in iterative passes while tracking dirtied pages, then briefly suspends the VM to copy the small remaining working set and the device state before resuming on the target — typically milliseconds of actual pause.
- Q: What is the difference between vSphere HA and Fault Tolerance? A: HA restarts the failed host's VMs elsewhere, so there is a reboot and a few minutes of downtime; FT runs a continuously synchronised secondary VM that takes over instantly, but costs double the resources and is limited in vCPUs.
- Q: Is a snapshot a backup? A: No — it is a delta disk dependent on the original base disk on the same storage; it rolls back a change but does not survive datastore loss, and long-lived snapshots degrade performance and can fill the datastore.
- Q: What causes high CPU Ready and how do you fix it? A: Too many vCPUs contending for too few physical cores, worsened by oversized VMs needing co-scheduled vCPUs; fix by right-sizing vCPU counts, lowering the vCPU:pCPU ratio, removing CPU limits, and balancing with DRS.
- Q: Explain memory ballooning. A: A balloon driver inside the guest allocates memory on the hypervisor's instruction, forcing the guest's own pager to free its least valuable pages — the guest chooses what to give up, which is far better than blind hypervisor swapping.
- Q: Difference between Generation 1 and Generation 2 Hyper-V VMs? A: Gen 1 boots from legacy BIOS with emulated IDE/legacy NIC; Gen 2 uses UEFI with SCSI boot, Secure Boot and virtual TPM, boots faster, supports only modern 64-bit guests, and cannot be converted after creation.
- Q: Why do organisations still use VMs when containers exist? A: VMs give kernel-level isolation, run different operating systems on one host and support legacy workloads; containers share the host kernel, so most Kubernetes clusters in fact run on VMs to get both density and isolation.
- Q: A host has 256 GB RAM but VMs configured for 400 GB — is that valid? A: Yes, that is memory overcommitment at about 1.56:1 and it works while active memory stays below the usable physical total; if actual demand exceeds it, the host reclaims through sharing, ballooning, compression and finally swapping, which hurts performance badly.
Common mistakes
- Calling Hyper-V or KVM a Type 2 hypervisor because a familiar OS is visible — both own the hardware and are Type 1.
- Giving a VM many vCPUs "to be safe": oversized VMs raise CPU Ready and scheduling latency and usually run *slower* than right-sized ones.
- Treating snapshots/checkpoints as backups, and leaving them running for weeks until the delta disks fill the datastore.
- Forgetting that live migration needs compatible CPU features (or EVC/processor-compatibility mode), shared or migrated storage and a dedicated migration network — and that SR-IOV or passthrough devices usually block it.
- Confusing *allocated* with *active* memory when computing overcommitment, or ignoring hypervisor and per-VM overhead in capacity maths.
- Building a cluster with no N+1 spare capacity or no HA admission control, so a single host failure leaves nowhere for its VMs to restart.
- Licensing errors: assuming the free hypervisor means free guests, or buying Windows Server Standard for a host whose VMs roam freely across a DRS/failover cluster.
Related topics
Cloud computing and IaaS service models · Operating system memory management and scheduling · Containers, Docker and Kubernetes · Disaster recovery and business continuity · IT asset and licence management · Storage and SAN/NAS fundamentals.