[CentOS-es] Maquinas Virtuales

Dom Ene 5 10:49:01 UTC 2014

Excelente epe! Muy didáctico 

Saludos,
Fabricio Palacios V.

Enviado desde mi iPhone 5

> El 05/01/2014, a las 5:18, hariseldom en gmail.com escribió:
> 
> Me ha encantado como lo expones.
> 
> Gracias por compartirlo.
> 
> El 02/01/2014, a las 16:20, "Ernesto Pérez Estévez, Ing." <ernesto.perez en cedia.org.ec> escribió:
> 
>>> 
>>> 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
>> _______________________________________________
>> CentOS-es mailing list
>> CentOS-es en centos.org
>> http://lists.centos.org/mailman/listinfo/centos-es
> _______________________________________________
> CentOS-es mailing list
> CentOS-es en centos.org
> http://lists.centos.org/mailman/listinfo/centos-es