Virtualisierung verstehen: Wie virtuelle Maschinen und Container funktionieren

Die Firma betreibt drei physische Server. Auf jedem läuft ein Dienst, und jeder ist im Schnitt zu etwa 10 Prozent ausgelastet. Der Rest der Rechenleistung, des Arbeitsspeichers und des Stroms läuft ungenutzt mit. Jetzt braucht die Firma einen vierten Server für eine neue Anwendung. Muss sie schon wieder ein Gerät kaufen, einbauen, verkabeln und absichern?

Mit Virtualisierung ginge es anders: Ein einziger kräftiger Rechner übernimmt mehrere „virtuelle“ Server, die voneinander getrennt arbeiten. Im Beitrag Was ist ein Server? haben wir den virtuellen Server schon als Variante neben dem physischen und dem Cloud-Server genannt. Hier lernst du, wie das funktioniert.

Was ist Virtualisierung?

Virtualisierung bedeutet, dass Software die physischen Ressourcen eines Rechners (Prozessor, Arbeitsspeicher, Speicher, Netzwerk) nachbildet und auf mehrere voneinander getrennte Umgebungen verteilt. Jede dieser Umgebungen verhält sich so, als hätte sie einen eigenen Rechner. Die wichtigsten Begriffe:

• Host: Der physische Rechner, auf dem alles läuft.
• Gast (Guest): Die virtuelle Umgebung auf dem Host, zum Beispiel eine virtuelle Maschine.
• Hypervisor: Die Software, die die virtuelle Hardware bereitstellt und die Gäste verwaltet.
• VM (virtuelle Maschine): Ein vollständiger virtueller Rechner mit eigenem Betriebssystem.

Das Betriebssystem im Gast sieht nur die virtuelle Hardware. Es weiß nicht, dass sie in Wirklichkeit aus Anteilen eines größeren Rechners besteht. Das Prinzip des Hardware-und-Software-Stapels kennst du aus den Beiträgen Hardware und Software und Betriebssysteme. Der Hypervisor schiebt eine weitere Schicht dazwischen.

Der Hypervisor

Man unterscheidet zwei Bauarten:

	Typ 1 („Bare Metal“)	Typ 2 („Hosted“)
Läuft	Direkt auf der Hardware, ohne ein anderes Betriebssystem darunter	Als Programm auf einem normalen Betriebssystem
Beispiele	VMware ESXi, Microsoft Hyper-V, Proxmox VE (mit KVM), Xen	VirtualBox, VMware Workstation, Parallels
Leistung	Hoch, kaum Aufwand durch eine Zwischenschicht	Geringer, das Host-Betriebssystem braucht selbst Ressourcen
Typischer Einsatz	Server im Rechenzentrum und Serverraum	Arbeitsplatz, Test und Lernumgebung

Zwei Hinweise zur Einordnung: KVM ist eine Funktion des Linux-Kernels, die Linux selbst zu einem Hypervisor macht. Zusammen mit QEMU, das die virtuelle Hardware nachbildet, ist das die Grundlage von Proxmox und vielen Linux-Lösungen. Und Hyper-V gibt es als Rolle in Windows Server, die sich wie ein Typ-1-Hypervisor verhält, auch wenn Windows dabei sichtbar bleibt. Wer das Lernen am Arbeitsplatz üben will, nimmt VirtualBox oder Hyper-V unter Windows.

Damit das Ganze schnell läuft, nutzen moderne Prozessoren Erweiterungen für Virtualisierung: Intel VT-x oder AMD-V. Sie müssen im BIOS beziehungsweise UEFI eingeschaltet sein. Unter Linux siehst du, ob dein Prozessor sie unterstützt, mit diesem Befehl:

lscpu | grep -i virtualization

Die Ausgabe nennt VT-x oder AMD-V, wenn die Funktion vorhanden ist.

Woraus eine virtuelle Maschine besteht

Baustein	Wie er in der VM aussieht	Wo er in Wirklichkeit liegt
Prozessor	Virtuelle CPUs (vCPUs)	Zeitanteile der physischen Prozessorkerne
Arbeitsspeicher	Zugeteilter RAM, zum Beispiel 8 GB	Ein Teil des RAM des Hosts
Festplatte	Eine oder mehrere virtuelle Platten	Dateien auf dem Speicher des Hosts (zum Beispiel VMDK, VHDX oder qcow2)
Netzwerkkarte	Virtuelle Netzwerkkarte mit eigener MAC-Adresse	Anschluss an einen virtuellen Switch im Host
BIOS, Grafik, USB	Nachgebildete Standardgeräte	Software im Hypervisor

