VMware ESXi and vSphere Cluster Management
What Is a Virtual Machine? Understanding VMs and Hypervisors
Learn what virtual machines are, how hosts, guests, and hypervisors work, and how Type 1 and Type 2 virtualization differ.
A virtual machine (VM) is an isolated, software-defined computer environment. It can boot an operating system and run applications much like a physical computer, even though its processor, memory, disk, and other devices are supplied by another computer.
The physical computer that supplies those resources is separate from the VM itself. For example, a Windows laptop can host a VM running Linux. Windows and the laptop are the host environment; Linux is the guest running inside the VM.
What Is a Virtual Machine?
A VM behaves like a computer from the perspective of its guest operating system. The guest can have a boot process, a file system, users, applications, network settings, and virtual devices. The difference is that the computer the guest sees is created and managed by software rather than being a separate physical machine.
VMs are isolated from one another and from the host at a high level. This means that one VM normally has its own operating system and virtual disk, rather than directly sharing the guest operating system of another VM. Isolation is useful, but it is not an unlimited security boundary. Configuration, software vulnerabilities, and features such as shared folders can affect separation.
Virtual Hardware Inside a VM
A hypervisor presents virtual or emulated hardware to the guest. The guest operating system detects these components as if they were the hardware of an ordinary computer.
- Virtual CPU (vCPU): A processor resource assigned to the VM. The hypervisor schedules its work on physical CPU cores or threads.
- Virtual RAM: A portion of the host's memory made available to the guest.
- Virtual disk: A disk presented to the guest for the operating system, applications, and data. It is usually stored as one or more files on the host's storage device.
- Virtual network adapter: A software-defined network interface that connects the guest to a virtual network and, depending on configuration, to the host network or the Internet.
- Virtual display adapter: A device that allows the guest to produce a graphical desktop and use a VM window or remote console.
- Firmware: Virtual BIOS or UEFI firmware that initializes the VM and starts its operating system.
- Removable-device support: Virtual access to devices such as an ISO image, optical drive, USB device, or other removable media, when enabled.
An ISO image is a disk image file commonly used as installation media. Attaching an operating system ISO to a VM is similar to inserting an installation DVD or USB device into a physical computer.
Physical Resources and Virtual Equivalents
Host, Guest, and Physical Resources
The host is the physical computer that runs VMs. In desktop virtualization, the host usually includes both the physical machine and its conventional operating system.
The guest is the operating system and workload running inside a VM. A guest operating system might be Linux, Windows, or another supported system. Guest applications run on that guest operating system.
CPU time, RAM, storage capacity, network connectivity, and access to peripheral devices ultimately originate from the host. A VM's allocation is not an unlimited supply of resources. If a host has 16 GB of RAM, assigning 12 GB to one VM leaves less memory for the host operating system and other VMs.
Several VMs can share a host, but they compete for capacity. Running many VMs can create contention for CPU scheduling, memory, disk input and output, and network bandwidth. Giving every VM a large allocation can make the host less responsive instead of making every guest faster.
What Does a Hypervisor Do?
A hypervisor is the virtualization layer responsible for creating, running, and managing VMs. It presents virtual hardware to each guest and coordinates access to physical hardware.
- It schedules vCPU work on physical processors.
- It maps or manages guest memory using host memory.
- It connects virtual disks to files, volumes, or other storage on the host.
- It routes traffic through virtual network adapters and physical network devices.
- It provides virtual firmware, display devices, and selected peripheral access.
- It applies VM configuration and helps keep separate VMs from directly interfering with one another.
Isolation does not eliminate security responsibilities. Guests still need operating-system updates, strong account security, malware protection where appropriate, and careful configuration of integration features.
Type 1 and Type 2 Hypervisors
The terms Type 1 and Type 2 describe where the hypervisor sits in the software stack.
Type 1: Directly on Physical Hardware
A Type 1 hypervisor is installed directly on physical hardware. It is often called a bare-metal hypervisor. Guest operating systems run above the hypervisor rather than above a general-purpose desktop operating system.
This model is common in servers and data centers, where centralized administration, predictable resource management, and high VM density are important. The administration model generally focuses on hosts, clusters, storage, networking, permissions, and many guest systems.
Type 2: Above a Host Operating System
A Type 2 hypervisor is an application installed on a conventional host operating system such as Windows or Linux. The host operating system manages the physical computer, while the hypervisor application manages VMs through that host environment.
This model is common on personal computers and workstations. It is convenient for learning, software testing, and running another operating system beside the user's normal desktop. There can be additional overhead because requests pass through the host operating system and its drivers.
Type 1 is not automatically faster or safer in every situation, and Type 2 is not automatically unsuitable for serious work. Performance and security depend on hardware support, software versions, configuration, workload, storage, networking, and administration.
Desktop Example: Linux on a Windows PC
Suppose a user has a Windows computer and installs VMware Workstation Player. The user creates a VM, attaches an openSUSE installation ISO, and installs openSUSE as the guest operating system.
The layers, in order, are physical PC, Windows host operating system, VMware Workstation Player, VM virtual hardware, Linux guest operating system, and guest applications. This is classified as Type 2 virtualization because VMware Workstation Player runs as an application on Windows.
Configuring a Basic VM
When creating a VM, the exact screens depend on the virtualization product, but the main decisions are similar:
- Choose the guest operating-system type and version.
- Assign an appropriate number of vCPUs without leaving the host starved of processor capacity.
- Allocate RAM while retaining enough memory for Windows or Linux and other host applications.
- Create or select a virtual disk and choose where its files will be stored.
- Attach an operating-system ISO image as installation media.
- Select a network mode such as NAT, bridged, or host-only when the product provides those choices.
- Install the guest operating system, then configure updates, accounts, applications, and integration features.
NAT commonly lets the guest reach external networks through the host. Bridged networking places the guest more directly on the same network as the host's physical connection. Host-only networking normally limits communication to the host and other appropriately configured VMs. The exact behavior varies by product and network configuration.
VM Lifecycle
A VM typically moves through these stages:
- Create: Define the VM and its virtual hardware.
- Install: Boot from an ISO image or other installation media and install the guest operating system.
- Start: Power on the VM and boot the guest.
- Stop: Shut down the guest cleanly or power it off.
- Suspend: Save the running state so the VM can resume later.
- Delete: Remove the VM configuration and, if selected, its virtual disk files.
Powering off a VM is like switching off a physical computer. Unsaved guest work may be lost, and repeated unclean power-offs can damage a file system. Suspending saves the VM's running state, including memory contents, so it can continue later; the saved state consumes storage and may become invalid after some hardware or product changes.
Snapshots and clones may be available depending on the virtualization product and edition. A snapshot records a point-in-time VM state for later reversion, while a clone creates another VM from an existing one. They are separate features, not requirements for the basic definition of a VM. Snapshots should not replace a proper backup strategy.
Benefits of Virtual Machines
- Multiple operating systems: Run Linux on a Windows desktop, or test another supported operating system without buying a second computer.
- Software testing: Try an application or configuration in a separate environment that can be deleted and recreated.
- Administration practice: Learn installation, networking, user management, services, and troubleshooting with less risk to the primary desktop.
- Legacy support: Keep an older application or operating system available when replacing physical hardware is impractical, subject to licensing and security constraints.
- Portability: A VM can often be moved by copying its configuration and virtual disk files to compatible host infrastructure.
- Repeatability: A known VM configuration can be copied or rebuilt for consistent labs and development environments.
Limitations and Trade-Offs
- VMs consume host CPU time, RAM, storage, and network capacity.
- Some workloads perform less efficiently than they would with direct access to physical hardware, especially when virtualization features or drivers are poorly configured.
- Virtual disks can require substantial storage, including additional space for snapshots or copied VMs.
- A VM generally depends on the host being available. If the host is shut down, fails, or loses its storage, its guests may also become unavailable.
- Several active VMs can contend for CPU, memory, disk I/O, and network bandwidth.
Security and Data Considerations
A guest is still a real operating-system environment from a security perspective. Install patches, use appropriate account protections, limit unnecessary services, and use malware protection when suitable for the guest workload.
Integration features can reduce separation between host and guest. Shared folders expose selected host files, clipboard sharing permits data transfer, USB passthrough gives the guest access to a physical device, and bridged networking can place the guest directly on the surrounding network. Enable these features only when needed and understand what they allow.
Back up important VM files before major guest changes, storage moves, or host migration. A backup should include the virtual disk and any required VM configuration, and it should be tested rather than assumed to work.
Troubleshooting Common VM Problems
The VM Is Slow or Unresponsive
- Too little RAM or CPU capacity may be available on the host.
- Too many VMs or host applications may be running simultaneously.
- Host storage may be slow or nearly full.
- The VM may have been given excessive virtual hardware allocations, leaving the host unable to work efficiently.
Close unnecessary applications or VMs, review the guest allocation, keep sufficient resources for the host operating system, and use faster storage where practical. More assigned resources do not always improve performance.
The Guest Cannot Access the Network
- Check that the host itself has network connectivity.
- Confirm that the VM's virtual network adapter is enabled.
- Review whether NAT, bridged, or host-only networking matches the intended connectivity.
- Check the guest's IP address, gateway, and DNS configuration.
The VM Will Not Start
- Check available host memory and storage.
- Confirm that the VM configuration and virtual disk files remain in their expected locations.
- Review virtualization support and possible conflicts with other hypervisor features.
- Check for a damaged VM configuration and consult the product's diagnostics if necessary.
Adding Resources Did Not Improve Performance
The host may be overcommitted, or the workload may be limited by disk or network performance rather than CPU or RAM. Measure the likely bottleneck before increasing allocations, and always preserve adequate capacity for the host operating system.
Key Terms to Remember
- VM: A software-defined computer environment that runs an operating system and applications.
- Host: The physical computer and, in desktop virtualization, its operating system that provide VM resources.
- Guest: The operating system and workload running inside a VM.
- Hypervisor: The software or firmware layer that manages VMs and mediates physical-resource access.
- Resource allocation: The assignment of host CPU, memory, storage, and network capacity to a VM.
- Isolation: Separation between VM environments and the host, subject to product settings and security controls.
- Suspend: Saving a VM's running state so it can resume later.
- Snapshot: A supported point-in-time record of a VM state.
For a concise reference to this lesson, return to the virtual machine overview.