{"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\/es\/blog\/administrirovanie\/obshhie-printsipy-raboty-qemu-kvm","title":{"rendered":"Principios generales de funcionamiento de QEMU-KVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Principios
\n
\nMi comprensi\u00f3n actual:<\/p>\n

1) KVM<\/h2>\n

\nKVM (M\u00e1quina Virtual basada en el N\u00facleo) es un hipervisor (VMM - Gestor de M\u00e1quinas Virtuales) que funciona como un m\u00f3dulo en el sistema operativo Linux. El hipervisor se necesita para ejecutar cierto software en un entorno no existente (virtual) y ocultar este software del hardware f\u00edsico real en el que se ejecuta. El hipervisor act\u00faa como un 'intermediario' entre el hardware f\u00edsico (host) y el sistema operativo virtual (invitado).<\/p>\n

Dado que KVM es un m\u00f3dulo est\u00e1ndar del n\u00facleo de Linux, recibe todas las ventajas del n\u00facleo (gesti\u00f3n de memoria, planificador, etc.). Como resultado, todas estas ventajas tambi\u00e9n se trasladan a los invitados (ya que los invitados funcionan en el hipervisor, que opera en\/en el n\u00facleo del sistema operativo Linux).<\/p>\n

KVM es muy r\u00e1pido, pero por s\u00ed solo no es suficiente para ejecutar un sistema operativo virtual, ya que se requiere emulaci\u00f3n de I\/O. Para I\/O (procesadores, discos, red, video, PCI, USB, puertos seriales, etc.), KVM utiliza QEMU.
\n<\/a><\/noindex><\/p>\n

2) QEMU<\/h2>\n

\nQEMU (Emulador R\u00e1pido) es un emulador de diversos dispositivos que permite ejecutar sistemas operativos dise\u00f1ados para una arquitectura en otra (por ejemplo, ARM -> x86). Adem\u00e1s del procesador, QEMU emula varios dispositivos perif\u00e9ricos: tarjetas de red, HDD, tarjetas de video, PCI, USB, etc.<\/p>\n

Funciona as\u00ed:<\/p>\n

Las instrucciones\/c\u00f3digo binario (por ejemplo, ARM) se convierten en c\u00f3digo intermedio independiente de la plataforma mediante un convertidor TCG (Generador de C\u00f3digo Reducido) y luego, este c\u00f3digo binario independiente de la plataforma se convierte en instrucciones\/c\u00f3digo objetivo (por ejemplo, x86).<\/p>\n

ARM -> c\u00f3digo_intermedio -> x86<\/p>\n

En esencia, puedes ejecutar m\u00e1quinas virtuales en QEMU en cualquier host, incluso en modelos de procesador antiguos que no admiten Intel VT-x (Tecnolog\u00eda de Virtualizaci\u00f3n Intel) \/ AMD SVM (M\u00e1quina Virtual Segura AMD). Sin embargo, en este caso, funcionar\u00e1 bastante lento, dado que el c\u00f3digo binario ejecutable debe recompilarse sobre la marcha dos veces, utilizando TCG (TCG es un compilador Just-in-Time).<\/p>\n

Es decir, QEMU por s\u00ed solo es incre\u00edble, pero funciona muy lento.<\/p>\n

3) Anillos de Protecci\u00f3n<\/h2>\n

\n\"Principios
\n
\nEl c\u00f3digo de programaci\u00f3n binario en los procesadores no funciona arbitrariamente, sino que se organiza en diferentes niveles (anillos \/ Anillos de Protecci\u00f3n) con diferentes niveles de acceso a los datos, desde el m\u00e1s privilegiado (Anillo 0) hasta el m\u00e1s restringido, regulado y 'con tuercas apretadas' (Anillo 3).<\/p>\n

El sistema operativo (n\u00facleo del SO) funciona en Ring 0 (modo kernel) y puede hacer lo que quiera con cualquier dato y dispositivo. Las aplicaciones de usuario funcionan en el nivel Ring 3 (modo usuario) y no tienen derecho a hacer todo lo que deseen, sino que deben solicitar acceso cada vez que necesiten realizar alguna operaci\u00f3n (as\u00ed, las aplicaciones de usuario solo tienen acceso a sus propios datos y no pueden \u00abinvadir\u00bb la \u00abarena de juegos\u00bb de otros). Ring 1 y 2 est\u00e1n destinados al uso por controladores.<\/p>\n

Antes de la invenci\u00f3n de Intel VT-x \/ AMD SVM, los hipervisores operaban en Ring 0, mientras que los hu\u00e9spedes funcionaban en Ring 1. Dado que Ring 1 no ten\u00eda suficientes privilegios para el funcionamiento normal del SO, cada vez que hab\u00eda una llamada privilegiada desde el sistema hu\u00e9sped, el hipervisor ten\u00eda que modificar esa llamada en tiempo real y ejecutarla en Ring 0 (algo similar a lo que hace QEMU). Es decir, el c\u00f3digo binario del hu\u00e9sped NO<\/i><\/b> se ejecutaba directamente en el procesador, y cada vez pasaba por varias modificaciones intermedias en tiempo real.<\/p>\n

Los costes fueron significativos y esto represent\u00f3 un gran problema, y entonces los fabricantes de procesadores, de manera independiente, lanzaron un conjunto de instrucciones ampliadas (Intel VT-x \/ AMD SVM) que permiten ejecutar el c\u00f3digo de los sistemas operativos hu\u00e9spedes DIRECTAMENTE<\/i><\/b> en el procesador del host (eliminando todos los costosos pasos intermedios, como se hac\u00eda antes).<\/p>\n

Con la llegada de Intel VT-x \/ AMD SVM, se cre\u00f3 un nuevo nivel especial Ring -1 (menos uno). Ahora en este nivel opera el hipervisor, mientras que los hu\u00e9spedes operan en Ring 0 y obtienen acceso privilegiado a la CPU.<\/p>\n

Es decir, en resumen:<\/p>\n