VMware vSphere / ESXi – Grundlagen

Was ist VMware vSphere / ESXi?

VMware ESXi ist der verbreitetste Enterprise-Hypervisor weltweit. Er läuft direkt auf der physischen Server-Hardware (Typ-1 / Bare-Metal), ohne ein klassisches Betriebssystem darunter. Du kannst darauf dutzende virtuelle Maschinen (VMs) betreiben, die sich komplett unabhängig voneinander verhalten – jede mit eigenem OS, eigenem Netzwerk und eigener virtueller Festplatte.

vSphere ist der Name des Gesamtpakets von VMware (heute Broadcom), das ESXi als Hypervisor plus vCenter Server als zentrale Verwaltungskonsole beinhaltet. Wenn jemand im KMU von «dem VMware» spricht, meint er fast immer die Kombination aus ESXi-Hosts und vCenter.

Die drei Schichten der vSphere-Architektur

Optional kommen dazu:

Wichtige Begriffe auf einen Blick

ESXi-Host: Erste Schritte nach der Installation

Nach der ESXi-Installation erreichst du den Host direkt über den Browser: https://<ESXi-IP>/ui (DCUI – Direct Console User Interface für Erstkonfiguration über lokale Konsole).

Grundkonfiguration per DCUI (Konsolenzugang)

Nach dem Boot erscheint die DCUI (gelbes/graues Textmenü). Dort konfigurierst du:

1. Netzwerk: Management-IP, Subnetz, Gateway, DNS
2. Tastatur/Zeitzone: Korrekte Zeitzone setzen (wichtig für Logs und Zertifikate)
3. Root-Passwort: Sicheres Passwort setzen – du wirst es brauchen, wenn vCenter nicht erreichbar ist

ESXi per SSH verwalten (esxcli / esxi Shell)

SSH auf ESXi ist standardmässig deaktiviert. Aktivieren im vSphere Client unter Host > Verwalten > Dienste > SSH.

# ESXi-Version anzeigen
esxcli system version get

# Netzwerk-Informationen
esxcli network ip interface list
esxcli network ip address list

# NIC-Statistiken (Fehler, Drops)
esxcli network nic stats get -n vmnic0

# Alle VMs und deren Power-Status
esxcli vm process list

# VM per Kommandozeile starten (World-ID aus obigem Befehl)
vim-cmd vmsvc/power.on <vmid>

# Datastore-Belegung anzeigen
esxcli storage filesystem list

# Snapshot-Status aller VMs
vim-cmd vmsvc/snapshot.get <vmid>

Virtuelle Maschinen erstellen und verwalten

Neue VM anlegen (vSphere Client)

1. Rechtsklick auf den Host oder Cluster > Neue virtuelle Maschine
2. Erstellungstyp: Neu erstellen / aus Template / OVA importieren
3. Kompatibilität: VM-Hardware-Version wählen (höher = neuere Features, aber weniger Kompatibilität für ältere Hosts)
4. Gastbetriebssystem: Windows / Linux – beeinflusst vorgeschlagene Standardwerte
5. Datastore: Speicherort für VMDK und VMX
6. CPU / RAM / Disk: Ressourcen zuweisen
7. Netzwerk: Port Group wählen
8. ISO einlegen: CD/DVD-Laufwerk > Datenspeicher-ISO

VM-Ressourcen anpassen (hot-add)

Manche VMs unterstützen Hot-Add (CPU/RAM zur Laufzeit hinzufügen), wenn die VM-Hardware-Version 8 oder höher und die VMware Tools installiert sind. Für Windows-VMs ab Server 2012 R2 ist Hot-Add für CPU und RAM in der Regel möglich, muss aber in den VM-Einstellungen unter Flags aktiviert werden.

Templates: Einmal bauen, immer wieder deployen

Statt jede VM neu zu installieren, baust du einmal eine saubere Basis-VM (z.B. Windows Server 2022, Sysprep’d), konvertierst sie zum Template, und deployest daraus in Sekunden neue VMs. Im vSphere Client: Rechtsklick auf VM > Als Template konvertieren.

# OVA-Export einer VM (aus ESXi-Shell, alternativ über vCenter)
ovftool vi://root@<esxi-ip>/<vmname> /backup/<vmname>.ova

