[CentOS-es] Maquinas Virtuales

Jue Ene 2 18:23:16 UTC 2014

El día 2 de enero de 2014, 14:28, David González Romero
<dgrvedado en 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.duarte en gmail.com> escribió:
>
>> El día 2 de enero de 2014, 12: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
>>
>>
>> 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 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


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