Student Manual: Virtual Infrastructure 3: ESX Server 3.0 and VirtualCenter 2.0

— ny_wk

VMware ESX Server and Virtual Infrastructure 3 (VI3) introduced the bare-metal hypervisor and centralized management model that still underpins modern data center virtualization. The fundamentals below explain how ESX worked and map every legacy component to its current vSphere equivalent, since VI3, the Service Console, and classic ESX are long end-of-life.

What VMware ESX and Virtual Infrastructure 3 Actually Were

VMware ESX Server was a type-1 (bare-metal) hypervisor: it installed directly onto physical server hardware with no host operating system underneath it. Virtual Infrastructure 3 was the broader product suite built around that hypervisor, pairing ESX Server 3.x hosts with a central management server called VirtualCenter 2.0. Together they let one administrator carve a single physical machine into many isolated virtual machines (VMs), each running its own guest operating system as if it owned the hardware.

This was a turning point for IT. Before bare-metal hypervisors, servers commonly ran a single application at 5-15% average utilization. Virtualization let organizations consolidate dozens of workloads onto far fewer physical hosts, raising utilization, cutting power and cooling costs, and dramatically speeding up provisioning.

Important context: VI3, ESX 3.x, and VirtualCenter 2.0 are obsolete and unsupported. The architecture and vocabulary below are still the foundation of today's platform, but you should run the modern products in production. Use this as a conceptual primer, then apply the up-to-date names noted throughout.

Legacy term to modern term, at a glance

ESX Architecture and the VMkernel

The heart of ESX was the VMkernel, a purpose-built microkernel that VMware wrote specifically to run virtual machines. The VMkernel scheduled CPU time, managed memory, controlled access to storage and networking, and enforced isolation between VMs. Because it was lightweight and dedicated to virtualization, it imposed far less overhead than running VMs on top of a general-purpose operating system.

The Service Console (and why it no longer exists)

Classic ESX shipped with a Service Console, a modified Red Hat Linux environment that booted alongside the VMkernel and provided a management and command-line interface. Administrators logged into it to run scripts, configure the host, and install agents. It was useful but carried real costs: a full Linux install meant a larger attack surface, more patching, and more disk and memory consumed by management plumbing rather than workloads.

VMware's answer was ESXi ("i" for the integrated, thin architecture). ESXi removed the Service Console entirely, shrinking the hypervisor footprint to roughly a hundred-odd megabytes and sharply reducing the patch and security burden. For a transition period VMware shipped both "ESX" (with console) and "ESXi" (without). With vSphere 5.0, classic ESX was discontinued and ESXi became the only hypervisor. If you administer VMware today, you administer ESXi.

How you manage an ESXi host now

• DCUI (Direct Console User Interface): the yellow-and-grey console screen for basic host setup (management IP, root password, restart services).
• ESXi Shell and SSH: a local/remote shell with VMware-specific commands such as esxcli and vim-cmd, disabled by default for security.
• vSphere Client: the browser-based GUI served by vCenter (or by the host directly via the Host Client).
• PowerCLI and the API: PowerShell and REST/SOAP automation for repeatable, large-scale management.

Virtual Machines: Hardware Abstracted in Software

A virtual machine is a set of files plus a slice of the host's CPU, memory, disk, and network presented to a guest OS as standardized virtual hardware. Crucially, the VM's virtual hardware is decoupled from the underlying physical server, which is exactly what makes live migration, snapshots, and templating possible. The key files that make up a VM include:

Because a VM is just files on shared storage, you can clone it, convert it to a reusable template, or move it between hosts without touching the guest OS. Two long-standing efficiency features deserve mention:

• VMware Tools: a package installed inside the guest that provides optimized drivers, better mouse/clock handling, graceful shutdown, and heartbeating. It remains essential today.
• Thin provisioning: a virtual disk that consumes only the storage actually written rather than its full declared size, improving capacity efficiency (use with monitoring so a datastore does not silently fill).

How the VMkernel stretches physical resources

ESX pioneered several memory-reclamation techniques that let hosts safely run more VMs than raw RAM would suggest (a practice called overcommitment):

• Transparent page sharing: identical memory pages across VMs are stored once and shared.
• Ballooning: a driver inside the guest (via VMware Tools) reclaims idle guest memory when the host is under pressure.
• Memory compression and swapping: last-resort tiers that compress or page out memory to keep VMs running.

Virtual Networking with the vSwitch

