Hypervisor

Practically every data center and every cloud is based on virtualization today. The layer that makes this possible stays invisible in everyday operation: the hypervisor. It distributes physical resources across many virtual machines and at the same time keeps them strictly separated from each other. Anyone deciding on the architecture and security of IT infrastructure should understand this layer, because below the virtual machines no further line of defense exists. At the same time, this level gives rise to security questions that have no counterpart in purely physical environments.

What is a hypervisor?

A hypervisor, also called a virtual machine monitor, is software that abstracts physical hardware and runs several operating systems in parallel on the same machine. Each virtual machine receives virtual CPU cores, memory, storage, and network cards and behaves like a standalone server. Two designs are distinguished. Type 1 hypervisors run directly on the hardware and are the standard in data centers and clouds, because they combine high performance with a small attack surface. Type 2 hypervisors run as an application on an existing operating system and are suitable for development and testing at the workplace. Modern processors support the separation of guests with dedicated virtualization functions, so that the hypervisor can broker access efficiently without guests gaining direct access to the hardware.

How it works

  • Resource allocation: The hypervisor schedules which virtual machine receives compute time and memory when, and thereby enables a considerably higher utilization of the physical servers.
  • Isolation: Each VM runs in its own, sealed-off context. Memory areas are strictly separated, access to hardware is brokered rather than granted directly.
  • Virtual networks: Virtual switches connect the VMs of a host with each other and with the physical network. A considerable part of the data traffic never leaves the host in the process.
  • Central management: A management layer controls the provisioning of new machines and moves running VMs between hosts, for example for planned maintenance.
  • High availability: If a host fails, its VMs restart on other hosts. Thanks to the migration of guests, maintenance usually runs without interrupting the services.

Why the hypervisor matters for security

  • Foundation of the infrastructure: everything that runs on the hypervisor inherits its stability. A vulnerability in this layer potentially affects all guests.
  • A high-value target: whoever controls the virtualization layer or its management controls all systems running on it along with their data.
  • Invisible east-west traffic: communication between VMs on the same host passes no physical firewall. Without additional controls, a blind spot arises in the network.
  • A lever for segmentation: at the virtual network card, rules can be enforced that the guest itself cannot switch off. This makes this level an effective starting point for microsegmentation.
  • Patch discipline: updates for the hypervisor and its management need planned time windows but are security-critical. Escapes from a VM are rare, but their effect would be comprehensive.
  • Protecting the management: the consoles and interfaces of the virtualization belong in a separate, strictly restricted management network with strong authentication.

Typical use cases

Virtualization is found in almost all areas of infrastructure today:

  • Server consolidation: many applications share a few physical hosts, with noticeable gains in utilization and energy demand.
  • Private cloud: virtual machines are created automatically in your own data center, with self-service for the business units on request.
  • VDI platforms: desktop VMs run densely packed on central hosts, and the hypervisor ensures the separation between the sessions.
  • Testing and development: type 2 hypervisors provide isolated test environments directly on the work computer.
  • Network functions at the location: firewalls and other network services run as virtual machines on compact hardware in branch offices.

Hypervisor vs. container runtime

Both technologies divide hardware between workloads but draw the dividing line at a different place. A hypervisor gives each virtual machine a complete operating system with its own kernel, so the isolation is correspondingly strong. A container runtime, by contrast, starts processes that share the host's kernel and are separated from each other via namespaces and resource limits. Containers start faster and need fewer resources but offer a thinner isolation layer: a kernel vulnerability can affect all containers of a host at once. In practice, the two approaches rarely exclude each other. Container platforms predominantly run in virtual machines. The hypervisor then provides the hard separation between tenants or security zones, while containers provide agility within these boundaries. For decision-makers, what counts is therefore less the either-or than the question of which level of isolation a workload actually needs.

Working with KAEMI

From a network perspective, the most critical question in virtualized environments is the traffic between the workloads, because it is precisely this traffic that remains hidden from physical control points. KAEMI makes it visible and controllable: with Microsegmentation , virtual machines and workloads receive precise communication rules, so that a compromised system cannot move freely across the virtual network. In addition, our Professional Services provide support on architecture questions around zone models and the protection of the management networks of virtualized platforms. If you would like to harden the network side of your virtualization, you can reach us via the contact page .

Frequently asked questions about Hypervisor

What distinguishes type 1 and type 2 hypervisors?

Type 1 hypervisors run directly on the server hardware, without an underlying operating system. They offer high performance with a small attack surface and therefore dominate in data centers and clouds. Type 2 hypervisors run as a program within a normal operating system and are suitable for testing and development at the workplace. For productive enterprise infrastructure, type 1 is the usual choice.

How strong is the isolation between virtual machines?

Very strong, because each VM has its own kernel, and modern processors enforce the separation of memory and compute time in hardware. Escapes from a VM are documented but rare and demanding in practice. The greater everyday risk is open network paths between the guests and weakly secured management access, both of which can be remedied architecturally.

What is hypervisor-based segmentation?

Here, communication rules are enforced at the virtual network card or at the virtual switch, that is, below the guest operating system. A compromised guest can neither see nor switch off these rules. This allows east-west traffic between virtual machines to be controlled without rerouting the data traffic through central firewalls. The principle is a widespread basis for microsegmentation in data centers.

Are containers more secure than virtual machines?

In terms of pure isolation, the opposite is true: virtual machines separate workloads with their own kernel and hardware support, while containers share the host's kernel. Containers, in return, score on speed and packing density. That is why both are often combined, with containers for the applications and virtual machines as a hard boundary between security zones or tenants.

Why is the management access of the virtualization so critical?

The management layer can start, copy, move, and delete virtual machines, including access to their storage. Whoever takes it over thereby controls the entire virtualized infrastructure. Management access therefore belongs in a dedicated network segment, secured with strong authentication and complete logging. Access from the general office network should be excluded.

Wondering how this looks in your own network? Talk to KAEMI: we plan, build and operate the right solution with you.