Understanding Server Virtualization: Hypervisors and Virtual Switches

1. The "Why": Solving Server Sprawl

Before virtualization became mainstream, the standard practice was a "one application, one server" model. This led to a phenomenon known as server sprawl, where data centers became filled with hundreds or thousands of physical servers, each running a single application and often being severely underutilized.

This created significant challenges:

• High Capital Expenditures (CapEx): The constant need to purchase new physical servers.
• High Operational Expenditures (OpEx): Massive costs for power, cooling, and physical rack space.
• Inefficiency: Most servers were idle much of the time, wasting resources.
• Slow Deployment: Provisioning a new physical server for an application could take days or weeks.

Server virtualization addresses these problems by allowing a single, powerful physical server to host multiple independent "virtual machines" (VMs).

2. The "How": Introducing the Hypervisor

The magic behind server virtualization is a piece of software called a hypervisor, or Virtual Machine Monitor (VMM). The hypervisor is responsible for abstracting the physical hardware (CPU, memory, storage, networking) and presenting virtualized versions of that hardware to each VM. The physical server is called the host, and the VMs running on it are called guests.

Hypervisors are broadly categorized into two types, and understanding their architectural differences is fundamental.

Type 1 vs. Type 2 Hypervisors

To reinforce those concepts with a more visual explanation, the following video provides clear examples and analogies.

Here is a summary of the key distinctions:

For your work in enterprise networking and for the CCNP exam, Type 1 hypervisors are the primary focus, as they form the foundation of modern data centers and private clouds.

3. Virtual Networking: The Virtual Switch

Now for the part that matters most to a network professional: how do these VMs communicate? Each VM has one or more virtual Network Interface Cards (vNICs). To connect these vNICs to each other and to the outside world, the hypervisor includes a virtual switch (vSwitch).

A vSwitch is a software-based Layer 2 switch that runs inside the hypervisor. It allows VMs on the same host to communicate with each other directly, with the traffic never leaving the physical server. This is extremely fast as it all happens in memory.

To connect to the physical network, the vSwitch uses the physical NICs of the host server as uplinks.

This diagram illustrates the complete architecture:

Virtual Switch Deep Dive: Components and VLANs

Just like a physical Cisco switch, a vSwitch has its own set of components and configurations. The most common implementation you'll encounter is VMware's vSphere, so we will use it as a practical example.

Let's summarize the VLAN tagging methods, as this is a frequent point of confusion:

1. External Switch Tagging (EST):

   • How it works: The vSwitch does no tagging. The physical switch port connected to the host's uplink is configured as an access port in a specific VLAN.
   • Analogy: The vSwitch port group acts like a simple hub, and the physical switch handles all VLAN assignment.
   • Use Case: Simple, but inflexible. Requires a dedicated physical uplink for each VLAN.

2. Virtual Switch Tagging (VST):

   • How it works: The vSwitch port group is assigned a VLAN ID. The vSwitch adds the 802.1Q tag before sending traffic out the uplink. The physical switch port connected to the host's uplink must be configured as a trunk port.
   • Analogy: This is the most common method and is analogous to a standard trunk link between two physical switches.
   • Use Case: The standard for carrying multiple VLANs to a single host over a shared uplink.

3. Virtual Guest Tagging (VGT):

   • How it works: The vSwitch passes all frames through without modification. A special 802.1Q trunking driver is installed inside the guest OS of the VM, which handles the tagging itself. The vSwitch port group is set to a special trunk mode (VLAN ID 4095 in VMware), and the physical switch port is also a trunk.
   • Analogy: The VM itself is behaving like a small router or switch connected to a trunk port.
   • Use Case: Rare. Used when a single VM needs to be on many VLANs simultaneously (e.g., a virtual firewall or IDS).

Conclusion

In this lesson, we have moved from the physical to the virtual world, establishing the foundational concepts of server virtualization. As a network engineer, you are no longer just responsible for the physical cables and switches; you must also understand the virtual networking environment where modern applications live.

Key Takeaways:

• Server Virtualization solves issues of cost, space, and underutilization by running multiple isolated Virtual Machines (VMs) on a single physical host.
• The Hypervisor is the core software that enables this. Type 1 (bare-metal) hypervisors run directly on hardware and are used in data centers, while Type 2 (hosted) hypervisors run on top of a desktop OS.
• Virtual Switches (vSwitches) provide Layer 2 connectivity between VMs using vNICs. They connect to the physical network via uplinks.
• Virtual Switch Tagging (VST) is the most common method for handling VLANs, where the vSwitch tags traffic and the physical switch uplink port is a trunk.

Preview of the Next Lesson:
We've just seen how a hypervisor can run a virtualized general-purpose server (like Windows or Linux). What if we could take a network appliance, like a router, firewall, or load balancer, and run it as a VM on a generic server? That is the core idea behind our next topic: describing the concept of Network Function Virtualization (NFV). We will see how the principles of server virtualization are applied to transform how we build and deploy network services.