Os adjunto un vídeo de la instalación "lado a lado" de 3i y de Hyper-V. Aparte del evidente efecto de marketing - aquí todos juegan al mismo juego y con las mismas reglas - os invito a reflexionar sobre el concepto del Hypervisor como Appliance. Al igual que nuestros proxies, firewalls, antispam, ¿No debería plantearse el hypervisor como un appliance, sin sistema operativo por debajo que requiera configuraciones o adaptaciones especiales? ¿no debería poder automatizarse, mediante archivo de respuestas, la instalación y configuración del mismo?. Creo que estas características son las mínimas exigibles para un despliegue en producción de un Hypervisor. Mi experiencia me va diciendo que sí, que el Hypervisor debe dar la menor lata posible. Y que cuanta menos consola, menos choque "cultural". Quizá la próxima versión de Hyper-V, esa que ha anunciado Microsoft como gratuíta, recoja el pañuelo.
Hasta entonces, os dejo el vídeo.
Side by side Comparison: Hypervisor Installation.
26 comentarios:
Todos los productos de Windows, incluido Hyper-V pueden instalarse de forma automática mediante archivo de respuestas, compadre. Sean Sistemas Operativos, Entornos gráficos, ventanitas o hypervisores.
La diferencia más importante la hacen los drivers, que son mucho más "abiertos" en Hyper-v que en ESXi. Por experiencia.
¿Drivers más abiertos? Que yo sepa, Hyper-V no tiene drivers de I/O... los tiene la máquina virtual que lo gestiona. Si es por instalación desatendida, créeme que ESX (tanto en su versión Server como i) sigue siendo más rápido a la hora de instalar que Windows 2008 con un sysprep o unnatend) Tienes la opción de crear, o bien un archivo de respuestas en la ISO (Al estilo sysprep/unnatend) o bajarlo desde un servidor web. Para más INRI, el "unnatended" de ESX permite la configuración automática de vSwitches (incluyendo VLAN ID, que en el caso de Hyper-V depende de si el driver de la tarjeta lo soporte o no), Multipath, autoformateo de Datastores, Datastores por NFS, etc... También decir que crear un archivo de respuestas para ESX no es, ni de cerca, tan complejo como crear un Sysprep con un driver no incluído en los que trae 2008
Créeme, compadre, que no es comparable. Ventajas de que un producto haga una sola cosa y la haga bien sobre otro que corre sobre un sistema operativo multipropósito.
Volvemos a lo de siempre.... una Intel e1000 vale 20€.. y está soportada.
PD: Y me da en la nariz que el "killer criteria" en el mundo de los Hypervisores no viene dado porque soportes la Realtek RTL80xx o no.
PD2: Por mucho archivo de respuestas que le des, de los dos rearranques no te salvas, querido.
PD3: Y sí. Ya sé que Hyper-V no está acabado (me ahorro el jocoso-festivo comentario respecto a los SP). Hasta entonces, mejor no comparar... ¿No te parece?
PD3: Sigo teniendo la E1000 a vuesa disposición, previa liquidación de los consecuentes Vodkas!!!
Esto... que el scripting de instalación sea mejor (y conste que aquí he de creerte, ya que no lo he probado), no quiere decir que el otro no exista.
Y a drivers más "abiertos" me refiero a que Hyper-V por el hecho de depender de W2K8 (en la versión que conozco) tiene más soporte hardware (en la VM root, claro) que ESXi. A las listas de compatibilidad me remito.
Y no es por el precio de las intel o no. Simplemente es de muchos contra pocos.
Largo es el camino, y cosas veredes, oh Sancho amigo....
Nota: a lo mejor me doy una vuelta por el SIMO, así que ya te pondré al día...
Nota 2: he dicho en la VM root, porque en las VM el soporte de puertos serie del host es inexistente en ambos.
Cosa que no es así en los productos de "menor entidad". En fin, supongo que el fax, los módems analógicos, y los puertos serie se extinguen como los dinosaurios.
"Es de muchos contra pocos"... Sí, eso parece que le pasa a Hyper-V... lo que pasa en este caso es que el de los pocos es Microsoft.
Lo dicho: Comparemos peras con peras. Y por el momento, Microsoft no tiene producto comparable a VMware en Hypervisores corporativos.
Si quieres comparar peras con peras, éste post no va de eso.
Esa ha de ser una de las razones para preferir VM a $pectra: el desequilibrio.
¡Mira que contar pulsaciones de teclado! desde los tiempos de VM, aquel sistema operativo "Virtual Machine" para IBM-370 (década de los 70) existen los comandos por lotes / scripts / batch...
No me digas que Hyper-V no tiene, por favor.
Peras con Peras y melones con melones... pechito con pechito y ombligo con ombligo...
A ver... yo en ningún caso he dicho que Hyper-V no lo tenga... de hecho lo desconozco. Lo que SI he dicho es que puedes instalar, configurar vSwitches, redes de consola, almacenamiento y demás parámetros de ESX SIN pulsar una sola tecla de manera TOTALMENTE desasistida.
PD: Por cierto, mi churrimpresora HP no me funciona en Vista 64... Vaya sistema operativo... en XP si me funciona.
¿Es mejor XP que vista por eso?
¿Más HCL hace mejor a un OS o a un Hypervisor?
¿Da soporte MS a los drivers de red o de FC de terceros? VMware SI da soporte a los de su "reducida" HCL.
Lo dicho, compadre. Peras con peras.
Ah, se me olvidaba. El comando (o shell, o como la llames) "netsh" es scriptable en XP/2003/Vista/2008 (con lo cual tambien puedes gestionar la red, Vlans, inalámbricas y todo lo que se te antoje en modo script).
¿Soporta ESXi alguna inalámbrica? ¿3G? ¿Adaptadores USB/Ethernet?
Ups... todo eso lo he puesto yo a funcionar bajo el tádem 2008/Hyper-V y las VM pueden cada una acceder a las redes que quieras, y como quieras.
Por cierto, al comparar sistemas opertativos (XP versus Vista como haces en tu últimpo comentario) no tengo claro qué quiere decir "mejor"... podríamos hablar en términos de eficiencia, compatibilidad, rendimiento, o incluso experiencia de usuario, pero ¿mejor?
Disquisiciones filosóficas de primera hora de la mañana... me hacen falta esos vodkas (y unos pocos más).
Suponiendo que uno sea el responsable de colocar 60 servidores productivos en un cluster de hypervisors y las opciones son ESX y Hyper-V hay varios puntos a tener en cuenta pero que seguro todos compartimos:
- Madurez del producto
- Seguridad del producto
- Performance
- Soporte y comunidad de usuarios
Me parece que fanatismos aparte el ganador es claro, y como dicen acá hay que comparar peras con peras, hoy día no son productos comparables sin mencionar el historial que tienen los productos de MS que recién alcanzan su madurez en su 2 o 3er service pack.
Si apenas le pueden garantizar cierta estabilidad a un par de aplicaciones en un solo servidor no me quiero imaginar a 60 VM dependiendo de él.
Slds
Esto.. sobre todo porque Hyper-V (versión gratis) no soporta clustering... A eso le llamo yo comparar peras con peras, sí señor.
Conste que sigo pensando que Hyper-V no está maduro.
Lo primero decir que me alegro mucho de ver de nuevo posts de J.L.
Lo segundo decir que automatizar el despliegue de Hyper-V es algo que se esta realizando para grandes granjas sin problema ninguno ni intervención de los usuarios.
Sobre lo de la madurez del producto, vosotros mismos pero no es algo que se este perciviendo en quien lo tiene en producción, es un producto sin problemas, estable.
Talvez si hablaramos de la beta de SCVMM si que diria que tiene que mejorar pero para eso esta la RTM.
Respecto a los drivers sin duda el poder usar cualquier driver para Windows Server es una ventaja se mire por donde se mire.
El comentario de Herman, no lo puedo entender, insinuar hoy en dia que W2K3 o W2K8 tienen problemas de estabilidad me resulta muy separado de la realidad, cuando son sistemas operativos que estan sosteniendo muchas de las aplicaciones criticas de grandes entidades.
Por ultimo yo tambien tengo claro el ganador, pero bueno, cuando tenga tiempo ya hare un post sobre el tema.
Dani:
Que tú precisamente defiendas que el I/O de un hypervisor dependa de un driver de terceros ejecutándose en una VM (por muy DOM0 que sea), y que cuando el mercado está criticando esto de Xen me parece jocoso.
Al menos el mercado en el que yo me muevo, claro.
Pues las pruebas de IO a mi me satisfacen, habra gustos de todos los colores, pero si consigo las IO que necesito es valido para mi.
De momento con los drivers de HP, DELL, IBM, etc no estoy teniendo problemas incluido en el modo core.
Volvemos al tema del bechmarking... una VM sobre un solo host evidentemente debe ir como un tiro... (si no, cambiemos el hypervisor)... Veamos ese I/O con 64 o 128 o 192 máquinas virtuales por host. Y debe set que Intel (Netqueues) o Emulex/Qlogic con NPIV deben equivocarse: No hacen falta ni tecnologías especiales ni drivers especiales para virtualizar, y como tienen a los departamentos de I+D aburriditos, les ponen a desarrollar tecnologías por gusto.
Anda, anda, mira los benchmarks de QLogic, Dell o HP y no son tirando con 1 servidor.
Yo he consolidado 117 en 5 y como la seda.
NPIV es fantastico para Hyper-V y QLogic esta encantado con Hyper-V mira en su site como asegura logra el 97% de IO con respecto al fisico usando sus HBAs (y que conste que no es que este analisis sea totalmente de mi agrado) pero desde luego IO es un punto fuerte de Hyper-V.
Y ya sabes que lo de los ratios no me gusta, hay otros parametros que se me hacen mas interesantes 192 servidores en un fisico no me llama nada, se pueda o no. Que teoricamente con hyper-v se puede, por que eso no lo he probado como es logico.
Como dice uno de mis clientes preferidos, demasiados huevos en la misma cesta. :-D
Yo por mucho que digáis no veo el problema de utilizar drivers de I/O de terceros. El fabricante es quien mejor conoce su dispositivo y quien debería realizar estos drivers optimizados.
Los drivers de I/O que utiliza VMware no están escrito por VMware, están basados en los drivers de Linux y son adaptados y certificados por VMware para ejecutarse como modulos dentro del vmkernel de ahí que la HCL sea mas reducida. De hecho os podéis bajar los drivers de IO que utiliza VMware y las modificaciones ya que son GPL y veréis como no hay muchas diferencias con el driver original.
Que estos drivers se cargen dentro del hypervisor o en la root partition o Dom0 creo que es lo de menos mientras no afecten al rendimiento y creo que el performance de I/O en Hyper-V es algo que no se puede criticar.
Al final todas las soluciones dependen en mayor medida de su Service Console o Dom0 o Root Partition. Sin este elemento ninguna solución funciona y si se cuelga, o tiene algun problema toda la arquitectura se ve afectada generalmente.
VMware lleva años con su marketing de desligarse de la Service Console y Linux. Pero técnicamente siguen dependiendo de ella, con ESXi lo único que han hecho es reducir el tamaño de esta sustituyendo Red Hat por BusyBox. Y que queréis que os diga visto que si se cuelga la Service Console se cuelga también el vmkernel y las VM…. Pues a mi me da mas confianza que sea una distribución de Red Hat que un BusyBox.
Me temo, Alberto, que en esto no cuenta lo que tú, o yo, o Dani creamos/pensemos/opinemos: Los números mandan. Y sobre los números objetivos no hay discusión por el momento.
Que si Service Console VS DOM0, que si Virtualizo por HW o hago traslación binaria... al final importa la estabilidad, las tecnologías que permiten garantizarla y los uptimes. Y esos, hoy por hoy, dicen VMware, al igual que dicen Windows Server en los entornos de servidores. Nos guste, no nos guste, opinemos o no opinemos, diga la realidad lo que nos gustaría que dijese o no.
Que si está basado en Redhat, Busybox, Windows Server... Lo fabrique Microsoft, VMware, Oracle o SUN, al final se imponen(al menos ahora) las tecnologías que se acercan a lo que el cliente requiere. Y créeme que al cliente le importa un comino el que sea el DOM0, que los drivers los haga fulano o mengano. Eso nos importa a los tecnólogos, que no deberíamos olvidar que nuestra primera herramienta debería ser el sentido común. Y el mío me dice que es más seguro que el Hypervisor controle el I/O, ya ves tú que sentido común más raro tengo.
Lo que importa es lo que funciona, lo que ha demostrado continuidad funcionando, y el que tiene la suficiente experiencia en el mercado. Y eso, hoy por hoy, está claro.
Por otro lado... si nos parece estúpido que un Servidor SQL gestione su I/O de red o disco... ¿porqué nos parece guay-de-la-muerte que una VM gestione el I/O de un hypervisor?
Respecto a lo de criticar el I/O de Hyper-V tienes razón. No se puede criticar.... porque aún no hay "producción" donde evaluarla (exceptuando, claro, 4 web servers de MSDN). Y creo que un entorno de lab de los de evaluar a-ver-quien-la-tiene-más-larga/carga-más-VM/doy-mas-gigabit-por-segundo no es justo para Hyper-V. Disculpadme si me fío tanto de los benchmark de q-logic/emulex/intel del I/O de Hyper-V como me fío de los que publica del I/O de VMware.
¿Mañana? Ya veremos. ¿Ganará la mejor tecnología, el mejor departamento de marketing, la mayor presión sobre clientes? No lo sé. Pero hoy, 9 de octubre del año del señor de 2008, la cosa está más que clara. ¿El año que viene, con rdoses, eseequis4, xenes5, equisvms y demás palabros? Ya veremos. La diferencia, creo, es que de mí puedes esperar que dentro de un año esté diciendo que Hyper-V es la repera-state-of-the-art-in-the-hypervisor-universe, o que simplemente, VMware haya desaparecido. Porque yo me baso en números, no en opiniones. No todos pueden decir lo mismo. (Dani, no saques el hacha, no va por tí (Bueno, un poquito sí - ;) - ¿Cervecita mañana/Díselo al David)
Compadre, el Amigo Herman ha dicho "Hyper-V", no "`Hyper-V gratis" que sí soporta "clustering". Eso, según MS, es comparar Peras con Peras. Eso sí, de diferentes variedades.
Y claro que no está maduro. Por eso digo que compararlos es hacerle un flaco favor a Hyper-V.
4 servidores de MSDN y otros 4 de la .com.
Tioooooo, que es una de las webs mas grandes y con mas trafico del mundo!!!!! si eso no es una referencia que venga dios y lo vea.
Dame paciencia señor, dame paciencia. ;-)
Un abrazo
Iba a responder aquí mi opinión... pero se me fue de las manos y demasiado largo, asi que he abierto un post en mi blog que os invito a que leáis :)
http://vpxd.blogspot.com/2008/10/microsoft-el-eterno-malo-de-la-pelcula.html
Un saludo,
Alberto
Estimado Daniel, como tu has dicho ahora W2K3 es ahora estable, menos mal porque si mal no recuerdo lleva 5 años desde su lanzamiento y agregó caracteristicas pedidas a gritos recien en su R2!!!
En cuanto a sistemas operativos recien lanzados es siempre conveniente esperar su madurez, esto vale para MS o Suse, Red Hat o cualquier otro S.O.
Yo soy responsable por la información de mi compañía, el día que sea irresponsable lo haré.
Y hace 6 meses tuve que tomar la decisión de que plataforma de virtualización utilizar, probé XEN y VMware, y pese a la diferencia de u$s no había demasiado para dudar. Al día de hoy 80 servidores han sido migrados a VMware (cluster de 2 servidores x3650), al día de hoy ningún problema, a ello yo llamo un producto maduro.
Slds
Publicar un comentario