Each ESX/ESXi host runs one or more virtual switches (vSwitches) in software. A vSwitch behaves much like a physical Layer 2 switch: VMs connect to it through virtual NICs, and the vSwitch forwards frames between them and out to the physical network through the host's physical NICs, which in VMware terminology are called uplinks or vmnics.

Port groups and VMkernel ports

You do not connect VMs directly to a vSwitch; you connect them to a port group. A port group is a named policy template that applies a consistent configuration, most importantly a VLAN ID and security/teaming settings, to every VM attached to it. Separately, the host uses special VMkernel ports for its own IP traffic, such as management, VMotion/vMotion, IP storage (iSCSI/NFS), and (today) vSAN. Keeping these traffic types on dedicated VLANs and, ideally, dedicated NICs is a core design practice.

Standard vSwitch versus Distributed Switch

The vSwitch described above is the vSphere Standard Switch (vSS), which is configured per host. Managing identical switches across dozens of hosts is tedious and error-prone, so VMware later introduced the vSphere Distributed Switch (vDS): a single logical switch defined once in vCenter and pushed consistently to all member hosts. The vDS also unlocks advanced features such as network I/O control, LACP, port mirroring, and migration of network state with the VM. The standard switch remains valid for small deployments; the distributed switch is the norm at scale.

• NIC teaming: binding multiple uplinks to a port group for redundancy and load distribution.
• VLAN tagging (VST): the vSwitch tags traffic per port group so one trunked physical link can carry many networks.
• Traffic shaping and security policies: control over bandwidth and behaviors like promiscuous mode and MAC-address changes.

Storage and the VMFS File System

Shared storage is what makes the marquee availability features possible, because every host that might run a VM must be able to reach that VM's files. ESX introduced VMFS (Virtual Machine File System), a clustered file system designed so that multiple hosts can access the same volume at the same time without corrupting it. Each VMFS volume is presented as a datastore, the logical container where VM files live.

Storage options VI3 established

VI3 used VMFS-3. The file system has evolved through VMFS-5 to VMFS-6, gaining larger volumes/files, GPT partitions, better space reclamation (UNMAP), and automatic block-size handling. Modern vSphere also adds storage abstractions that did not exist in VI3:

• vSAN: software-defined storage that pools the local disks of cluster hosts into a single shared datastore, removing the need for an external SAN.
• Virtual Volumes (vVols): per-VM storage objects that let array features apply at VM granularity.
• Storage policies (SPBM): policy-based management so a VM requests capabilities (e.g., "encrypted, mirrored") rather than a specific LUN.

A practical concept worth knowing is the raw device mapping (RDM), which lets a VM access a SAN LUN directly when an application requires it (for example, certain clustering setups), as an alternative to a normal .vmdk.

Resource Management: CPU and Memory Controls

Because many VMs share one host, ESX needed precise controls to arbitrate contention fairly. Three mechanisms, still central in vSphere, do this:

• Shares: a relative priority weighting. When resources are scarce, a VM with more shares gets a proportionally larger slice. When resources are plentiful, shares are irrelevant.
• Reservations: a guaranteed minimum amount of CPU (MHz) or memory (MB) that is set aside for a VM regardless of contention.
• Limits: a hard ceiling that prevents a VM from consuming more than a set amount, even if the host has spare capacity.

Resource pools

A resource pool is a logical container that groups VMs and applies shares, reservations, and limits at the group level. Pools can be nested, so an administrator might give the "Production" pool more shares than "Development," then let VMs inside each pool compete for that pool's allocation. This is how teams enforce capacity guarantees and prevent a noisy workload from starving others.

VMotion: Live Migration Without Downtime

VMotion (now styled vMotion) was the feature that made virtualization feel like magic: it moves a running VM from one host to another with no downtime and no dropped sessions. It works by copying the VM's active memory state to the destination host over a dedicated network while the source keeps running, iteratively syncing changed pages, then switching execution to the destination in a fraction of a second.

Classic vMotion requirements

• Shared storage reachable by both hosts (so only memory/CPU state must move, not the disk).
• A dedicated, low-latency VMkernel network for the migration traffic (originally GbE; 10GbE+ today).
• Compatible CPUs across hosts; Enhanced vMotion Compatibility (EVC) masks CPU feature differences within a family to keep a cluster migratable.