Dass die virtuelle Festplatte eine Datei ist, hat praktische Folgen: Man kann eine VM kopieren, verschieben, sichern und auf einen anderen Host mitnehmen, indem man die Dateien kopiert. Zusätzlich installiert man im Gast die Gast-Erweiterungen (zum Beispiel VMware Tools, Hyper-V-Integrationsdienste oder den QEMU-Gast-Agenten). Sie verbessern Treiber, Zeitabgleich und das saubere Herunterfahren von außen.

Ressourcen verteilen und überbuchen

Ein Host hat nur begrenzte Ressourcen, die sich auf die Gäste aufteilen. Ein wichtiger Teil der Planung ist das Verhältnis von zugeteilten zu vorhandenen Ressourcen:

• Prozessor: Alle VMs teilen sich die physischen Kerne. Die Summe aller vCPUs darf größer sein als die Zahl der Kerne, weil VMs selten alle gleichzeitig rechnen. Man nennt das Überbuchung (Overcommitment) und gibt das Verhältnis als vCPU zu physischen Kernen an.
• Arbeitsspeicher: Hier ist Vorsicht geboten. Wird mehr RAM verteilt, als vorhanden ist, muss der Host in Auslagerungsdateien ausweichen, und alles wird sehr langsam. Für Server plant man meist ohne Überbuchung.

Ein Rechenbeispiel

Ein Host hat 32 physische Kerne und 256 GB RAM. Darauf laufen 24 VMs mit je 4 vCPUs und 8 GB RAM:

vCPUs: 24 × 4 = 96     →  96 vCPU ÷ 32 Kerne = 3 : 1
RAM:   24 × 8 GB = 192 GB   →  192 GB von 256 GB belegt (75 %)

Beim Prozessor ist ein Verhältnis von 3:1 bei typischen Büro-Servern oft vertretbar. Der RAM ist zu 75 Prozent verplant, es bleiben 64 GB für den Hypervisor selbst und für Wachstum. Welche Verhältnisse akzeptabel sind, hängt von der Last ab. Mit Monitoring, wie im Beitrag Monitoring verstehen, prüfst du, ob der Host dauerhaft überlastet ist.

Vorteile und Nachteile

Vorteile	Nachteile
Bessere Auslastung der Hardware, weniger Geräte	Der Ausfall des Hosts trifft alle VMs gleichzeitig
Weniger Strom, Platz und Kühlung	Zusätzliche Schicht, die verwaltet und aktualisiert werden muss
Neue Server in Minuten statt Wochen	Gefahr, dass unkontrolliert immer mehr VMs entstehen (VM-Sprawl)
Einfaches Sichern, Kopieren und Verschieben von VMs	Lizenzfragen: Betriebssysteme und Software sind auch in VMs zu lizenzieren
Isolierte Test- und Entwicklungsumgebungen	Leistungseinbußen gegenüber direkter Hardware, besonders bei Speicher und Netzwerk
Hardwareunabhängigkeit: VM läuft auf anderem Host weiter	Erfordert Wissen über die Plattform

Die Stromersparnis nachgerechnet

Die Firma ersetzt ihre drei Einzelserver durch einen Host. Annahme: Jeder alte Server zieht rund 200 W, der neue Host rund 350 W:

Vorher:  3 × 200 W = 600 W
Nachher: 1 × 350 W = 350 W
Ersparnis: 250 W

Pro Jahr: 0,25 kW × 8.760 h = 2.190 kWh
Bei 0,30 € je kWh: 2.190 × 0,30 € = 657 €

Dazu kommt weniger Abwärme, wie im Beitrag Elektrische Energie beschrieben. Die Leistungswerte sind Annahmen und hängen von den konkreten Geräten ab.

Wenn der Host ausfällt: Hochverfügbarkeit

Das größte Risiko der Virtualisierung ist die Bündelung: Fällt ein Host aus, stehen alle seine VMs. Dagegen gibt es Gegenmaßnahmen:

• Cluster: Mehrere Hosts bilden einen Verbund. Fällt einer aus, startet das System seine VMs automatisch auf einem anderen Host neu.
• Gemeinsamer Speicher: Die virtuellen Platten liegen nicht auf dem Host, sondern auf einem Speichersystem (NAS oder SAN), das alle Hosts erreichen. Dieses Speichersystem sichert man selbst wieder mit RAID, wie im Beitrag RAID verstehen.
• Live-Migration: Eine laufende VM wird ohne Unterbrechung auf einen anderen Host verschoben, etwa für Wartungsarbeiten.

