El Sun, 26 Sep 2010 22:52:33 +0200, carlopmart escribió:
Camaleón wrote:
No depende.
A ver, con ESXi (o cualquier hypervisor) no puedes evitar la capa de software
¿A que capa de software te refieres?
Al hypervisor (ESXi).
. El sistema operativo no se comunica directamente con el
harwdare sino con el hypervisor
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.
... 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).
Y ahora que lo pienso... supongo que no se admitirán bugzillas en openSUSE sobre sistemas virtualizados (instalados mediante ESXi, que es código cerrado), lo cual puede complicar un poco más las cosas al administrador.
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 >:-)
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 :-)
De OpenSolaris solo hay un fork.
Illumos y OpenIndiana, que yo sepa :-? Menos da una piedra.
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? 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.
http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
Que RedHat haya desarrollado una versión de pago o personalizada para sus sistemas no afecta para nada a KVM ni a su licencia.
Eso lo dices tú. A ver: ¿porque RedHat no puede cerrar el código y cambiar la licencia??
¿Y quién te ha dicho que no puede hacerlo? Pero el código actual de KVM es GPL. Si la siguiente versión se cierra a cal y canto (se "privatiza"), puedes hacer un fork de la última versión GPL y mantenerla tú mismo. Parece mentira que aún no conozcas las ventajas de la licencia GPL :-)
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 y permitir que se pueda desarrollar un fork. Ellos NO han cambiado la licencia del producto, sólo han dejado de mantenerlo.
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 >:-) 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?
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
Pues te sigo diciendo que no es comparable. ¿Tiene virtualbox un watchdog que controle el funcionamiento de las VMs y te avise de una u otra forma en caso de caida? No lo creo, vmware server sí o sea que virtualbox no le gana en nada al server a nivel de servidor porque no sabe funcionar como tal.
Seguro que sí lo tiene (mediante las herramientas "vboxtools" o con "vmboxmanage"). Mira, hasta tienes un SDK que permite desarrollar aplicaciones de ese tipo:
http://beyondtc.wordpress.com/2010/04/22/virtualbox-sdk-machine-status/
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.
y no me convencerás de lo contrario. Y el SDK lo tienen KVM, Vmware, Xen y demás ...
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