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.
Excato, la VM NO necesita el hardware físico para nada. Tú lo que haces es abstraer el hardware y hacerlo único y "estadard" para todas las VMs y de paso te ovildas de si no te va funcionar la tarjeta de red, la controladora de disco, etc.
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 ...
... luego, si tienes algún problema o te
salta algún kernel oops, no sabes qué puede estar fallando, si el kernel, el ESXi o una mezcla de ambos. Resulta que en una VM eso ses muy sencillo de comprobar. Un kernel oops en la VMs, es un problema en el hypervisor directamente (a menos que hayas hecho alguna "perrería" tú a nivel de kernel de la vm, o cosas por el estilo), bien con el hard bien con el HA, el storage, etc ..
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. 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?
Pues en openSuSE no lo sé, en Microsoft, IBM, Redhat y SAP sí los admiten.
Me refería a openSUSE, claro. No creo que estemos en la lista de MS, IBM, Redhat o SAP >:-)
Con openSuSE, repito que ni idea. Con SLES, por ejemplo, me dice un compañero que también se pueden abrir.
Ya eso mimso pensábamos los que utilizábamos openSolaris repecto a las licencias de Solaris y mira lo que ha tardado Oracle en cambiarlas ... Han hecho uno (o varios) fork ¿no? Pues hala, eso es lo que permitiría sobrevivir a KVM pero no a ESXi, que depende únicamente de la voluntad de vmware. ¿Pero desde cuando ESXi es GNU?
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. Yo no me mojaré en esto porque las he vivido de todos los colores con ambos.
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.
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.
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? 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 ...
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. y permitir que se
pueda desarrollar un fork.
Ellos no han permitido nada. Han hecho lo que te he puesto de ejemplo con RedHat. 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.
En lo que estoy de acuerdo es en que se podrá hacer un fork que se llamará X, pero no será ya KVM ...
Ah, claro. ¿Y te parece poco?
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.
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.
Pues eso es lo que se dice, se comenta... que puede funcionar sin tener activadas las extensiones en el micro. Vale, espera ... Proabdo, no funciona. He deshabilitado VT en mi laptop y ni se ejecuta ... y encima es una cuestión del 2007, ha llovido mucho desde entonces en la virtualización ...
Huy, muy rápido ha sido eso. No me lo creo >:-P
Haz la prueba por tí misma. Yo lo he probado en una RHEL 5.5.
NI vboxmanage ni vboxtools son un watchdog ejecutandose en background y chequeando las VMs ...
Te sirven para conocer el estado de la VM. Y no me digas que no sabes cómo monitorizar el estado de un sistema linux sin necesidad de usar un sistema de alerta integrado en la administrador de máquinas virtuales.
Claro que śe monitorizar pero si el producto ya me lo dá, ¿será una feature a su favor no? Saludos. -- CL Martinez carlopmart {at} gmail {d0t} com -- 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