[CentOS-es] Maquinas Virtuales

Jue Ene 2 19:35:58 UTC 2014

Ya el problema de openSuSE que el tiempo de vida de la versión es limitado
a dos años de soporte. Algo que no estoy dispuesto a sacrificar cuando con
CentOS tengo 5. Aunque no dejo de reconocer que con zypper puedo upgradear
de versión muy fácil. Algo que hasta donde he leido NO SE PUEDE HACER CON
CENTOS.

De igual forma gracias por el dato y voy a probar en OpenSuSE el Xen. Antes
había para centos un Kernel-xen ya no lo veo en los repos... En el extra
veo: centos-release-xen.x86_64. Pero el yum info dice que no son mas que
documentos y configuraciones. Nada que ver con el Xen, manda a una Wiki
donde el primer parrafo dice:
"Standard CentOS-6 does not have the capabilities to run Xen as a
virtualisation host due to upstream vendor not shipping Xen in EL6. We are
undertaking an effort to try and fix that, with the aim of providing people
using Xen on CentOS-5 an upgrade path and also to provide people with an
option should they not find KVM to be a suiteable Virtualisation technology
in their workloads."

Igual imagino que si instalo este Xen estará optimizado para su ejecución.
Debian no es complicado, incluso si es Debian el linux que ellos dan será
una excelente opción.

Saludos,
David

El 2 de enero de 2014, 15:23, Maxi <maximiliano.duarte en gmail.com> escribió:

> 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
> _______________________________________________
> CentOS-es mailing list
> CentOS-es en centos.org
> http://lists.centos.org/mailman/listinfo/centos-es
>