{"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\/nl\/blog\/administrirovanie\/obshhie-printsipy-raboty-qemu-kvm","title":{"rendered":"Algemene principes van QEMU-KVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Algemene
\n
\nMijn huidige begrip:<\/p>\n

1) KVM<\/h2>\n

\nKVM (Kernel-based Virtual Machine) \u2013 hypervisor (VMM \u2013 Virtual Machine Manager), die functioneert als een module binnen het Linux-besturingssysteem. De hypervisor is nodig om software uit te voeren in een niet-bestaande (virtuele) omgeving en tegelijkertijd de echte fysieke hardware waar deze software op draait, voor deze software te verbergen. De hypervisor fungeert als een 'tussenlaag' tussen de fysieke hardware (de host) en het virtuele besturingssysteem (de gast).<\/p>\n

Aangezien KVM een standaardmodule van de Linux-kernel is, krijgt het alle voordelen van de kernel (zoals geheugenbeheer, scheduler, enz.). Uiteindelijk profiteren ook de gasten van al deze voordelen (omdat gasten draaien op de hypervisor, die op\/in de kernel van het Linux-besturingssysteem draait).<\/p>\n

KVM is erg snel, maar op zichzelf is het niet voldoende om een virtueel besturingssysteem uit te voeren, omdat hiervoor I\/O-emulatie nodig is. Voor I\/O (processor, schijven, netwerk, video, PCI, USB, seri\u00eble poorten, enz.) gebruikt KVM QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

\nQEMU (Quick Emulator) \u2013 een emulator van verschillende apparaten, die het mogelijk maakt om besturingssystemen die voor \u00e9\u00e9n architectuur zijn ontworpen, op een andere uit te voeren (bijvoorbeeld, ARM -> x86). Naast de processor emuleert QEMU verschillende randapparaten: netwerkkaarten, HDD's, videokaarten, PCI, USB, enz.<\/p>\n

Dit werkt zo:<\/p>\n

Instructies\/binaire code (bijvoorbeeld, ARM) worden omgezet in tussentijdse platformonafhankelijke code met behulp van de TCG (Tiny Code Generator) en vervolgens wordt deze platformonafhankelijke binaire code omgezet in de doelinstructies\/code (bijvoorbeeld, x86).<\/p>\n

ARM -> tussentijdse_code -> x86<\/p>\n

In wezen kun je virtuele machines op QEMU draaien op elke host, zelfs met oudere processor-modellen die geen Intel VT-x (Intel Virtualization Technology) of AMD SVM (AMD Secure Virtual Machine) ondersteunen. In dat geval zal dit echter erg traag zijn, omdat de uitvoerbare binaire code 'on the fly' twee keer moet worden hercompileren met TCG (TCG is een Just-in-Time compiler).<\/p>\n

Met andere woorden, QEMU op zichzelf is geweldig, maar werkt erg traag.<\/p>\n

3) Protection rings<\/h2>\n

\n\"Algemene
\n
\nBinaire softwarecode op processoren functioneert niet zomaar; het bevindt zich op verschillende niveaus (ringen \/ Protection rings) met verschillende toegangslevels tot gegevens, van het meest bevoorrechte (Ring 0) tot het meest beperkte, gereguleerde en 'strikt gecontroleerde' (Ring 3).<\/p>\n

Het besturingssysteem (kernel) draait op Ring 0 (kernel mode) en kan met alle gegevens en apparaten doen wat het wilt. Gebruikersapplicaties draaien op Ring 3 (user mode) en hebben niet de vrijheid om alles te doen wat ze willen; in plaats daarvan moeten ze telkens toestemming vragen om bepaalde operaties uit te voeren (op deze manier hebben gebruikersapplicaties alleen toegang tot hun eigen gegevens en kunnen ze niet 'in de zandbak van anderen' komen). Ring 1 en 2 zijn bedoeld voor gebruik door stuurprogramma's.<\/p>\n

Voor de uitvinding van Intel VT-x \/ AMD SVM, werkten hypervisors op Ring 0 en gasten op Ring 1. Omdat Ring 1 niet genoeg rechten heeft voor de normale werking van het besturingssysteem, moest de hypervisor bij elke geprivilegieerde aanroep van het gastensysteem dit aanroep wijzigen en deze uitvoeren op Ring 0 (zo ongeveer zoals QEMU het doet). Dat wil zeggen, de binaire code van de gast NIE<\/i><\/b> werd rechtstreeks op de processor uitgevoerd, maar moest bij elke keer verschillende tussentijdse wijzigingen ondergaan.<\/p>\n

De overhead was aanzienlijk en dit was een groot probleem. Toen hebben verschillende procesorfabrikanten onafhankelijk van elkaar een uitgebreide instructieset ontwikkeld (Intel VT-x \/ AMD SVM) die het mogelijk maakt om de code van de gastbesturingssystemen DIRECT<\/i><\/b> op de hostprocessor uit te voeren (waardoor alle dure tussenstappen, zoals eerder, werden omzeild).<\/p>\n

Met de komst van Intel VT-x \/ AMD SVM, werd er een speciale nieuwe laag Ring -1 (min \u00e9\u00e9n) gecre\u00eberd. En nu draait de hypervisor daarop en de gasten draaien op Ring 0 en krijgen geprivilegieerde toegang tot de CPU.<\/p>\n

Dat wil zeggen, uiteindelijk:<\/p>\n