Servers and Virtual Machines: Software-Defined Computers

A server is not necessarily a special shape of computer. It is a computer or program that provides services to other programs, called clients.

A single physical server can also behave like several independent computers through virtualization.

A virtual machine, or VM, is a software-defined computer with virtual CPU, memory, storage, and networking, backed by physical hardware and managed by a hypervisor.

Each VM can run its own operating system and applications as though it were a separate machine.

A concrete example: one host, several systems

Imagine a physical server with 32 CPU cores and 256 GB of memory.

A hypervisor might host:

• A Linux VM for a web application
• A Windows VM for an accounting application
• A second Linux VM for testing
• Several small VMs for different customers

Each guest sees virtual hardware assigned to it. The hypervisor maps that virtual activity to the physical processor, memory, disks, and network devices.

The guests do not normally control one another.

What makes a computer a server?

The word server can refer to:

• Physical hardware in a rack
• A virtual machine
• A program listening for requests
• A role performed by a system

A laptop running a local web server is temporarily a server. A large physical machine may host hundreds of server processes.

Context matters. When someone says "restart the server," clarify whether they mean one process, one VM, or an entire physical host.

The hypervisor controls virtualization

A hypervisor creates and manages virtual machines.

A type 1, or bare-metal, hypervisor runs directly on hardware. This model is common in data centers.

A type 2 hypervisor runs as an application on a host operating system. Desktop virtualization tools often use this model.

The hypervisor:

• Schedules virtual CPUs on physical CPUs
• Maps guest memory
• Presents virtual devices
• Enforces isolation
• Connects virtual networks
• Controls VM lifecycle

Modern processors include virtualization features that help guests execute efficiently while preserving control.

Virtual CPUs share physical execution

A virtual CPU is a schedulable unit presented to a VM. It is not always a dedicated physical core.

The hypervisor schedules virtual CPUs across available physical cores. When too many active virtual CPUs compete, workloads experience contention or CPU steal time.

Providers may oversubscribe CPU because many workloads are not busy simultaneously. This improves utilization but makes performance less predictable under contention.

Dedicated hosts or specialized instance types are available when isolation or licensing requires them.

Memory virtualization

Each VM sees its own address space. The hypervisor maps guest-physical memory to actual machine memory.

Memory is harder to share than CPU because active data must remain available. Techniques may include:

• Reserving memory
• Ballooning memory from guests
• Deduplicating identical pages
• Swapping to storage

When a host lacks physical memory, performance can decline sharply. A VM with an assigned memory size does not guarantee that every workload uses it efficiently.

Application-level memory monitoring remains necessary.

Virtual disks

A VM sees one or more virtual disks. Behind them may be:

• A file on local storage
• A logical block device
• A network-attached volume
• Distributed storage across several machines

Virtual disks simplify attachment, resizing, snapshots, and movement. Their performance depends on the underlying storage, network, caching, and provisioned limits.

Durability also varies. An ephemeral local disk may disappear with the host, while replicated block storage survives host failure.

The device name inside the VM does not reveal the full storage guarantee.

Virtual networking

A VM receives virtual network interfaces connected through software switches and network overlays.

Virtual networks can provide:

• Private address ranges
• Routing
• Firewalls or security groups
• Public addresses
• Load balancer connections
• Network isolation among tenants

Packets ultimately travel through physical network cards and switches.

Software-defined networking makes configuration fast and programmable, but incorrect rules can isolate a service or expose it publicly just as quickly.

Isolation is the central boundary

Each VM runs its own kernel. A failure or incompatible software inside one guest should not directly alter another guest.

VM isolation supports:

• Multiple operating-system types on one host
• Separate customer workloads
• Independent patch schedules
• Stronger boundaries than ordinary processes

The hypervisor is highly privileged. A vulnerability that escapes a guest into the hypervisor is serious, which is why providers minimize, patch, and monitor this layer carefully.

Isolation also includes networks, storage permissions, management APIs, and operator access.

Images create repeatable machines

A VM image is a template containing an operating system and optionally configured software.

Teams can use images to:

• Launch consistent instances
• Scale out applications
• Replace failed machines
• Test upgrades
• Standardize security settings

Images become stale. An image created months ago may contain vulnerable packages or expired credentials.

A healthy image pipeline rebuilds from controlled definitions, scans outputs, records provenance, and avoids embedding secrets.

Snapshots are point-in-time storage views

A snapshot captures virtual-disk state at a point in time.

It can help with:

• Backup workflows
• Creating test copies
• Rolling back controlled changes
• Migrating data

A snapshot is not always application-consistent. If a database has unwritten memory or several disks must align, the application may need to flush, pause, or coordinate before capture.

Snapshot lifecycle and storage cost also need management.

Live migration moves running VMs

Some virtualization platforms can move a running VM between physical hosts with little interruption.

Memory pages are copied while the VM runs. Changed pages are recopied, then execution pauses briefly for final state transfer.

Live migration enables hardware maintenance and load balancing, but depends on compatible hosts, networking, and accessible storage.

It reduces visible interruption; it does not eliminate the need for application-level redundancy.

Virtualization overhead

VMs add management layers and each guest carries a complete operating-system kernel.

Costs include:

• Guest memory usage
• Boot time
• Virtual-device processing
• Hypervisor management
• Lower density than many container workloads

Hardware support makes virtualization efficient enough for enormous production use. For specialized low-latency or accelerator workloads, bare-metal access may still matter.

The correct comparison is based on measured workload behavior and isolation needs.

VMs and containers solve different layers

A VM virtualizes a machine and runs its own kernel.

A container isolates processes while sharing the host kernel.

VMs can run different operating systems on one host and provide a stronger kernel boundary. Containers are generally smaller and start faster.

Many platforms run containers inside VMs, combining VM-level tenant or host isolation with container-level application packaging.

Knowledge check

1. What different things can the word server refer to?
2. What role does a hypervisor perform?
3. Why can virtual CPU performance vary?
4. Why is a virtual-disk snapshot not always a complete application backup?
5. What key kernel difference separates VMs from containers?

The one idea to remember

A virtual machine is a software-defined computer. The hypervisor divides and isolates shared physical resources so each VM can run its own operating system while remaining backed by real hardware.