Netzwerk: vSwitch und Port Groups

Standard-vSwitch (vSS) Aufbau

Ein ESXi-Host hat typischerweise:

• vmnic0 / vmnic1: Physische Netzwerkkarten (Uplinks)
• vSwitch0: Standard-Switch, verbunden mit vmnic0
  • VM Network: Port Group für VM-Traffic
  • Management Network: Port Group für ESXi-Verwaltung (vmk0)

VLAN-Tagging in Port Groups

Wenn dein physischer Switch 802.1Q-Trunks liefert, trägst du in der Port Group die VLAN-ID ein:

# Port Groups und VLAN-Tags auf Kommandozeile anzeigen
esxcli network vswitch standard portgroup list

Distributed Virtual Switch (vDS) vs. Standard Switch

Ein Standard-vSwitch (vSS) wird pro ESXi-Host einzeln konfiguriert – bei fünf Hosts also fünfmal dieselbe Portgruppen-Konfiguration von Hand pflegen. Ein Distributed Virtual Switch (vDS) wird dagegen einmal zentral am vCenter Server angelegt und anschliessend allen gewünschten Hosts zugewiesen. Die Konfiguration (Portgruppen, VLANs, Sicherheitsrichtlinien) liegt zentral in der vCenter-Datenbank und wird automatisch auf alle beteiligten Hosts verteilt.

Für Einzelhost-Umgebungen ohne vCenter bleibt der Standard-Switch die einzige Option. Sobald du einen Cluster mit mehreren Hosts, vMotion und HA betreibst, lohnt sich der Umstieg auf vDS spätestens dann, wenn du NIOC brauchst (z. B. um vMotion-Traffic gegenüber VM-Traffic zu drosseln) oder LACP für Uplink-Redundanz einsetzen willst.

# Physischen Uplink von vSS zu vDS umziehen (PowerCLI)
$vds = Get-VDSwitch -Name "dvSwitch-Prod"
Add-VDSwitchVMHost -VDSwitch $vds -VMHost esxi01.firma.local
Get-VMHostNetworkAdapter -VMHost esxi01.firma.local -Physical -Name vmnic1 |
  Add-VDSwitchPhysicalNetworkAdapter -DistributedSwitch $vds -Confirm:$false

Storage: Datastores und VMDK-Grundlagen

Datastore-Typen

Thin vs. Thick Provisioning – was wählen?

• Thin: Disk belegt nur den genutzten Platz – sinnvoll, wenn mehrere VMs auf einem Datastore und du den Platz effizienter nutzen willst. Risiko: Datastore läuft voll, alle VMs auf diesem Datastore frieren ein.
• Thick Lazy Zeroed: Platz wird sofort reserviert, aber noch nicht genullt. Standard für die meisten Fälle.
• Thick Eager Zeroed: Platz reserviert und genullt. Beste Performance für Datenbanken, benötigt längere Erstellungszeit.

vSAN-Grundarchitektur: Disk Groups, Fault Domains, Storage Policies

vSAN bündelt lokale Disks mehrerer ESXi-Hosts zu einem gemeinsamen, verteilten Datastore (HCI – Hyper-Converged Infrastructure) und macht damit ein separates SAN überflüssig. Für den Support-Alltag lohnt sich ein Grundverständnis der drei zentralen Bausteine.

Disk Groups: Cache- und Capacity-Tier

Jeder Host, der Storage zu vSAN beisteuert, braucht mindestens eine Disk Group bestehend aus:

• 1 Cache-Device (zwingend Flash/SSD) – im Hybrid-Modus als Lese-/Schreibcache, im All-Flash-Modus ausschliesslich als Schreibpuffer
• 1 bis 7 Capacity-Devices (SSD im All-Flash-Modus, HDD im Hybrid-Modus) – hier liegen die eigentlichen Nutzdaten

Ein Host darf bis zu 5 Disk Groups betreiben (maximal 35 Capacity-Devices pro Host). In der Praxis reicht für kleinere KMU-Cluster meist eine Disk Group pro Host – mehrere Disk Groups erhöhen primär die parallele I/O-Leistung und die Fehlertoleranz gegenüber dem Ausfall eines einzelnen Cache-Devices.

