Begriff
Virtual Machine (VM)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Ein Computer im Computer. Dein echter PC (Host) tut so, als wäre er mehrere PCs. Du startest ein Programm (VMware, VirtualBox), und darin bootet ein komplettes Windows oder Linux (Guest). Der Gast denkt, er hat eine echte Festplatte und CPU. In Wahrheit sind das nur Dateien auf deinem Host. Vorteil: Du kannst Linux auf Windows nutzen. Wenn die VM Viren bekommt, löschst du die Datei einfach. Dein echter PC bleibt sicher.
Merksatz: Eine Software-Emulation eines Computersystems, die es ermöglicht, mehrere Betriebssysteme isoliert voneinander auf derselben physischen Hardware auszuführen.
Cloud (EC2): Nahezu 99% der "Cloud" sind VMs. Wenn du bei Amazon einen Server mietest ("EC2 Instanz"), kriegst du keinen echten Computer. Du kriegst eine VM auf einem riesigen Amazon-Server, auf dem 50 andere VMs laufen.
Desktop: Entwickler nutzen VMs, um Software auf anderen Systemen zu testen ("Läuft meine App auf Windows 7?").
1. Hypervisor (Typ 1 vs. Typ 2)
Der Hypervisor ist der "Manager" der VMs.
- Typ 2 (Hosted): Läuft als App auf deinem OS (VirtualBox auf Windows). Langsam, weil alles durch Windows durch muss.
- Typ 1 (Bare Metal): Läuft direkt auf der Hardware (ESXi, Hyper-V, Xen, KVM). Das "Betriebssystem" ist nur dazu da, VMs zu starten. Extrem schnell. (Cloud nutzt Typ 1).
2. VM vs. Container
- VM: Hat einen eigenen Kernel. Isoliert Hardware. Schwer (GBs an RAM, Minuten zum Booten). Sehr sicher (Kernel-Isolation).
- Container (Docker): Teilt sich den Kernel mit dem Host. Isoliert Prozesse. Leicht (MBs an RAM, Millisekunden zum Starten). Weniger sicher (Kernel-Leck möglich).
3. Paravirtualisierung (VirtIO)
Früher hat der Hypervisor jede Hardware emuliert ("Ich tue so, als wäre ich eine Soundblaster Karte von 1995"). Das war langsam. Heute wissen moderne Gast-Systeme: "Ich bin in einer VM." Sie nutzen spezielle "Treiber" (VirtIO), um direkt mit dem Hypervisor zu reden ("Gib mir Netzwerk!"), statt echte Hardware zu simulieren. Das bringt fast native Performance.
Hardware-Assisted Virtualization (Intel VT-x & AMD-V)
Früher war Virtualisierung extrem quälend langsam (Soft-Virtualization/Binary Translation), weil der Hypervisor jeden Gast-Kernel Call ("Bitte RAM beschreiben") abfangen (Trappen) und in simulierte Instruktionen rückübersetzen musste (Ring 1). Moderne Cloud-Datacenter existieren nur dank Hardware-Assisted Virtualization. Intel (VT-x) und AMD (AMD-V) implementierten mit "Ring -1" (Root Mode) eine tiefe Silizium-Befehlsebene im CPU-Die. VM-Gäste können ihre nativen CPU-Register (Ring 0) in der CPU ausführen, statt auf Softwareebene abgefedert zu werden. Tritt ein hypervisor-bedürftiger Konflikt (Exit-Condition) ein (z.B. Hardware Interrupt der echten NIC), zwingt VT-x einen "VMExit" an den Hypervisor auf Hardwareebene, was Nanosekunden-Umschaltzeiten ermöglichte. Ohne diese CPU-Flags läuft auf AWS kein EC2 Instanz-Typ performant.
SR-IOV (Single Root I/O Virtualization)
Wie schießt man 25 Gigabit/s Netzwerk Traffic ohne Bottleneck dediziert in eine VM? Normale VirtIO-Netzwerk-Bridge Virtualisierung frisst extrem viel CPU (Paket in Host empfangen, in vSwitch packen, RAM-Copy an Guest weiterleiten). SR-IOV ist der absolute High-End Bypass (genutzt für AWS ENA - Elastic Network Adapter). Die physische Hardware-Netzwerkkarte (NIC) teilt sich selbst auf PCI-Express-Ebene in logische virtuelle Funktionen (VFs) auf. Jede VF hat ihre eigene MAC-Adresse am physischen PCIe Bus. Die VM krallt sich per PCI-Passthrough (IOMMU) direkt an diese VF heran. Der VM-Kernel spricht direkt mit der Silizium-NIC im Server-Rack, völlig am Hypervisor-Software-Stack vorbei! Zero Overhead.
Das Beste aus beiden Welten: MicroVMs (Firecracker)
Container (Docker) booten in Millisekunden, teilen jedoch den Kernel (Sicherheitsrisiko für Public Cloud Serverless Funktionen). Traditionelle VMs sind sicher isoliert, aber booten behäbig (Gigabytes an virtueller PCI-Hardware, BIOS, USB-Controller Simulationen).
AWS erfand zur Lösung das Open-Source Tool Firecracker MicroVMs (basierend auf KVM). Es ist ein derart brutaler Minimal-Hypervisor, der alles, was kein absolutes Basic (Netzwerk, Blockstorage) in der VM darstellt, gnadenlos weglässt. Weder VGA, USB, BIOS Screen noch Mouse-Treiber-Emulationen existieren dort.
Das Resultat: Eine Hardware-Isolierte Linux-VM kann in <125 Millisekunden booten und nutzt nur winzige 5 MB RAM! Auf dieser revolutionären MicroVM-Technologie läuft das Milliardengeschäft "AWS Lambda" Serverless-Computing.
Quick-Check
KVM?
Kernel-based Virtual Machine. Macht aus Linux einen Typ-1 Hypervisor. Standardtechnologie der meisten Clouds (AWS, Google Cloud).Nested Virtualization?
Eine VM in einer VM. (z. B. Docker Desktop auf Windows nutzt Hyper-V, um eine Linux-VM zu starten, in der Docker läuft).Overcommitment?
Der Trick der Cloud-Anbieter. Sie verkaufen mehr V-CPUs, als sie echte CPUs haben. Sie wetten darauf, dass nicht alle Kunden gleichzeitig 100% Last erzeugen. (Wie Banken, die nicht alles Geld im Tresor haben).