Snapshots und Klone

Ein Snapshot hält den Zustand einer VM zu einem Zeitpunkt fest. Vor einem Update oder einer riskanten Änderung ist er sehr nützlich: Geht etwas schief, kehrt man mit wenigen Klicks zurück. Ein Klon ist eine Kopie der gesamten VM, aus der man schnell ein weiteres System baut. Aus einer vorbereiteten Vorlage (Template) entstehen neue Server in Minuten.

Aber Vorsicht: Ein Snapshot ist kein Backup. Er liegt auf demselben Speicher wie die VM und geht mit ihm verloren. Außerdem wächst er mit jeder Änderung, und viele oder lang liegende Snapshots bremsen die VM. Das entspricht dem, was im Beitrag RAID ist kein Backup über Snapshots gesagt wurde. Sie sind eine erste Schicht, kein Ersatz für die 3-2-1-Backup-Regel.

Netzwerk in der Virtualisierung

Auch das Netzwerk wird nachgebildet. Der Hypervisor enthält einen virtuellen Switch (vSwitch). Jede VM hängt mit ihrer virtuellen Netzwerkkarte an einem Port dieses Switches. Der vSwitch ist über die physische Netzwerkkarte des Hosts mit dem echten Netz verbunden. Jede virtuelle Netzwerkkarte hat eine eigene MAC-Adresse, wie im Beitrag MAC-Adresse und IP-Adresse beschrieben.

Besonders interessant ist das Zusammenspiel mit VLANs. Der Switch-Port, an dem der Host hängt, ist ein Trunk, wie im Beitrag Access Port und Trunk Port gezeigt. Der vSwitch ordnet jede VM einer Portgruppe mit einer VLAN-ID zu. So kann ein einziger Host VMs in verschiedenen VLANs bedienen, ohne dass für jedes VLAN ein eigenes Kabel nötig ist.

Bei Typ-2-Hypervisoren am Arbeitsplatz gibt es meist drei Anschlussarten:

Modus	Wie hängt die VM im Netz?	Typischer Einsatz
Bridged (Netzwerkbrücke)	Die VM ist wie ein eigener Rechner im LAN, mit eigener IP und MAC-Adresse	Server-Test, VM soll aus dem Netz erreichbar sein
NAT	Die VM nutzt die Adresse des Hosts, ähnlich wie im Beitrag Private und öffentliche IP-Adressen	VM braucht nur Internetzugang
Host-only	Die VM erreicht nur den Host und andere VMs, nicht das restliche Netz	Isolierte Testumgebung

Speicher: Wie die virtuellen Platten vergeben werden

Beim Anlegen einer virtuellen Platte gibt es zwei Verfahren:

• Thick Provisioning: Der gesamte Platz wird sofort reserviert. Eine VM mit 100 GB belegt 100 GB, auch wenn nur 20 GB genutzt werden.
• Thin Provisioning: Die Platte wächst bei Bedarf. Das spart Platz, erlaubt aber, mehr zu verteilen, als wirklich da ist. Wächst alles gleichzeitig, läuft der Speicher voll, und alle VMs auf ihm stehen. Deshalb gehört die Füllung des Speichers unbedingt ins Monitoring.

Container: Die leichtere Alternative

Eine VM bringt ein komplettes Betriebssystem mit. Das ist flexibel, aber schwer: Jede VM braucht Gigabyte an Speicher und startet in Minuten. Container gehen anders vor: Sie teilen sich den Kernel des Hosts, also den Kern des Betriebssystems aus dem Beitrag Betriebssysteme erklärt. In jedem Container laufen nur die Anwendung und ihre Programmbibliotheken, abgetrennt durch Mechanismen des Kernels (Namespaces und Kontrollgruppen). Das macht sie klein und schnell.

	Virtuelle Maschine	Container
Betriebssystem	Jede VM hat ein eigenes, vollständiges	Teilen den Kernel des Hosts
Größe	Meist Gigabyte	Meist Megabyte bis wenige hundert Megabyte
Startzeit	Sekunden bis Minuten	Sekunden oder weniger
Isolation	Stark, getrennte Kernel	Schwächer, gemeinsamer Kernel
Verschiedene Betriebssysteme	Ja, Windows und Linux nebeneinander	Nur solche, die zum Kernel des Hosts passen
Typischer Einsatz	Klassische Server, Betriebssysteme, starke Trennung	Anwendungen in Einzelteilen, Entwicklung, schnelle Skalierung

Beides schließt sich nicht aus. In der Praxis laufen Container oft in VMs, weil man die stärkere Trennung der VM mit der Beweglichkeit der Container verbindet.

