{"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 QEMU-KVM-Nutzung","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) ist ein Hypervisor (VMM \u2013 Virtual Machine Manager), der als Modul im Linux-Betriebssystem l\u00e4uft. Der Hypervisor erm\u00f6glicht es, Software in einer nicht existierenden (virtuellen) Umgebung auszuf\u00fchren und gleichzeitig die tats\u00e4chliche physische Hardware, auf der diese Software l\u00e4uft, zu verbergen. Der Hypervisor fungiert als \u201eVerbindung\u201c zwischen der physischen Hardware (Host) und dem virtuellen Betriebssystem (Gast).<\/p>\n

Da KVM ein Standardmodul des Linux-Kernels ist, erh\u00e4lt es alle erforderlichen Funktionen vom Kernel (Speicherzugriff, Scheduler usw.). Folglich profitieren auch die G\u00e4ste von all diesen Vorteilen, da sie auf einem Hypervisor betrieben werden, der im Kernel des Linux-Betriebssystems l\u00e4uft.<\/p>\n

KVM ist sehr schnell, aber alleine reicht es nicht aus, um ein virtuelles Betriebssystem zu starten, da f\u00fcr die I\/O-Simulation erforderlich ist. F\u00fcr die I\/O-Verarbeitung (Prozessor, Festplatten, Netzwerk, Video, PCI, USB, serielle Ports 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 bestimmt sind, auf einer anderen zu starten (zum Beispiel ARM \u2192 x86). Neben der CPU emuliert QEMU verschiedene Peripherieger\u00e4te: Netzwerkkarten, HDDs, Grafikkarten, PCI, USB usw.<\/p>\n

So funktioniert das:<\/p>\n

Anweisungen\/Bin\u00e4rcode (z.B. ARM) werden mit Hilfe des TCG (Tiny Code Generator) in plattformunabh\u00e4ngigen Zwischencode umgewandelt und dieser plattformunabh\u00e4ngige Bin\u00e4rcode wird dann in Zielanweisungen\/-code (z.B. x86) konvertiert.<\/p>\n

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

Im Grunde k\u00f6nnen Sie virtuelle Maschinen auf QEMU auf jedem Host ausf\u00fchren, selbst auf \u00e4lteren Prozessoren, die Intel VT-x (Intel Virtualization Technology) \/ AMD SVM (AMD Secure Virtual Machine) nicht unterst\u00fctzen. In diesem Fall funktioniert es jedoch sehr langsam, da der ausf\u00fchrbare Bin\u00e4rcode zur Laufzeit zweimal mithilfe von TCG (TCG ist ein Just-in-Time-Compiler) neu kompiliert werden muss.<\/p>\n

Das hei\u00dft, QEMU selbst ist mega beeindruckend, aber es l\u00e4uft sehr langsam.<\/p>\n

3) Schutzringe<\/h2>\n

\n\"Allgemeine
\n
\nDer Bin\u00e4rcode auf Prozessoren funktioniert nicht einfach so; er befindet sich auf verschiedenen Ebenen (Ringen \/ Schutzringe) mit unterschiedlichen Zugriffsebenen auf Daten, von den privilegiertesten (Ring 0) bis hin zu den am st\u00e4rksten eingeschr\u00e4nkten und regulierten (Ring 3).<\/p>\n

Das Betriebssystem (Kern des OS) arbeitet auf Ring 0 (Kernelmodus) und kann alles mit beliebigen Daten und Ger\u00e4ten tun. Anwendungsprogramme f\u00fcr Benutzer laufen im Ring 3 (Benutzermodus) und d\u00fcrfen nicht alles nach Belieben machen, sondern m\u00fcssen jedes Mal um Erlaubnis bitten, bevor sie eine bestimmte Operation durchf\u00fchren (somit haben Benutzeranwendungen nur Zugriff auf ihre eigenen Daten und k\u00f6nnen nicht in das \u201eSandkasten\u201c anderer eindringen). Ring 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 die G\u00e4ste im Ring 1 liefen. Da Ring 1 nicht \u00fcber gen\u00fcgend Rechte f\u00fcr das ordnungsgem\u00e4\u00dfe Funktionieren des Betriebssystems verf\u00fcgte, musste der Hypervisor bei jedem privilegierten Aufruf von der Gastsystemseite diesen Aufruf w\u00e4hrend der Ausf\u00fchrung modifizieren und im Ring 0 ausf\u00fchren (\u00e4hnlich wie es QEMU macht). Das bedeutet, dass der Gast-Bin\u00e4rcode sind<\/i><\/b> direkt auf der CPU ausgef\u00fchrt wurde, w\u00e4hrend er jedes Mal mehrere zwischenzeitliche Modifikationen durchlief.<\/p>\n

Die Overheadkosten waren erheblich und stellten ein gro\u00dfes Problem dar. Daher f\u00fchrten die Prozessorhersteller unabh\u00e4ngig voneinander einen erweiterten Befehlssatz (Intel VT-x \/ AMD SVM) ein, der es erm\u00f6glichte, den Code der Gastbetriebssysteme DIREKT<\/i><\/b> auf der Host-CPU auszuf\u00fchren (ohne die damals aufwendigen Zwischenstufen).<\/p>\n

Mit der Einf\u00fchrung von Intel VT-x \/ AMD SVM wurde eine spezielle neue Ebene Ring -1 (minus eins) geschaffen. Nun l\u00e4uft der Hypervisor darauf, w\u00e4hrend die G\u00e4ste im Ring 0 arbeiten und privilegierten Zugriff auf die CPU erhalten.<\/p>\n

Das hei\u00dft, zusammenfassend:<\/p>\n