[CentOS-es] Maquinas Virtuales

[hariseldom en gmail.com]

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