En la lista de CentOS en Español, surgió un hilo muy interesante el mes pasado sobre sistemas de virtualización para CentOS, derivó a un tema sin salida de sistemas de virtualización que no son para CentOS, luego regresó al tema.. un usuario de la lista habló muy bien de Xen y a mi me gusta Xen y uso Xen desde fines del 2004! Pero igual he visto y probado que KVM es bueno, y en la lista puse un breve escrito sobre cómo comprender que KVM es igual de bueno pues usa algunas técnicas de paravirtualización en algunos dispositivos, aquí va (le he corregido algunas faltas y aclarado cosas que me quedaron en el aire por el apremio):
Dijo el otro usuario (y luego le respondo yo):
xen me parece mejor, porque soporta paravirtualizacion, si tienes un micro con soporte V-XM, puedes correr incluso un SO instalado y funcionando en otro disco duro. Ademas de poder direccionar hardware para un huesped en particular. No soy experto ni nada pero lo que he leido acerca de xen dan mas que ganas. Pero tambien hay que ver que quieres virtualizar, porque una cosa es un SO completo y otra es virtualizar tu propio SO para hacer como jaulas clonando tu instalacion para otros servicios.
Es verdad lo que indicas y lo apruebo. La paravirtualización es maravillosa. Y me encanta Xen y le usé mucho tiempo, y le usaré si es necesario. Sin embargo, la brecha entre sistemas full virtualizados y paravirtuales se ha ido reduciendo a casi nada. Y me explico (con simples palabras): La full virtualización (kvm por ejemplo, xen también) le asigna un slice de tiempo de procesador a la máquina virtual, esta máquina le usa directamente al procesador durante este periodo, y le guste o no, a través de herramientas incorporadas en el procesador, se le saca a la máquina del procesador y se le devuelve el control al hospedero. Ventajas: no hay que emular el procesador, no hay que usar llamadas al hospedero por parte de los invitados para acceder al procesador. Es acceso directo al procesador! Maravilloso!!! Sin embargo la full virtualización tenía algunos inconvenientes que no tenía la paravirtualización (xen por ejemplo soporta paravirtualización) y es que para el resto de dispositivos (red, disco, ram) había que emular para que las máquinas virtuales full virtualizadas accedieran a ellos. En pocas palabras: Emulación=lentitud. Entonces algunos (yo incluído) siempre decíamos que la full virtualización, tal y como se usaba en principio no traía ventajas, o mejor aún, digamos que la paravirtualización era más rápida. Por qué? porque en la paravirtualización el invitado está programado para ejecutar llamadas pre-establecidas al hospedero para realizar ciertas labores hacia dispositivos. Por ejemplo, no accede directamente a la tarjeta de red, sino que invoca a llamadas preestablecidas (funciones) en el hospedero y este le hace la comunicación de red. Lo mismo al disco, lo mismo a la ram y a otros dispositivos menos importantes ahora. Entonces no había que emular hardware.. simplemente llamadas, y el hospedero a través de su sistema operativo y drivers específicos, realizaba la labor de comunicación con la red, disco, etc... esto era rapidísimo, tan rápido como acceder desde el hospedero mismo. Lo único que podía ralentizar un poquiiiiiiiiiiiiiiiiiiiito era el hecho de la llamada misma.. pero era algo negligible.. es algo que impacta poco. Es por eso que decíamos: -> paravirtual=rapido, -> full virtual=rapido el procesador, emulado el resto. Por qué no se puede hacer una mezcla? Qué tal algo full virtual para el procesador (que es lo que es a la final) y paravirtual el resto? Bueno, pues "porque los sistemas operativos privativos no pueden ser modificados" pensaban algunos.. y si no puedo incorporar las llamadas pre-establecidas entre el invitado que corre un sistema operativo privativo y el invitado con KVM por ejemplo.. pues no puedo hacer paravirtualización! Full virtualización sin embargo no requiere de modificaciones en el SO con la finalidad de que corra como máquina virtual. Esto lo hacía útil para SO privativos. Pero lento por otro lado. Ahh.. entonces full virtualización para los privativos y paravirtualización para los que pueden ser modificados (SL)? En principio algunos pensaron así. Hasta que alguien sacó a la luz una idea: Pensemos que tengo windows, y que hago un driver de red llamado digamos virt-net que ese driver, se incorpora como todo driver de windows al kernel que corre.. y este driver tiene las llamadas pre-establecidas para comunicarse y enviar/recibir las peticiones de red con el hospedero en KVM por ejemplo. Además hago un driver llamado virt-block que igual se comunicará con el hospedero para enviar/recibir las peticiones de disco. Y hago uno llamado virt-balloon que se ocupará de mantener las llamadas pre-establecidas para comunicarse con el hospedero y atender las llamadas a las operaciones con la ram (fundamentalmente reducir/ampliar la ram en uso del invitado). Ah bacán! Todos esos drivers serán drivers "paravirtuales" y sustituirán la necesidad de drivers "emulados". Qué hay en tu mente? paravirtual=rápido, emulación=lento. Entonces qué logro? rapidez! Un sistema full virtual para acceso nativo y directo al procesador + drivers paravirtuales de red, disco y ram que permiten acceso casi directo a estos recursos a través del hospedero.. Esto lo hace KVM: - Al usar un SO Linux, estos ya vienen con los drivers paravirtuales, y funciona rapidísimo el sistema. - Al usar un SO tipo windows por ejemplo, le indicas a Windows que por favor use un disco de drivers (virtio-win) http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers y windows detectará tu tarjeta de red paravirtual, disco paravirtual y balloon paravirtual. Para esto es necesario decirle al KVM antes de comenzar a instalar que estos tres dispositivos serán de tipo virtio.. windows no verá disco al inicio, hasta que introduzcas el CD de drivers y entonces ahi verá el disco PV, red PV, etc. Rápido? rapidísimo, además de que hace latente una de las ventajas de la virtualización que es la independencia de las máquinas virtuales del hardware.. ellas no conocen el hardware bajo el que se ejecutan, sino que quien sabe del hardware es elhospedero, esto facilita la migración (cosa que también KVM hace) entre hardware, etc. Para terminar insisto: KVM y Xen son los dos sistemas de virtualización más importantes en nuestro mundillo de CentOS.. también puedes usar LXC, qemu, virtuozzo y otras cosillas, pero fundamentalmente kvm y xen son los duros. Proxmox y todos esos paneles que hablan, simplemente son paneles que manejan y facilitan el uso de los sistemas de virtualización KVM, Xen, LXC, virtuozzo... tal y como virt-manager o virsh lo hacen a su forma. Pero para mi me parece importante comprender lo que hay debajo, antes de saltar a usar un panel y ya. saludos epe