Fault Domains: mehr als nur «pro Host»

Ohne explizite Konfiguration behandelt vSAN jeden Host automatisch als eigene Fault Domain. In grösseren Umgebungen mit mehreren Racks lohnt es sich, Fault Domains manuell nach Rack oder Brandabschnitt zu definieren – so stellt vSAN sicher, dass Replikate einer VM nie im selben Rack landen und ein Rack-Stromausfall nicht gleich mehrere Kopien derselben Daten lahmlegt. Ein vSAN Stretched Cluster über zwei Standorte nutzt dasselbe Prinzip: Jeder Standort ist eine Fault Domain, dazu kommt ein Witness-Host als dritte, unabhängige Instanz.

Storage Policies: FTT und Failure Tolerance Method

Statt RAID auf Hardware-Ebene zu konfigurieren, weist du in vSAN jeder VM (oder sogar jeder einzelnen VMDK) eine Storage Policy zu (SPBM – Storage Policy Based Management). Die wichtigsten Parameter:

• Primary Level of Failures to Tolerate (FTT): wie viele gleichzeitige Host-/Disk-Ausfälle die VM überlebt (0 bis 3)
• Failure Tolerance Method (FTM): RAID-1 (Mirroring, volle Kopien) oder RAID-5/6 (Erasure Coding, Paritätsdaten, nur All-Flash)

# Neue vSAN-Storage-Policy per PowerCLI anlegen (FTT=1, RAID-1 Mirroring)
New-SpbmStoragePolicy -Name "vSAN-FTT1-Mirror" -AnyOfRuleSets (
  New-SpbmRuleSet -AllOfRules (
    New-SpbmRule -Capability (Get-SpbmCapability -Name "VSAN.hostFailuresToTolerate") -Value 1
  )
)

# Policy einer bestehenden VM zuweisen
Get-VM "SQL01" | Get-HardDisk | Set-SpbmEntityConfiguration -StoragePolicy "vSAN-FTT1-Mirror"

Für generelle RAID-Grundlagen ausserhalb von vSAN sowie eine Einordnung, wann sich klassisches NAS/SAN gegenüber HCI lohnt, siehe RAID-Level im Detail und NAS vs. SAN – die Entscheidung.

Snapshots – das zweischneidige Schwert

Snapshots sind keine Backups! Sie speichern den Delta-Zustand einer VM relativ zum Basis-Disk. Je länger ein Snapshot offen ist, desto grösser wird die Delta-Datei und desto schlechter wird die VM-Performance.

Goldene Regeln:

1. Snapshot vor riskanter Änderung erstellen (z.B. Windows-Update, Software-Installation)
2. Snapshot nach erfolgreicher Änderung sofort löschen (Consolidate)
3. Niemals länger als 72 Stunden laufen lassen
4. Auf Produktionssystemen nie mehrere gestapelte Snapshots

# Snapshot-Consolidation erzwingen (falls VMDK-Dateien verwaist sind)
vim-cmd vmsvc/snapshot.removeall <vmid>

# Alle VMs mit offenen Snapshots finden (PowerCLI)
Get-VM | Get-Snapshot | Select VM, Name, Created, SizeGB | Sort-Object SizeGB -Descending

VMware Tools – immer installieren

VMware Tools sind ein Paket aus Treibern und Diensten, das innerhalb der Gast-VM installiert wird. Ohne VMware Tools:

• Kein Graceful Shutdown / Reboot aus vCenter
• Keine IP-Adresse sichtbar in vCenter
• Kein Quiesced Snapshot (konsistenter Backup-Snapshot)
• Schlechtere Performance (kein VMXNET3, kein PVSCSI)

Installation: In der VM erscheint im vSphere Client oben eine Meldung. Unter Windows: Autorun startet den Installer. VMware Tools sollten regelmässig aktuell gehalten werden.

vSphere HA im Detail: Admission Control, Heartbeats, Isolation Response

vSphere HA sorgt dafür, dass VMs bei einem Host-Ausfall automatisch auf einem anderen Host im Cluster neu gestartet werden. Damit das zuverlässig funktioniert, braucht HA drei Mechanismen, die im KMU-Alltag oft nur oberflächlich konfiguriert sind. Allgemeine Grundlagen zu Cluster- und Hochverfügbarkeits-Konzepten findest du auch unter Virtualisierung: Hochverfügbarkeit.

