{"id":37939,"date":"2019-10-31T22:20:41","date_gmt":"2019-10-31T19:20:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obshhie-printsipy-raboty-qemu-kvm\/"},"modified":"2019-10-31T22:20:41","modified_gmt":"2019-10-31T19:20:41","slug":"obshhie-printsipy-raboty-qemu-kvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/obshhie-printsipy-raboty-qemu-kvm","title":{"rendered":"Allgemeine Prinzipien der Arbeit mit QEMU-KVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Allgemeine
\n
\nMein aktuelles Verst\u00e4ndnis:<\/p>\n

1) KVM<\/h2>\n

\nKVM (Kernel-based Virtual Machine) \u2013 ein Hypervisor (VMM \u2013 Virtual Machine Manager), der als Modul im Linux-Betriebssystem arbeitet. Der Hypervisor wird ben\u00f6tigt, um Software in einer nicht existierenden (virtuellen) Umgebung auszuf\u00fchren und dabei die reale physische Hardware, auf der diese Software l\u00e4uft, vor dieser Software zu verbergen. Der Hypervisor fungiert als \"Vermittler\" zwischen der physischen Hardware (Host) und dem virtuellen Betriebssystem (Gast).<\/p>\n

Da KVM ein Standardmodul des Linux-Kernels ist, erh\u00e4lt es alle n\u00f6tigen Funktionen (Speicherverwaltung, Scheduler usw.) vom Kernel. Folglich kommen all diese Vorteile letztendlich auch den G\u00e4sten zugute (da die G\u00e4ste auf einem Hypervisor arbeiten, der im Kernel des Betriebssystems l\u00e4uft).<\/p>\n

KVM ist sehr schnell, aber allein gen\u00fcgt es nicht, um ein virtuelles Betriebssystem zu starten, da hierf\u00fcr eine I\/O-Emulation erforderlich ist. F\u00fcr I\/O (Prozessor, Festplatten, Netzwerk, Video, PCI, USB, serielle Schnittstellen usw.) verwendet KVM QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

\nQEMU (Quick Emulator) \u2013 ein Emulator f\u00fcr verschiedene Ger\u00e4te, der es erm\u00f6glicht, Betriebssysteme, die f\u00fcr eine Architektur vorgesehen sind, auf einer anderen zu starten (zum Beispiel ARM \u2192 x86). Neben dem Prozessor emuliert QEMU verschiedene Peripherieger\u00e4te: Netzwerkkarten, HDDs, Grafikkarten, PCI, USB usw.<\/p>\n

So funktioniert es:<\/p>\n

Anweisungen\/bin\u00e4rer Code (zum Beispiel ARM) werden mittels des TCG (Tiny Code Generator) in eine zwischenplattformunabh\u00e4ngige Code umgewandelt, und dieser plattformunabh\u00e4ngige Bin\u00e4rcode wird dann in die Zielanweisungen\/code (zum Beispiel x86) umgewandelt.<\/p>\n

ARM \u2192 Zwischenkodierung \u2192 x86<\/p>\n

Im Grunde genommen k\u00f6nnen Sie virtuelle Maschinen auf QEMU auf jedem Host betreiben, selbst auf \u00e4lteren Prozessoren, die Intel VT-x (Intel Virtualization Technology) \/ AMD SVM (AMD Secure Virtual Machine) nicht unterst\u00fctzen. Allerdings wird es in diesem Fall sehr langsam funktionieren, da der auszuf\u00fchrende Bin\u00e4rcode zur Laufzeit zweimal mit TCG (TCG ist ein Just-in-Time-Compiler) neu kompiliert werden muss.<\/p>\n

Das hei\u00dft, QEMU an sich ist extrem cool, funktioniert aber sehr langsam.<\/p>\n

3) Schutzringe<\/h2>\n

\n\"Allgemeine
\n
\nDer bin\u00e4re Programmcode auf Prozessoren wird nicht einfach so ausgef\u00fchrt, sondern befindet sich auf verschiedenen Ebenen (Ringen \/ Schutzringen) mit unterschiedlichen Zugriffsebenen auf die Daten, vom privilegiertesten (Ring 0) bis zum am st\u00e4rksten regulierten und \"eingeschr\u00e4nkten\" (Ring 3).<\/p>\n

Das Betriebssystem (OS-Kernel) l\u00e4uft im Ring 0 (Kernelmodus) und kann mit beliebigen Daten und Ger\u00e4ten alles tun, was es m\u00f6chte. Benutzeranwendungen laufen im Ring 3 (Benutzermodus) und d\u00fcrfen nicht tun, was sie wollen, sondern m\u00fcssen jedes Mal um Erlaubnis bitten, um eine bestimmte Operation durchzuf\u00fchren (so haben Benutzeranwendungen nur Zugang zu ihren eigenen Daten und k\u00f6nnen nicht in die \"Sandbox\" anderer eindringen). Die Ringe 1 und 2 sind f\u00fcr Treiber vorgesehen.<\/p>\n

Vor der Erfindung von Intel VT-x \/ AMD SVM arbeiteten Hypervisoren im Ring 0, w\u00e4hrend G\u00e4ste im Ring 1 t\u00e4tig waren. Da Ring 1 nicht \u00fcber ausreichende Berechtigungen f\u00fcr den normalen Betrieb eines OS verf\u00fcgt, musste der Hypervisor bei jedem privilegierten Aufruf vom Gastbetriebssystem diesen Aufruf in Echtzeit modifizieren und im Ring 0 ausf\u00fchren (\u00e4hnlich wie es QEMU tut). Das bedeutet, dass der Gast-bin\u00e4re Code NEIN<\/i><\/b> direkt auf der CPU ausgef\u00fchrt wurde und bei jedem Aufruf mehrere Zwischenmodifikationen in Echtzeit durchlief.<\/p>\n

Die Overhead-Kosten waren erheblich und dies war ein gro\u00dfes Problem, sodass die Prozessorhersteller unabh\u00e4ngig voneinander eine erweiterte Befehlssatzarchitektur (Intel VT-x \/ AMD SVM) ver\u00f6ffentlichten, die es erm\u00f6glichte, den Code der Gastbetriebssysteme DIREKT<\/i><\/b> auf der Host-CPU auszuf\u00fchren (unter Umgehung aller kostspieligen Zwischenstufen, wie es zuvor der Fall war).<\/p>\n

Mit Intel VT-x \/ AMD SVM wurde ein spezieller neuer Ring -1 (minus eins) geschaffen. Jetzt l\u00e4uft der Hypervisor darauf und die G\u00e4ste arbeiten im Ring 0 und erhalten privilegierten Zugriff auf die CPU.<\/p>\n

Das bedeutet letztendlich:<\/p>\n