Excelente epe! Muy didáctico Saludos, Fabricio Palacios V.
Enviado desde mi iPhone 5 > El 05/01/2014, a las 5:18, harisel...@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.pe...@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@centos.org >> http://lists.centos.org/mailman/listinfo/centos-es > _______________________________________________ > CentOS-es mailing list > CentOS-es@centos.org > http://lists.centos.org/mailman/listinfo/centos-es _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
