[CentOS-es] Maquinas Virtuales

["Ernesto Pérez Estévez, Ing."]

> 
> 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 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!

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

-- 

Ernesto Pérez
+593 9 9924 6504