vMotion has since grown well beyond VI3's limits. Storage vMotion moves a VM's files between datastores live; Enhanced/XvMotion can migrate without shared storage; and modern versions support cross-vCenter and even long-distance migrations. The original concept, though, is exactly what shipped in VI3.

High Availability (HA) and Distributed Resource Scheduler (DRS)

vMotion is a manual, planned operation. VI3 added two cluster-level services that automate availability and balancing, and both remain pillars of vSphere.

VMware HA (High Availability)

HA protects against host failure. You group hosts into a cluster; the hosts monitor one another, and if a host crashes, HA automatically restarts that host's VMs on the surviving hosts using the shared storage they all see. Note the distinction: HA is a restart mechanism, so affected VMs do reboot, meaning there is a brief outage rather than zero downtime. (For zero-downtime protection of a single critical VM, VMware later added Fault Tolerance, which runs a lockstep shadow copy.) Early HA relied on legacy agents; vSphere 5 re-architected it around the FDM (Fault Domain Manager) agent with a master/slave election that is far more robust.

VMware DRS (Distributed Resource Scheduler)

DRS optimizes performance across a cluster. It continuously evaluates the CPU and memory load on every host and uses vMotion to rebalance VMs so no host is overloaded while others sit idle. At VM power-on, DRS also performs intelligent initial placement, choosing the best host automatically. You can run DRS in manual, partially automated, or fully automated mode, and use affinity/anti-affinity rules to keep certain VMs together or apart. A related feature, Distributed Power Management (DPM), consolidates VMs during quiet periods and powers off idle hosts to save energy.

How HA and DRS work together

In a well-built cluster, DRS keeps everyday load balanced, and HA stands by to recover instantly if hardware dies, both depending on shared storage and a reliable management network, exactly the design VI3 established.

Putting It Together: The Modern vSphere Stack

If you started from VI3 concepts and updated every name, you would arrive at today's platform. ESXi hosts (the thin, console-free hypervisor) run your VMs; vCenter Server, usually deployed as the Linux-based VCSA appliance rather than on Windows, provides the single pane of glass that enables vMotion, DRS, and HA across a cluster; the browser-based vSphere Client replaces the old Windows VI Client; and storage spans VMFS-6, NFS, vSAN, and vVols. The mental model, hypervisor plus central management plus shared storage plus live migration plus automated availability, is unchanged. Only the implementations have matured.

Key Takeaways

• ESX/VI3 is end-of-life: learn it as foundational concepts, but run modern vSphere (ESXi + vCenter/VCSA) in production.
• The Service Console is gone: ESXi removed it for a smaller, more secure footprint; manage hosts via DCUI, ESXi Shell, the vSphere Client, and PowerCLI.
• Shared storage is the enabler: VMFS datastores (now VMFS-6, plus vSAN/NFS/vVols) let multiple hosts reach the same VM files, which is what makes vMotion and HA possible.
• vMotion, DRS, and HA divide the work: vMotion moves running VMs live, DRS balances performance automatically, and HA restarts VMs after a host failure.
• Resource controls are precise and current: shares, reservations, limits, and resource pools still govern how VMs share CPU and memory.

Frequently Asked Questions

What is the difference between ESX and ESXi?

Classic ESX included a Linux-based Service Console for management, which increased its footprint and attack surface. ESXi removed the Service Console, leaving a thin, integrated hypervisor managed through the DCUI, shell, vSphere Client, and APIs. ESXi fully replaced ESX as of vSphere 5.0, so all current VMware hosts are ESXi.

Is VMFS still used, and what version should I expect today?

Yes. VMFS is still the native clustered file system for block storage, but VI3's VMFS-3 has been succeeded by VMFS-6, which supports larger volumes and files, GPT partitioning, and automatic space reclamation. Many environments now also use vSAN, NFS, or vVols alongside or instead of traditional VMFS LUNs.

What is the difference between HA and vMotion?

vMotion is a planned, live migration of a running VM with no downtime, typically used for maintenance or balancing. HA is automatic disaster recovery: when a host crashes unexpectedly, HA restarts the affected VMs on surviving hosts, which means a brief reboot rather than zero downtime. They complement each other rather than overlap.

Did VirtualCenter become vCenter?

Yes. VirtualCenter 2.0 was the VI3-era central management server; it was renamed vCenter Server in the vSphere era and is now most commonly deployed as the self-contained Linux vCenter Server Appliance (VCSA), retiring the older Windows-based installation.

Enjoyed this breakdown? Subscribe on YouTube @explorenystream for more.