Hola
Una de las preguntas más habituales que surgen cuando se traslada el licenciamiento de VDI a la instalación del software propiamente dicha es la de que medio de instalación y claves utilizar para las máquinas virtuales.
Recordemos que para VDI es obligatorio licenciar el dispositivo de acceso con “VECD for SA” (Clientes Windows con Software Assurance) o Windows VECD (Clientes no cubiertos con SA, ya sean thin o rich clients). Una vez adquirida la licencia, la pregunta es con qué instalamos el sistema operativo de la máquina virtual, y qué clave utilizamos para activarla.
La respuesta es sencilla. Cuando se ha adquirido VECD, puedes acceder a la web de licenciamiento por volumen de Microsoft (https://licensing.microsoft.com) y en ella encontraras algo similar a esto en el apartado de descargas de software (la lista de productos depende de lo que se tenga contratado):
Si seleccionamos el VECD que hayamos contratado (en este ejemplo se trata del asociado a Windows 7) nos podremos descargar un ISO para el idioma que queramos, que como puede observarse corresponde a una imagen de Windows 7 Professional, que será el que utilicemos para realizar la instalación:
Este ISO es de hecho el mismo que seguramente ya se esté utilizando en el caso de que lo hayamos adquirido. La clave de producto necesaria para activarlo se encuentra en el apartado correspondiente de esta Web. Obviamente no voy a poner el pantallazo :-).
Una de las situaciones que más frecuentemente nos encontramos sin querer por ahí es versiones OEM instaladas en las máquinas virtuales. Recordemos que esto viola dos veces la legalidad. La primera porque una versión OEM no puede ser adquirida al margen de un equipo nuevo, y no puede ser desvinculada del mismo, y la segunda porque esto suele indicar que no se ha licenciado correctamente el dispositivo de acceso. Y todo esto, independientemente del hypervisor utilizado.
Por último mencionar que a partir del 1 de Julio, VECD se denominará Virtual Desktop Access (VCA), y pasa a ser un beneficio más de Software Assurance, con lo que no conllevará coste adicional. Para rich/thin clientes no cubiertos con SA, el esquema de licenciamiento será igual que hasta ahora, con una subscripción anual por dispositivo (los famosos $110 anuales)
Saludos
David Cervigón
Lo cierto es que hay pocos estudios independientes con comparativas entre los tres principales hypervisores del mercado. Recordemos que hay dos de ellos que no están interesados en competir entre si (Hyper-V y XenServer) y que el tercero en discordia tiene esto incluido en su EULA:
You may use the Software to conduct internal performance testing and benchmarking studies, the results of which you (and not unauthorized third parties) may publish or publicly disseminate; provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study. Please contact VMware at benchmark@vmware.com to request such review.
Pensándolo bien, si en Microsoft hubiésemos incluido algo similar a esto en el de Windows, en una gran parte de Internet no habría mucho de lo que hablar. Y a lo mejor así nunca hubiésemos tenido que leer que en Vista no corrían las aplicaciones P2P, o que no se podían copiar CDs y DVDs por culpa del DRM. Así es que con tal “disclaimer”, tan legítimo como purista, cualquier cosa que leamos va a tener un crédito muy limitado.
He aquí algunas comparativas:
NOTA: Hemos estado trabajando justamente en este escenario durante este año con un cliente al que todos conocéis. Terminal Servers 2008 x86 instalados “en físico” sobre hardware x64 con procesadores que soportan SLAT. Si sobre los servidores ponemos Hyper-V R2 y sobre ellos montamos instancias virtuales la misma imagen de Sistema Operativo que teníamos en físico. Ajustando el número de maquinas virtuales por host, jugando el ratio de procesadores virtuales/core y la memoria, se ha multiplicado el número de sesiones concurrentes que soporta cada hosts en un factor cercano a x3. Se ha ganado flexibilidad con Live Migration, y ya que estábamos, todas las aplicaciones corren a su vez virtualizadas con App-v. Y de paso, algunas cañas también han caído…
Tenéis más estudios de rendimiento de Hyper-V recogidos en este post de mis compañeros del grupo de soporte a plataformas:
¿Que significa todo esto?
Pues si has entendido bien el post anterior, poca cosa realmente. Simplemente, es falso afirmar taxativamente VMware tenga a fecha de hoy mejor rendimiento que Hyper-V. De igual manera, también es falso lo contrario. Sin embargo, lo que si es cierto es que las necesidades de cada organización son diferentes, y la posible combinatoria de todos los factores que influyen en el rendimiento de una plataforma de virtualización muy rica. Y que hay otras muchas cosas que incluir dentro de la ecuación a la hora de elegir una solución de virtualización.
Hoy se han anunciado (y también aquí) las versiones RTM de estos dos productos de la familia de System Center. Las versiones de evaluación correspondientes se pueden descargar desde estos enlaces:
Este fin de semana estuve instalando la Release Candidate de SCE, y es francamente curiosa de ver la integración que han hecho de Virtual Machine Manager, Operations Manager, WSUS y SCUP en una única consola. Tenemos gestión de equipos físicos, virtuales, hosts de virtualización, librería, conversiones P2V, PRO Tips, despliegue de actualizaciones y software, inventario, reportes y un sinfín de detalles más, siempre a dos o tres clics de distancia. Capturé todos los pantallazos de instalación y algunos aspectos de la consola, pero quiero hacerme primero con los binarios sin fecha de caducidad y comprobar que nada haya cambiado antes de colgarlos aquí, y lo mismo para Data Protection Manager.
Para los que quieran ir leyendo algo al respecto este es el enlace al apartado dedicado a System Center Essentials 2010 en la TechNet Library.
En los últimos meses, una de las cuestiones que empieza a aparecer con mas frecuencia encima de la mesa es la de las comparativas que las diferentes plataformas de virtualización ofrecen en términos de rendimiento. Sin que todavía hayan terminado de despejarse las discusiones sobre las ventajas que las iguales, similares o diferentes funcionalidades aportan a las soluciones de virtualización de los diferentes fabricantes, parece que se abre este nuevo frente, muy propio por otro lado de las tecnologías que han alcanzado ya un punto importante de madurez en lo que al interés y adopción del mercado se refiere, y por supuesto, de la presencia en el mismo de diferentes competidores.
Durante los años que llevo metido en este mundillo, gran parte de ellos dedicado sobre todo a los sistemas operativos Windows y servidores que corren por encima, este tipo de comparaciones han sido, y seguirán siendo, argumentos principales en las batallas entre los diferentes competidores y de sus defensores y detractores. Me consta que ya era así antes, y supongo que así seguirá siendo en el futuro. Sin embargo, la virtualización, redescubierta en los últimos años gracias sobre todo a los avances realizados sobre los procesadores ia32 por parte de Intel y AMD, y al margen de que todos estemos de acuerdo en los importantes beneficios que supone, esta potenciando que volvamos a cometer muchas veces el viejo error de confundir el fin con los medios, olvidándonos de que desde los tiempos remotos la tecnología se ha venido usando para resolver problemas concretos.Por muy entretenido que sea comparar acaloradamente arquitecturas, funcionalidades y datos históricos de las diferentes tecnologías, nos olvidamos de que a la gente que se dedica a diseñar, implementar y operar soluciones de IT no les pagan por montar tal o cual sistema operativo, o unos u otros productos por encima, o hacerlo en físico o en virtual. Les suelen pagar porque, monten lo que monten y como o monten, aquello se ajuste bien a lo que se les demanda en cada momento. Y si se pierde este punto de vista, gran parte de las preguntas si no todas tienen una única respuesta. Depende
Se ven a menudo situaciones en las que todo parece reducirse a botes de RAM, CPU y Disco dando saltos de hypervisor en hypervisor. Pero la virtualización no se trata de arrancar máquinas virtuales sobre un hypervisor y verlas, verdes, en estado “running” dentro de una u otra consola de gestión. Supongo que la gente no se pone delante de un rack recién conectado a la luz y sembrado de servidores recién ensamblados y se relaja y disfruta viendo parpadear las luces verdes con el sentimiento de haber terminado un trabajo bien hecho. Todo esto parece ser una obviedad, pero lo cierto es que casi a diario uno se encuentra con situaciones en las que, en base uno u otro conjunto de funcionalidades, se asevera que tal o cual solución es capaz de consolidar una u otra cantidad de maquinas virtuales de unas características determinadas. Y lo cierto es que eso puede ser verdad, o no. Depende. Porque de lo que de verdad si que se trata es de saber si un cierto conjunto de máquinas virtuales, cada una de ellas haciendo su trabajo, pueden ser consolidadas sobre que cantidad de hardware usando tal o cual tecnología de virtualización y si vamos a sacar el rendimiento que se espera de todas y cada una de ellas.
Rendimiento: Proporción entre el producto o el resultado obtenido y los medios utilizados Performance: Efficiency: effective operation as measured by a comparison of production with cost (as in energy, time, and money)
Rendimiento: Proporción entre el producto o el resultado obtenido y los medios utilizados
Performance: Efficiency: effective operation as measured by a comparison of production with cost (as in energy, time, and money)
Siempre le he escuchado decir a mi amigo Alberto Camina que el análisis del rendimiento es ciencia, pero que su optimización es arte. A la vista de las definiciones anteriores no puedo estar más de acuerdo, sobre todo en la acepción inglesa que responde sin duda al carácter mucho más práctico que tienen los anglosajones si se les compara con los latinos. Datos como el número de máquinas virtuales por servidor, procesador o core, medidas del consumo de recursos de la propia pila de virtualización, o sumas y restas de memoria RAM son completamente inútiles como parámetro de entrada si lo que aspiramos es a montar una solución virtualizada. Cuando de verdad estos datos valen para algo es cuando se obtienen a partir de una solución que esta dando el servicio para el cual ha sido diseñada, y con un rendimiento que esta dentro de los márgenes acordados. Ese es el momento de sacar conclusiones, que nos permitirán extrapolarlas a escenarios que sean similares.
Benchmark: a : a point of reference from which measurements may be made b : something that serves as a standard by which others may be measured or judged c : a standardized problem or test that serves as a basis for evaluation or comparison (as of computer system performance)
Para resolver en parte del problema anterior y podernos hacer una idea antes de tener que tomar una decisión acerca del camino a seguir, se suele recurrir a estudios de benchmarking. Dichos estudios se componen de una metodología, que detalla qué es lo que se va a probar y como, y una serie de herramientas diseñadas para medir diferentes aspectos del rendimiento de un sistema/aplicación y que se eligen en función de para qué se supone que vaya a servir en el futuro lo que se pretende medir, y de unas conclusiones que en muchas ocasiones se ciñen exclusivamente a presentar los datos obtenidos, y en otras se ponen además dentro del contexto de los costes que suponen en términos de tiempo y dinero. La idea es que si esta bien hecho, el estudio pueda servir como referencia a la hora de estudiar casos más particulares, y por supuesto, de nada vale si los resultados no son 100% repetibles por un tercero si se sigue paso a paso la metodología utilizada.
Piloto: en aposición, indica que la cosa designada por el nombre que le precede funciona como modelo o con carácter experimental
Sin embargo, como todos sabemos, el mundo real supera siempre a la ficción. Y mucho más a menudo de lo que sería deseable, resulta que los puntos de partida a partir de los cuales se ha realizado el benchmark no se pueden aplicar exactamente a nuestra situación, y de hecho no existe una herramienta que sea capaz de simular la carga de trabajo que necesitamos para simular nuestro entorno. Cuando se esta pensando en la estrategia que se va a seguir a la hora de ofrecer un determinado servicio es muy importante conocer de antemano el patrón de la demanda que éste va a tener. No es el mismo el uso que hacen de un equipo cliente, una base de datos, un sistema de mensajería o cualquier cosa que se os ocurra un banco que una factoría. Incluso con las mismas versiones de productos y modelos del diferente hardware, la manera en la que se usan y los patrones pueden ser totalmente diferentes. Y eso es así incluso para diferentes tipos de usuarios (clientes de esos servicios) dentro de una misma organización. Y gracias a esto (o a pesar de :-)), desarrolladores y personal de IT cobran sus sueldos a final de mes. Esta es la razón por la que antes de decidirse por tecnologías, productos, soluciones o como lo queramos llamar, se suele optar por montar pilotos a partir de los cuales que seamos capaces de comprobar si lo que hemos visto en los diferentes bechmarks se cumple en nuestro caso, o directamente evaluar por nosotros mismos la configuración más conveniente.
Para complicar aun más la situación, los datos obtenidos de estos ejercicios de benchmarking y pilotaje pueden ser incluso todavía insuficientes a la hora de ponerse a diseñar, implementar y operar un conjunto de servicios virtualizados, o abordar un proyecto de consolidación mediante virtualización de los ya existentes. Cuando hablamos de Capacity Planning, es decir, de prever cuantos recursos vamos a necesitar para ofrecer el nivel de servicio que se nos demanda, la exactitud de los datos que podamos tener sobre la mesa puede ser determinante. Es muy frecuente encontrarse ante proyectos de consolidación en los que se solicita una infraestructura para virtualizar una serie de equipos de los que se proporciona características de CPU, RAM, Red y Almacenamiento, así como sistema operativo y role. ¿Que ha de suponerse en estos casos?. ¿Porcentajes de uso mínimos, máximos, utilización media…?. Cualquier suposición será potencialmente contraproducente y arriesgada si no se es capaz de tener, al menos, una grafica de utilización de los recursos obtenida durante un periodo de tiempo significativo de cada una de las cargas de trabajo, de manera que podamos saber por ejemplo cuales se suman en un momento dado o cuantas se compensan. Porque por mucha flexibilidad e inteligencia adicional que nos ofrezca la virtualización, si la demanda sobrepasa a la capacidad, el servicio se ve irremediablemente impactado.
Espero que llegados a este punto haya sido capaz de hacer entender que no se trata de qué hypervisor consume más o menos CPU, Memoria, Disco o Red, sino de quien es más eficiente logrando que lo que corre por encima tenga el mejor rendimiento mientras esta haciendo el trabajo que le toca, que no es otro que dar servicio. Y que si bien los cuatro parámetros básicos anteriores son sin duda importantes, el termino “Eficiencia” abarca más cosas y reducir toda esta problemática a la mera comparación de características no suele llevar a resultados que se puedan utilizar en la práctica.
Obviamente, a los que como yo trabajan para una de las partes implicadas no les queda mas remedio que arrimar el ascua a su sardina. En virtud de todo lo explicado anteriormente, lo que viene a continuación no debería ser considerado a la hora de extraer conclusiones concretas, pero si para plantearse revisar algunos mitos y leyendas, y ponerse manos a la obra a sacar nuestras propias conclusiones. En cualquier caso aquí va.
Cuando hablamos de hypervisores, estamos hablando de paravirtualización en la gran mayoría de los casos. Es decir, el sistema operativo invitado debe ser modificado para que pueda utilizar las hypercalls que expone un hypervisor determinado, y funcionar de una manera mucho más eficiente a la hora de interactuar con los recursos. Sin estos componentes instalados en sistema operativo que corre en la máquina virtual, todo lo que podemos hacer es emular un entorno de hardware determinado de modo que el sistema operativo invitado funciona totalmente ignorante de su suerte y sin aprovecharse de gran parte de las ventajas que le ofrece la pila de virtualización. Tanto cuando hablamos de funcionalidades como de rendimiento, no hay que considerar únicamente al hypervisor sino también con esa pieza software que “aligera” el kernel del invitado. Y ambos son igual de importantes, ya que no tienen sentido por separado.
Bajo mi punto de vista, el que el ciclo de desarrollo de un hypervisor vaya parejo y ligado al del kernel del sistema operativo que se va a virtualizar, tanto en su variante cliente como servidora, es un hecho diferencial y que tiene y tendrá cada vez más impacto, no solo en rendimiento, sino en otros muchos factores como la inclusión del conocimiento de las aplicaciones que corren encima dentro de la propia tecnología. Eso sucede en el caso de Hyper-V y las versiones de Windows a partir de Windows Vista y Windows Server 2008, pero también en el caso de Linux, tanto en los casos de las distros comerciales como las las de libre distribución. Y todo esto sin perder de vista que al final gran parte del trabajo recae sobre el procesador, que absorbe cada vez más y más funcionalidades relacionadas con la virtualización.
Por eso ahora el discurso se desplaza a las nubes y a su gestión.
Se ha publicado recientemente una nueva “IPD Guide” relativa a las cuestiones a tener en cuenta a la hora de diseñar un datacenter virtualizado con Hyper-V y gestionado con Sytem Center:
He estado echando un vistazo por encima al contenido, y se parece a los temas que estamos tratando por aquí en esta serie de posts, pero de una manera mas amplia y general. Se complementa con otras guías específicas de los productos de System Center, que son las que siguen:
El miércoles 21 de Abril, invitado por mis amigos Estela y Javier de NetApp, participaré en esta Webcast de una hora de duración para hablar de cómo se complementan Hyper-V y sus soluciones de almacenamiento cuando hablamos de escenarios de virtualización, y también de cómo se están utilizando en el mundo real. Podéis registraros de manera gratuita en este enlace.
Ya de vuelta de Seattle y de unas cortas vacaciones por el Cantábrico os resumo las noticias y novedades que se han ido produciendo durante la segunda quincena de Marzo. Mucha ha sido la información recibida durante la semana que duró nuestro TechReady 10, pero la insistencia por parte de los ponentes sobre la naturaleza confidencial de la misma sugiere no ponerse a escribir durante el tiempo del evento, ya que entonces la posibilidad de contar más allá de lo debido es muy plausible.
Dynamic Memory y RemoteFX estarán presentes en el SP1 de Windows Server 2008 R2. Este SP coincidirá también con el de Windows 7, y no hay todavía fechas anunciadas para su disponibilidad.
Disponibilidad de la Beta de los Hyper-V Linux Integration Services 2.1 con el soporte de hasta cuatro procesadores virtuales, sincronización de tiempo con la partición padre y servicio de shutdown integrado. Puede descargarse de Microsoft Connect en este enlace. Recordemos que las distribuciones soportadas oficialmente son SLES 10 SP3 / 11 y RHEL 5.2 / 5.3 / 5.4. Al igual que ya se hizo con la versión 2.0, el código encargado con la comunicación directa con Hyper-V se ha licenciado bajo licencias BSC y GPLv2 y enviado para su inclusión en el Kernel de Linux, con el compromiso de contribuir directamente a su soporte y mantenimiento. De hecho, las versiones del Kernel de Linux 2.6.32 o posteriores ya integran el soporte para Hyper-V, o dicho de otra forma, cualquier distribución que use dicho kernel esta “paravirtualizada” para correr sobre Hyper-V. Mas información aquí:
Windows Virtual PC y XP Mode ya no requieren obligatoriamente el soporte de Virtualización Asistida por Hardware (HAV, es decir Intel-VT o AMD-V) por parte del procesador. Esto significa que a partir de este momento pueden ejecutarse con Windows Virtual PC máquinas virtuales en cualquier equipo que sea capaz de correr Windows 7, independientemente del procesador. Y por tanto también puede utilizarse XP Mode sobre estos equipos. Para ello hay que instalar una actualización, que está disponible en estos enlaces según el equipo corra una versión x86 o x64 de Windows 7:
Toda la información al respecto esta en este artículo de la Knowledge Base: http://support.microsoft.com/kb/977206. Es importante mencionar que hay que actualizar los componentes de integración de las máquinas virtuales tras aplicar el fix (en particular de la del XP Mode que descargamos de Internet) y que Microsoft solo soporta oficialmente el uso de Windows Virtual PC sin HAV para correr VMs con Windows XP, lo que no quiere decir que las demás no funcionen. Ben Amstrong lo explica mejor en este y en este post.
Cambios en el licenciamiento de VDI. A partir del 1 de Julio de 2010: VECD (Virtual Enterprise Centalized Desktop) pasa a llamarse VDA (Virtual Desktop Access) y básicamente pasa a ser un beneficio más de Software Assurance, como es por ejemplo hoy en día MDOP, con su APP-V y MD-V al frente. Para dispositivos sin SA se mantiene el coste anual del actual Windows VECD.
Ofertas y promociones para VDI. Con esto de la Memoria Dinámica, el RemoteFX, el “redescubrimiento” de los Remote Desktop Services (con y sin XenApp) como una excelente opción para virtualizar escritorios, y los brokers de Windows Server 2008 R2 y XenDesktop, más de uno puede estarse arrepintiendo muy seriamente de alguna que otra “inversión” realizada recientemente. Para todos ellos hay una promoción conjunta Citrix-Microsoft con un nombre muy llamativo: “Rescue from VMware VDI”. Y para los que quieran invertir en VDI, allí donde realmente sea de verdadera utilidad hay otra llamada “Get started with VDI for only $7K”. Tenéis más información en http://www.citrixandmicrosoft.com.
Adiós a la arquitectura Itanium (ia64). Sin dudar de las bondades de esta arquitectura, esta claro que ha sucumbido ante la rápida evolución de las arquitecturas x64. Tanto Intel como AMD están anunciando nuevas familias de procesadores con más núcleos de ejecución y por otro lado los fabricantes de hardware aumentan el numero de “vías” o “sockets” de sus servidores. Windows Server 2008 R2, SQL 2008 R2 y Visual Studio 2010 serán los últimos productos de Microsoft disponibles para dicha plataforma, aunque su soporte se extenderá hasta 2018.
Muchas de estas cosas serán sin duda temas sobre los que irán apareciendo información en los próximos meses y de las que nos ocuparemos por aquí. La pregunta que todos nos hacemos es seguramente el ¿cuando?. Como decía anteriormente, no hay ninguna fecha anunciada ni externa ni internamente para el SP1 de Windows 7 / 2008 R2 ni para los Linux ICs 2.1. Mi apuesta personal es que todo esto verá la luz cuando apriete el calor…