Admission Control: Wie viel Reserve steckt im Cluster?

Admission Control verhindert, dass so viele VMs laufen, dass im Fehlerfall kein Host mehr genug freie Kapazität hat, um die ausgefallenen VMs aufzunehmen. Drei Policy-Typen stehen zur Auswahl:

Für einen 4-Host-Cluster, der einen Hostausfall tolerieren soll, ist ein Wert von 25 % (1 von 4 Hosts) bei Cluster Resource Percentage ein guter Ausgangspunkt. Ohne Reservierungen auf den VMs rechnet HA intern nur mit einem Minimalwert von 32 MHz CPU und 0 MB RAM pro VM – bei realistischer Lastplanung solltest du dich also nicht blind auf die Admission-Control-Warnung verlassen.

# Aktuelle HA-Konfiguration eines Clusters auslesen (PowerCLI)
$cluster = Get-Cluster "Cluster-Prod"
$cluster.ExtensionData.Configuration.DasConfig |
  Select-Object AdmissionControlEnabled, AdmissionControlPolicy

Heartbeat-Netzwerke: Wie HA einen echten Ausfall erkennt

HA nutzt zwei unabhängige Kanäle, um zu unterscheiden, ob ein Host wirklich ausgefallen oder nur isoliert ist:

1. Netzwerk-Heartbeats über das HA-Management-Netzwerk zwischen allen Hosts.
2. Datastore-Heartbeating: vSphere wählt automatisch 2 Heartbeat-Datastores aus (manuell anpassbar), auf die alle Hosts unabhängig vom Management-Netzwerk schreiben.

Antwortet ein Host weder über das Netzwerk noch über die Heartbeat-Datastores, gilt er als tatsächlich ausgefallen statt nur isoliert. Diese Unterscheidung ist wichtig: Ein Host, der nur seine Netzwerkverbindung verliert, aber noch auf den Heartbeat-Datastore schreiben kann, läuft weiter – die darauf laufenden VMs werden nicht automatisch andernorts neu gestartet, weil sie ja noch aktiv sind. Erst wenn beide Heartbeat-Kanäle ausfallen, wertet HA das als echten Host-Ausfall.

Isolation Response: Was passiert mit isolierten VMs?

Wird ein Host isoliert (kein Netzwerk-Heartbeat mehr, Host läuft aber noch), entscheidet die Isolation Response über das weitere Verhalten der dort laufenden VMs:

Konfiguration: Cluster > Konfigurieren > vSphere-Verfügbarkeit > Bearbeiten > Failure conditions and responses.

DRS: Automatisierungsstufen und Affinity-Regeln

Während HA auf Ausfälle reagiert, sorgt DRS (Distributed Resource Scheduler) im laufenden Betrieb für eine ausgeglichene Lastverteilung zwischen den Hosts eines Clusters – per vMotion, ohne dass eine VM davon etwas merkt.

Automatisierungsstufen

Der Migrationsschwellenwert (Schieberegler von konservativ bis aggressiv) bestimmt, wie stark eine Schieflage sein muss, bevor DRS überhaupt eine Migration vorschlägt oder durchführt. Für die meisten KMU-Cluster ist «Vollautomatisiert» mit mittlerem Schwellenwert ein guter Standard – die Hosts gleichen sich selbstständig aus, ohne dass ständig VMs unnötig hin- und herwandern.

Affinity- und Anti-Affinity-Regeln

Regeln steuern, welche VMs zusammen oder getrennt laufen müssen bzw. sollen:

Jede Regel wird zusätzlich als «muss» (required) oder «sollte» (preferential) definiert. «Muss»-Regeln werden von DRS, HA und vSphere DPM nie verletzt – auch nicht, wenn das bedeutet, dass eine VM im Fehlerfall gar nicht neu gestartet werden kann, weil der einzige erlaubte Host ebenfalls ausgefallen ist. Genau das ist die häufigste Falle: Eine zu strikt formulierte «muss»-Anti-Affinity-Regel kann verhindern, dass HA eine VM überhaupt neu startet, wenn beide erlaubten Hosts down sind.