Docker: Ein Beispiel

Docker ist das bekannteste Werkzeug für Container. Zwei Begriffe: Ein Image ist die Vorlage, ein Container ist die laufende Instanz daraus. Mit diesem Befehl startest du einen Webserver (nginx) im Hintergrund:

docker run -d --name web -p 8080:80 nginx

Die Optionen: -d startet im Hintergrund, --name web vergibt einen Namen, nginx ist das Image. Mit -p 8080:80 wird der Port 80 im Container auf den Port 8080 des Hosts veröffentlicht. Das ist dem Prinzip der Portweiterleitung aus dem Beitrag zu privaten und öffentlichen Adressen verwandt. Rufst du jetzt http://localhost:8080 auf, antwortet der Webserver im Container. Den Zustand und die Meldungen kontrollierst du so:

docker ps
docker logs web

Der erste Befehl listet laufende Container, der zweite zeigt die Ausgaben von web. Zum Beenden und Aufräumen:

docker stop web
docker rm web

Wichtig: Container sind flüchtig. Wird ein Container gelöscht, sind alle Daten darin weg. Dauerhafte Daten gehören in ein Volume oder in einen eingebundenen Ordner des Hosts, der dann ins Backup gehört. Mit diesem Befehl bindest du einen Ordner schreibgeschützt ein:

docker run -d --name web -p 8080:80 -v /srv/web:/usr/share/nginx/html:ro nginx

Die Webseiten liegen jetzt im Ordner /srv/web des Hosts, und der Container liest sie nur. Verwende Images aus vertrauenswürdigen Quellen und veröffentliche nur die Ports, die wirklich nötig sind. Sonst öffnest du unnötig Angriffsfläche. Wo viele Container zusammenspielen, übernehmen Orchestrierungssysteme wie Kubernetes das Verwalten, das ist aber ein eigenes Thema.

VMs verwalten: Befehle

Auf einem Linux-Host mit KVM und libvirt zeigt dieser Befehl alle VMs, auch ausgeschaltete:

virsh list --all

Starten und sauberes Herunterfahren einer VM mit dem Beispielnamen srv-test:

virsh start srv-test
virsh shutdown srv-test

Unter Windows Server mit Hyper-V funktioniert das in der PowerShell:

Get-VM
Start-VM -Name "srv-test"

Der erste Befehl listet die VMs mit Zustand und Ressourcen, der zweite startet srv-test. Im Alltag nutzt man dazu meist die grafische Verwaltung des Hypervisors, die Befehle helfen beim Automatisieren.

Praxisbeispiel: Der VM-Host der Firma

Die Firma kauft einen Host mit 16 Kernen und 128 GB RAM. Er läuft mit einem Typ-1-Hypervisor und ist über einen Trunk-Port an den Switch angeschlossen (Zugang zu VLAN 10 für die Verwaltung und VLAN 30 für die Server). Darauf laufen diese VMs:

Name	Rolle	vCPU	RAM	Platte	VLAN	IP-Adresse
srv-monitor	Monitoring	2	4 GB	50 GB	30	192.168.10.160
srv-web	Webserver der Firma	2	8 GB	80 GB	30	192.168.10.165
srv-test	Test und Entwicklung	2	4 GB	40 GB	30	192.168.10.175

vCPU: 2 + 2 + 2 = 6    →  6 ÷ 16 Kerne = 0,375 : 1  (keine Überbuchung)
RAM:  4 + 8 + 4 = 16 GB  →  16 von 128 GB belegt (12,5 %)

Der Host hat also viel Reserve für weitere VMs. Zwei Entscheidungen des Administrators verdienen Beachtung:

• DHCP und DNS bleiben auf dem physischen srv-infra. Würden sie in einer VM auf demselben Host liegen, könnte nach einem Totalausfall weder der Host noch ein anderes Gerät ins Netz, weil die Namensauflösung und die Adressvergabe fehlen. Kritische Basisdienste gehören nicht allein auf den Host, den sie selbst brauchen.
• Der Backup-Server srv-backup bleibt physisch und getrennt. Ein Backup auf demselben Host wie das Original wäre nach den Regeln aus dem Beitrag zur 3-2-1-Backup-Regel keines. Die VMs selbst werden regelmäßig als Ganzes auf srv-backup gesichert.

Außerdem überwacht das Monitoring den Host: Auslastung, RAM, Speicher und den Zustand der Platten darunter.

Typische Fehler und Missverständnisse

