El Mon, 27 Sep 2010 16:36:48 +0200, carlopmart escribió:
Camaleón wrote:
¿A que capa de software te refieres?
Al hypervisor (ESXi).
Ok, pero una capa de software con un footprint de 32MB a nivel de SO. ¿Eso lo consigues con vmware server o xen o kvm? De momento no.
Hablas como los de vmware... ¿no te estarás "loboto-vmwarizando"? (es broma, es broma) X-) El tamaño de la capa de software no creo que importe demasiado en este caso.
Pues eso es lo que necesito en algunos de equipos que tengo para pruebas (que el sistema dialogue directamente con los componentes de hardware) y no lo puedo obtener con un hypervisor. En cambio, las máquinas virtuales las uso para probar el software/programas/servicios, ahí sí le veo utilidad a la virtualización. Pero el uso de un hypervisor que monopoliza el hardware del equipo por completo tampoco me valdría (hablo, obviamente, de mi caso en particular). ¿Crees que podría instalar sobre ESXi el windows que viene pre-instalado en los equipos, por ejemplo? Tengo mis dudas.
Puedes. Hay trucos para hacerlo, como por ejemplo modificar la bios de la máquina virtual en un servidor ESXi y el windows se cree que está instalado en una máquina Dell, HP o IBM por ejemplo. De hecho es el truco que se utiliza para activar los Windows 7 y Windows 2008 con los famosos serials estos OEM ...
¿Y funciona bien? :-?
Hombre, puede ser un problema del kernel, no del hypervisor exclusivamente ¿no? Y ahí está el problema, a ver cómo lo depuras (probar otro kernel puede ser sencillo, pero ¿y si falla el hypervisor? tendrías que cambiar de versión de ESXi o aplicar un parche que puede afectar al resto de VM que tienes instaladas).
Vamos a ver. El control de cambios en software, actualziaciones, etc .. en un entorno de virtualización funciona igual que en un entorno físico, con la salvedad de que si eres persona previsora siempre puedes hacer rollbacks (vamos los snapshots) y volver a un entorno estable.
Igualmente puedes tener "rollbacks" en un entorno real. A lo que iba es que cuando se trata de depurar un error "x" si el sistema operativo se ejecuta sobre una capa de software (llámese ESXi) se añade un problema adicional y en este caso (usando un hypervisor) difícilmente subsanable (salvo que instales sobre hierros). Por cierto, ¿se podría pasar una VM instalada sobre el hypervisor sobre hierros? (una especie de volcado de imagen) :-?
Para aplicar un parche en un ESXi actuas de la misma manera que con cualquier otro servidor: lees el advisory de turno, evaluas, testeas y aplicas.
¿Donde están las diferencias?
La diferencia radica en que un error en el parche le puede afectar a todas las máquinas virtuales que gestiona (no a una, ni a dos, ni a tres sino a cincuenta). O que el parche solucione el problema de una VM pero te deje frita otra :-P ¿Se puede "isolar" de alguna forma esto?
Pues por eso te digo, que las soluciones propietarias pueden dejarte con el culo al aire (con perdón) con mayor facilidad que una GNU :-)
No es verdad, te pueden dejar con el trasero al aire con la misma facilidad o dificultad que una GNU.
Con la salvedad de que el código de las aplicaciones GNU es recuperable o reutilizable, hombre.
De OpenSolaris solo hay un fork.
Illumos y OpenIndiana, que yo sepa :-?
No es verdad. IllumOS es el kernel, OpenIndiana es la distro-fork derivada de OpenSolaris. IllumOS es un fork del kernel, y solo del kernel, de Solaris.
Juvar, pues... a ver, siguen dando noticias "falsas" entonces :-) OpenIndiana - Another OpenSolaris Fork - Coming Next Week http://www.phoronix.com/scan.php?page=news_item&px=ODU4OA
Cuando dices "propiedad" ¿a qué te refieres, exactamente? Que es "suyo", como puede ser tu coche si lo tienes y está a tu nombre
¿Quieres decir que es una marca registrada de Redhat?
Si.
*** http://www.linux-kvm.org/page/FAQ#Is_the_name_.27KVM.27_trademarked.3F Is the name 'KVM' trademarked? No. ***
Verás, eso no importa. No importa quien lo alimente. KVM es GPL, por tanto, si Redhat deja de mantenerlo, otros lo harán, siempre y cuando sea una tecnología que tenga aceptación y sobre la que los desarrolladores tengan interés en mantener.
Correcto. ¿Pero verdad que mañana se puede levantar el CEO de Redhat y decir: "Cerramos código y a partir de hoy iniciamos el desarrollo de KVM-2"? Indudablemente el código que era GPL hasta hoy seguirá estándolo. A partir de mañana no habrá más codigo GPL. ¿Cierto o no?
Pues claro, ¿pero sabes para que sirve? para evitar tener que migrar un sistema a otro en apneas unos días sin tener opciones para valorar debidamente las alternativas. Con un sistema de código cerrado, como ESXi o cualquier solución propietaria, podría dejar de funcionar ipso-facto. Podrían desactivar la aplicación de forma remota e impedir iniciar las VM. Y no podría hacer nada :-/
Espera veo que más abajo lo has respondido. Tema cerrado.
Parece mentira que aún no conozcas las ventajas de la licencia GPL :-)
Las concozco de sobras pero ¿sabes que pasa? que no me puedo alimentar de productos GNU, ni yo ni mi familia, por eso siempre he de pensar en soluciones tanto GNU como comerciales. Y lo siento, pero no me caso con nadie porque las ha pasado de todos los colores. Eso no quiere decir que no esté a favor de GPL/GNU, lo estoy y al 99% pero no pongo mi mano en el fuego ...
Mientras no pongas un cerrojo a las soluciones GNU, vale, pero es que más allá de ESXi no te he visto decir muchas cosas >:-)
Porque por ese mismo motivo que me des, ya podemos denunciar a Oracle por lo que hizo con openSolaris ...
¿Denunciar, por qué o en base a qué? Lo único que puedes hacer es darles las gracias por no cambiar la licencia de OpenSolaris
Perdona, la han cambiado. Entra en la web de Oracle.
Juvaaar, qué mal vamos. http://en.wikipedia.org/wiki/Opensolaris Aquí dice: "Source model: Free and open source software" ¿"To er" mundo miente ahora o qué? :-D
y permitir que se
pueda desarrollar un fork.
Ellos no han permitido nada. Han hecho lo que te he puesto de ejemplo con RedHat.
No, claro, ellos, no. La licencia de su producto que ellos han puesto. ¿Te parece poco?
Ellos NO han cambiado la licencia del
producto, sólo han dejado de mantenerlo.
HAN cambiado la licencia y de paso lo han eliminado directamente. ¿Sabes porqué? De entrada OpenSolaris es marca registrada de Oracle y ya no existrán más versiones OpenSolaris y no permiten el uso del nombre. La versión de desarrollo que liberará Oracle se llamará Solaris Express ... que no va a tener nada que ve con lo que era OpenSolaris.
¿Me quieres explicar en qué forma han cambiado la licencia de opensolaris y en qué afecta a los desarrolladores y usuarios si se trata de un producto que ya no se mantiene por parte de Oracle y que existe como un fork?
A ver qué tipo de "fork" podrías hacer con ESXi... ninguno >:-)
Vamos a ver. Por muy extraño que te parezca, ESXi tiene los mismos puntos de desaparecer que los tiene Windows, me creas o no. Por lo tanto ese escenario ahora mismo no es posible.
Te recuerdo que VMware es un "juguetito" más de una empresa gigantesca que se llama EMC...
Ahora una pregunta personal, si me lo permites... ¿no te da un poco de miedo (o repelús) basar toda tu infraestructura en los servicios de virtualización de una sola empresa?
No, en este caso porque es una empresa mjuy solvente y supongo que hablamos en relación al caso de jp_listas. Y en el caso de mi empresa y/o el de mis clientes tampoco se basan en un solo producto. Personalmente, nunca he admitido entornos homogéneos, tienen ventajas y muchos inconvenientes, uno de ellos es el que nombras.
Tampoco le estoy diciendo a jp_listas que base toda su infraestructura en ESXi, solo le digo que su upgrade path fiable es ESXi y eso vale para todas las empresas que están usando vmware server.
No hablaba de jp_listas sino de ti. En cualquier caso ¿qué otras soluciones de virtualización has implementado? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org