# Anti-Affinity-Regel: zwei Domain Controller nie auf demselben Host
New-DrsRule -Cluster "Cluster-Prod" -Name "DC-getrennt" -KeepTogether $false -VM (Get-VM "DC01","DC02")

# VM-Host-Affinity-Gruppe fuer SQL-Lizenzierung
New-DrsVMHostRule -Cluster "Cluster-Prod" -Name "SQL-auf-Lizenz-Hosts" `
  -VMGroup "SQL-VMs" -VMHostGroup "Lizenzierte-Hosts" -Type "MustRunOn"

Resource Pools: Shares, Reservations, Limits – und die Fallstricke

Resource Pools bündeln CPU- und RAM-Ressourcen mehrerer VMs unter einem gemeinsamen Kontingent. Drei Werkzeuge steuern die Verteilung:

Bei verschachtelten Resource Pools kannst du eine Reservierung zusätzlich als «expandable» markieren: Reicht die eigene Reservierung des Pools nicht aus, darf er sich bei Bedarf von der Reservierung des übergeordneten Pools bedienen. Das ist der Standard und in den meisten Fällen sinnvoll – nur in strikten Multi-Tenant-Szenarien (z. B. Hosting mit Abrechnung pro Kunde) deaktivierst du das, damit ein Pool nicht versehentlich Ressourcen eines anderen Kunden beansprucht.

Typische Supportaufgaben im KMU-Alltag

VM hat kein Netzwerk

1. In der VM: ipconfig / ip a – hat die VM überhaupt eine IP?
2. Port Group der VM prüfen: Richtige Port Group? Richtiger vSwitch?
3. VLAN-Tag prüfen: Stimmt die VLAN-ID mit dem physischen Switch überein?
4. vmnic prüfen: Ist der Uplink des vSwitch verbunden? esxcli network nic list
5. Firewall in der Gast-VM (Windows Defender Firewall) – nicht vergessen!

VM bootet nicht

# VMDK-Dateien auf Datastore auflisten
ls /vmfs/volumes/<datastore-name>/<vm-ordner>/

# Lock auf VMDK-Datei prüfen
vmkfstools -D /vmfs/volumes/<datastore>/<vm>/<disk>.vmdk

Host überlastet

• CPU Ready: Wert über 5 % bedeutet, die VM wartet auf CPU-Zeit → weniger vCPUs zuweisen (mehr vCPUs = mehr Scheduling-Overhead) oder VM auf anderen Host migrieren
• Memory Balloon / Swap: VMware «stehlt» RAM von VMs bei Engpass → mehr RAM in Host oder VMs schlank halten
• Disk Latency: I/O-Wartezeiten über 20 ms → Datastore-Performance prüfen (viele Snapshots? Thin-Disks? Überlastetes NAS?)

# Top-Prozesse auf ESXi-Host
esxtop
# (interaktiv: 'c' für CPU-View, 'm' für Memory, 'd' für Disk, 'n' für Netzwerk)

Snapshot wächst unkontrolliert

# Consolidation-Bedarf prüfen (im vSphere Client unter VM > Zusammenfassung)
# Oder per PowerCLI:
Get-VM | Where-Object {$_.ExtensionData.Runtime.ConsolidationNeeded} | Select Name

PowerCLI: VMware per PowerShell verwalten

PowerCLI ist das offizielle PowerShell-Modul für VMware/vSphere. Für wiederkehrende Aufgaben unverzichtbar.

# PowerCLI installieren
Install-Module VMware.PowerCLI -Scope CurrentUser

# Verbinden (SSL-Warnung ignorieren für Self-Signed Certs)
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Connect-VIServer -Server vcenter.firma.local -User administrator@vsphere.local

# Alle VMs mit Status anzeigen
Get-VM | Select Name, PowerState, NumCpu, MemoryGB | Sort Name

# VMs mit offenem Snapshot
Get-VM | Get-Snapshot | Select VM, Name, Created, @{N='GB';E={[math]::Round($_.SizeGB,1)}}

# VM-Datastore-Belegung
Get-Datastore | Select Name, @{N='FreeGB';E={[math]::Round($_.FreeSpaceGB,1)}}, @{N='TotalGB';E={[math]::Round($_.CapacityGB,1)}}

# VM migrieren (vMotion)
Move-VM -VM "WebServer01" -Destination (Get-VMHost "esxi02.firma.local")

# VM-Snapshot erstellen und löschen
New-Snapshot -VM "WebServer01" -Name "vor-update-2026-06" -Memory $false -Quiesce $true
Get-VM "WebServer01" | Get-Snapshot | Remove-Snapshot -Confirm:$false

Backup-Strategien für VMware-Umgebungen

VMs sichert man nicht durch Snapshots, sondern durch dedizierte Backup-Lösungen, die VADP (vSphere Storage APIs for Data Protection) nutzen:

Veeam Community Edition ist für KMU mit bis zu 10 VMs eine exzellente Wahl: kostenfrei, vollständig funktional, Agent-los dank VADP.

Security-Hardening: Lockdown Mode, Zertifikate, AD-Integration

Ein frisch installierter ESXi-Host ist funktional, aber nicht gehärtet. Drei Massnahmen gehören in jede produktive Umgebung.

Lockdown Mode: direkten Host-Zugriff unterbinden

Lockdown Mode verhindert, dass sich jemand direkt am ESXi-Host anmeldet (per DCUI, SSH oder ESXi-Shell) und erzwingt stattdessen die Administration über vCenter – so bleibt das zentrale Audit-Log vollständig.

Konfiguration: Host > Konfigurieren > System > Sicherheitsprofil > Lockdown-Modus bearbeiten. Die Exception-User-Liste ist für Service-Accounts von Backup-Software oder Monitoring gedacht – normale Admin-Konten gehören dort nicht rein, sonst hebelst du den Zweck von Lockdown Mode selbst wieder aus.

Zertifikate: selbstsigniert vs. eigene CA

ESXi und vCenter kommen standardmässig mit selbstsignierten Zertifikaten der internen VMCA (VMware Certificate Authority). Für den Produktivbetrieb – besonders wenn Admins regelmässig per Browser auf den vSphere Client zugreifen – lohnt sich der Ersatz durch Zertifikate der eigenen internen CA, etwa aus Active Directory Certificate Services, oder einer öffentlichen CA. Details zu Zertifikatsketten, CSR und Trust Stores findest du unter SSL/TLS-Zertifikate.

AD-Integration: zentrale Anmeldung statt lokaler Konten

Statt für jeden Admin ein lokales Konto auf vCenter zu pflegen (administrator@vsphere.local), bindest du vCenter Single Sign-On an dein Active Directory als Identitätsquelle an (Verwaltung > Single Sign-On > Konfiguration > Identitätsquellen). Danach vergibst du Berechtigungen über AD-Gruppen statt über Einzelkonten – siehe AD-Benutzer und -Gruppen für die Gruppenlogik und AD-Security-Hardening (Tier-Modell) dafür, warum Admin-Konten für die Virtualisierungsebene idealerweise in einer eigenen Tier-Gruppe liegen und nicht mit alltäglichen Domain-Admin-Konten vermischt werden sollten.

Für ein umfassenderes Grundgerüst zur Absicherung von Servern generell (nicht nur der Virtualisierungsebene) siehe Server-Hardening nach CIS-Benchmarks und IT-Security-Grundlagen für KMU.

Weiterlernen

• VMware vSphere 8.0 Dokumentation (Broadcom TechDocs) – offizielle, aktuelle Referenz
• ESXi Installation and Setup (Broadcom TechDocs) – deutschsprachige Installationsanleitung
• Getting Started with ESXCLI (VMware Docs) – CLI-Referenz für ESXi
• Nakivo: Most Useful ESXCLI Commands – praktische Befehlsreferenz
• vSphere Availability Guide (Broadcom TechDocs) – offizielle Referenz zu HA, Admission Control und Heartbeats
• Configuring and Managing Lockdown Mode (Broadcom TechDocs) – Details zu Normal- und Strict-Modus
• Grundlagen der Virtualisierung – falls du noch nicht weisst, was ein Hypervisor ist
• Virtualisierung: Hochverfügbarkeit – Cluster- und HA-Konzepte herstellerübergreifend
• Hyper-V – Grundlagen & Verwaltung – Microsofts kostenlose Alternative

Videos

YouTube

YouTube