• Arbeitsspeicher überbuchen. Dann wird ausgelagert, und alle VMs werden langsam.
• Snapshots als Backup betrachten. Sie liegen auf demselben Speicher und bremsen bei längerem Bestehen.
• Alles auf einen Host ohne Plan für den Ausfall. Eine Hochverfügbarkeitslösung oder zumindest ein gutes Backup ist nötig.
• Basisdienste nur im eigenen Host. DNS, DHCP und die Anmeldung müssen auch bei einem Totalausfall erreichbar sein.
• VM-Sprawl. Wer nichts dokumentiert und aufräumt, hat bald hunderte vergessene VMs, die niemand patcht.
• Hypervisor nicht aktualisieren. Er sitzt unter allen VMs und ist ein attraktives Ziel.
• Thin Provisioning ohne Überwachung. Läuft der Speicher voll, stehen alle VMs.
• Daten im Container speichern. Sie sind weg, sobald der Container gelöscht wird.
• Container für sicher isoliert halten wie eine VM. Der gemeinsame Kernel bedeutet eine schwächere Trennung.
• Lizenzen vergessen. Betriebssysteme und Anwendungen sind in VMs ebenfalls zu lizenzieren. Prüfe die Bedingungen deiner Hersteller.

Zum Üben

1. Erkläre die Begriffe Host, Gast und Hypervisor.
2. Nenne je zwei Beispiele für Typ-1- und Typ-2-Hypervisoren.
3. 24 VMs mit je 4 vCPUs laufen auf einem Host mit 32 physischen Kernen. Wie hoch ist das Überbuchungsverhältnis?
4. Vier physische Server mit je 250 W werden durch einen Host mit 400 W ersetzt. Wie hoch ist die Ersparnis im Jahr bei 0,30 € je kWh?
5. Worin unterscheiden sich Container und virtuelle Maschinen beim Betriebssystem?
6. Warum ist ein VM-Snapshot kein Backup?
7. Was bedeutet -p 8080:80 im Docker-Befehl?
8. Ein Host hat 128 GB RAM, davon braucht der Hypervisor 16 GB. Wie viele VMs mit je 8 GB passen ohne Überbuchung?

Lösungen:

(1) Host: der physische Rechner. Gast: die virtuelle Umgebung auf ihm.
    Hypervisor: die Software, die virtuelle Hardware bereitstellt und die
    Gäste verwaltet.

(2) Typ 1: VMware ESXi, Hyper-V, Proxmox (KVM), Xen.
    Typ 2: VirtualBox, VMware Workstation, Parallels.

(3) 24 × 4 = 96 vCPUs. 96 ÷ 32 = 3 : 1

(4) Vorher 4 × 250 = 1.000 W, nachher 400 W, Ersparnis 600 W.
    0,6 kW × 8.760 h = 5.256 kWh
    5.256 × 0,30 € = 1.576,80 €

(5) Jede VM hat ein eigenes, vollständiges Betriebssystem. Container teilen
    sich den Kernel des Hosts.

(6) Er liegt auf demselben Speicher wie die VM und geht bei einem Ausfall
    mit verloren. Außerdem wächst er und bremst die VM.

(7) Der Port 80 im Container wird auf den Port 8080 des Hosts veröffentlicht.

(8) (128 − 16) ÷ 8 = 14 VMs

Das solltest du dir merken

• Virtualisierung verteilt die Ressourcen eines Hosts auf mehrere getrennte virtuelle Umgebungen. Der Hypervisor stellt die virtuelle Hardware bereit.
• Typ-1-Hypervisor laufen direkt auf der Hardware (ESXi, Hyper-V, Proxmox mit KVM), Typ-2 als Programm auf einem Betriebssystem (VirtualBox).
• Eine VM besteht aus virtuellen Bauteilen, ihre Platte ist eine Datei. Prozessoren lassen sich überbuchen, Arbeitsspeicher besser nicht.
• Das Risiko liegt in der Bündelung: Cluster, gemeinsamer Speicher und Backups gehören zur Planung.
• Der virtuelle Switch bindet VMs über einen Trunk in VLANs ein.
• Container teilen den Kernel, sind klein und schnell, aber schwächer isoliert. Daten gehören in Volumes.
• Snapshots ersetzen kein Backup. Basisdienste und Backup gehören nicht allein auf den Host, den sie selbst brauchen.

Damit endet der Block zu Servern und Infrastruktur. Alles, was du dort aufgebaut hast, will auch geschützt werden. Im nächsten Block geht es um die Grundlagen: Was heißt Sicherheit in der IT eigentlich, und wogegen schützt man sich? Los geht es mit IT-Sicherheit Grundlagen.