El día 2 de enero de 2014, 14:28, David González Romero <dgrved...@gmail.com> escribió: > Interesante toda la explicación algo ya he leido al respecto de los metodos > de virtualizacion. Y siempre aparecen cosas nuevas. Lo cierto es que el > objetivo de mi investigación tiene varias aristas: > 1- usar SL para virtualizar preferiblemente CentOS o RHEL. > 2- poder manejar las MV a mi antojo y esto incluye: backups, snapshots, > clonación, migración > 3- levantar una maquina virtual en cuestión de minutos predefinidas (para > esto estoy viendo cosas de cloud) > > Ahora mismo cada prueba estoy haciendo en una PC que por desgracia su CPU > no soporta virtualización, o sea al correo los comandos establecidos para > saber si el micro tienen o no esta capacidad: > egrep '(vmx|svm)' /proc/cpuinfo > > O sea este comando no tiene salida alguna. Asi que imagino que la prueba no > ha de ser muy satisfactoria. Hasta ahora había podido instalar los Winrus > bien con KVM y recien acabé de instalar un CentOS Minimal, porque probe con > cuanta distro tenía a mano: Mandrivia 2010.2; OpenSuSE 12.3; Ubuntu 11.10; > Xubuntu; Vector Linux; y alguna otra y la verdad no terminaba la > instalación. Bueno lo cierto es que se quedaba colgado mucho. > > Ahora me acaban de dar una PC, pero me baje el ISO de XenServer y quiero > probarlo, porque debe ser un Linux optimizado para Xen. Alguien lo ha > probado ya?? > > Saludos, > David > > > El 2 de enero de 2014, 12:34, Maxi <maximiliano.dua...@gmail.com> escribió: > >> El día 2 de enero de 2014, 12: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 >> >> >> Excelente los tuyo Ernesto!! >> >> Hace tiempo eliminé completamente windows de mi portatil, pero >> necesitaba un win para poder correr un soft de camaras de seguridad, >> probé kvm y era mas lento la visualización que en un vnc con modem de >> 56k. Entonces use virtualbox y se veia en tiempo real, que ahora >> entiendo usas esos drivers que nombrás, para red disco y demas cosas, >> por eso la ventaja respecto al otro. Que quizas por deconocer no >> funcionaba como comentás. >> -- >> El que pregunta aprende, y el que contesta aprende a responder. >> >> No a la obsolecencia programada: >> >> http://www.rtve.es/noticias/20110104/productos-consumo-duran-cada-vez-menos/392498.shtml >> >> Linux User #495070 >> http://domonetic.com/blog >> _______________________________________________ >> 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
Suele estar basada en debian, hace mucho lo bajé pero tenia una version muy vieja. En openSuse te instala xen en segundos y tiene una GUI muy al estilo de KVM y te crea en el grub la entrada para arrancar virtualizado. cuando no tenes el micro apropiado te avisa que tipo de virtualizacion va a crear. -- El que pregunta aprende, y el que contesta aprende a responder. No a la obsolecencia programada: http://www.rtve.es/noticias/20110104/productos-consumo-duran-cada-vez-menos/392498.shtml Linux User #495070 http://domonetic.com/blog _______________________________________________ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
