Posts anteriores:
Hola
Hasta el momento hemos tratado diferentes aspectos de los requisitos e instalación de Hyper-V. Con lo que tenemos hasta ahora ya podemos empezar a crear máquinas virtuales y a moverlas entre los hosts del cluster siempre que contemos con las consolas correspondientes instaladas en algún servidor Windows server 2008 R2 o un Windows 7 con las Remote Server Administration Tools (RSAT). En este post vamos a ver como realizar una instalación y configuración inicial de System Center Virtual Machine Manager 2008 R2. Por no llenarlo de pantallazos, he decidido simplemente publicar los mas relevantes. En este PDF he incluido todos.
La instalación de Virtual Machine Manager es bastante sencilla y rápida, y simplemente nos pedirá tomar una decisión por cada uno de los componentes de su arquitectura. Lo mas sencillo es instalar todo sobre el mismo servidor, pero pueden también instalarse por separado den diferentes equipos. Un servidor para la base de datos, otro para el servicio, otro para el portal, la consola de gestión en los clientes y file servers para la biblioteca. Los agentes son necesarios en los host que se gestionarán, en el servidor que alberga el servicio, y en los servidores que conformen la biblioteca:
Llegados a este punto ya tenemos una instalación funcional de System Center Virtual Machine Manager:
Para poder empezar a hacer cosas con el, será necesario:
Mas información (http://blogs.technet.com/b/davidcervigon/p/systemcenter.aspx)
Saludos
David Cervigón
Se acaba de publicar un whitepaper en el que se detallan diferentes aspectos del dimensionamiento de un host de Hyper-V R2 dedicado a un escenario de VDI, es decir, a correr máquinas virtuales con un sistema operativo de escritorio al que se conectarán los usuarios, bien directamente, bien a través de un bróker de conexiones:
Aparece titulado como Remote Desktop Virtualization Host porque ese es el nombre del role de los Remote Desktop Services que se encarga de poner en contacto los servicios de gestión de Hyper-V con el Remote Desktop Connection broker, y porque ha sido el equipo responsable de los Remote desktop Services quien ha realizado el estudio. De hecho lo consideran una continuación del este otro Whitepaper que ya comentamos cuando apareció hace unas semanas:
Obviamente los resultados son aplicables también en el caso de que se esté usando otro bróker, como XenDesktop o vWorkspace.
La metodología utilizada en ambos estudios es muy similar. Se ejecutan scripts de carga de trabajo sobre las sesiones de usuario. En RDS, un servidor (físico o virtual) soporta la suma de las cargas de todos los usuarios que han iniciado sesión, y en VDI cada VM alberga una única sesión. Al final se trata de comparar cuantos usuarios estamos soportando sobre el servidor físico sin que se produzca una penalización en su experiencia de usuario.
No es el propósito de estos dos whitepapers comparar estas dos técnicas de virtualización del escritorio entre si a nivel de rendimiento. Se estima que RDS escala entre 2 y 5 veces mejor que VDI, cosa que debe tenerse en cuenta, junto con los matices de diferencias en funcionalidad y los costes asociados, a la hora de decidir que tipo de escritorio virtual se entrega a cada tipo de usuario. Ninguna de las dos soluciones es la buena si se presenta como la única solución.
Hacia tiempo que andaba buscando una herramienta gratuita para administrar conexiones de Remote Desktop, y que fuera compatible con las últimas versiones del protocolo. En particular, para mi era muy importante que soportara la conexión a través de un Remote Desktop Gateway, para encapsular la comunicación RDC dentro de HTTPS y pode alcanzar servidores remotos situados detrás de firewalls.
Esta herramienta es una evolución de la inexplicablemente desaparecida Remote Desktop Snap-in de la MMC (tsmmc.msc) que teníamos en Windows Server 2003:
Una de las cosas más interesantes que tiene es la posibilidad de gestionar grupos de conexiones que van heredando la configuración si así se desea. Para todas las conexiones de un grupo puedes configurar credenciales comunes, mi querido servidor de puerta de enlace, como se compartirá la ventana de la sesión, si se permiten o no la redirección de dispositivos locales, etc. Y con la opción de “Connect Group” puedes lanzar las todas las conexiones de ese grupo simultáneamente. Y se ve así:
Se puede establecer el tamaño del cliente en cualquier momento, poner una conexión en pantalla completa, y también hacer un “undock” de una de las conexiones para mostrarla en una ventana diferente de la aplicación principal. Los thumbnails son perfectamente operativos, aunque hay que subirlos de tamaño un poco para que esa funcionalidad sea utilizable. Lo bueno es que dicho tamaño es igualmente configurable por grupo. Todo esto, además de para trabajar, puede resultar de mucha utilidad a la hora de usar un proyector para hacer demos. Permite incluso multimonitor.
Hasta ahora la herramienta de este estilo que mas me había gustado es Remote Desktop Manager de Devolutions, que incluye como valor añadido muchos otros tipos de conexiones útiles como Telnet, SSH, VNC, Hyper-V, Vmware, etc.
Espero que os guste tanto como a mi.
Inspirado por este post de Santos, he descargado la versión de evaluación de Windows Embedded 7 Standard para ver el aspecto que pueden llegar a tener la nueva generación de dispositivos que incluyan Windows 7 embebido.
La prueba más inmediata era instalarlo sobre Windows Virtual PC a partir del ISO que te descargas. Sin necesitar utilizar de entrada ninguna de las herramientas del Toolkit ni el SDK, la instalación esta completamente basada en componentes y bastante personalizable. Vienen una serie de plantillas ya definidas, como se puede ver en la segunda imagen, si bien pueden agregarse o quitarse componentes adicionales, y el propio proceso de instalación se encarga de mantener las dependencias subyacentes:
Este es el resultado de elegir las plantillas “Thin Client” e “Internet Explorer, Windows Media Player, Remote Desktop”. La que llaman “Minimum Configuration” monta una simple línea de comandos en plan “Server Core”
Aprovechando que por la oficina tenemos un HP Compaq t5730, decidimos pasar de tener un Thin Client virtualizado montar uno de verdad. Este Thin Client en particular tiene un disco interno SATA de estado sólido (SDM) de tan solo 1Gb, y 1Gb de RAM. Mientras investigábamos cual era en detalle su configuración hardware, descubrimos que el procesador soportaba virtualización asistida por hardware. y que además es x64. ¿Sería capaz de arrancar Hyper-v server 2008 R2 desde un pendrive?. Nos preparamos un lápiz USB tal y como se explica aquí (es más fácil si se usa la herramienta BootHVSR2FromUSB). Los resultados hablan por si solos:
Después de haber montado un Thin Client virtual, y un Hyper-V sobre un Thin Client decidimos intentar montar algo que realmente resultase de utilidad práctica. Sin embargo, jugando a quitar y poner componentes de Windows Embedded 7 Standard fuimos incapaces de montar algo decente (que tuviera al menos UI y un cliente RDP) y que cupiera en los 936 MB escasos que tiene el disco interno. Dado que ponernos a buscar algún sitio donde nos vendieran un SATA Disk Module de al menos 2Gb a buen precio, decidimos montarnos el Thin Client más pequeño del mundo:
Microsoft Hyper-V server 2008 R2 y Windows Embedded 7 tienen ambos la capacidad de arrancar de un disco USB extraíble. En particular, Windows Embedded implementa un módulo llamado “Bootable USB Stack” (mas información aquí y en el fichero de ayuda que se incluye en el Toolkit) que al incluirlo en la instalación permite seleccionar el pendrive que descansa sobre la manita de 5 años que veis en la foto. Desde luego no es un sistema que bata records de I/O, pero el resultado es el siguiente:
y el dueño de la mano tan contento gracias a este briconsejo, y a haber copiado la carpeta c:\Archivos de Programa\Windows NT\PinBall de un Windows XP a una carpeta del pendrive:
No tengo muy claro si el dueño del Thin Client va a ser capaz o no de restaurar la imagen original del fabricante. Voy a ver si le meto mano al TDT y pruebo la plantilla “Set Top Box”. Uno de los componentes es Media Center….
Estos son los dos documentos básicos
Mis comentarios:
Las ediciones OEM de Windows Server tienen exactamente los mismos derechos de virtualización que las demás. De cara a la activación, este tipo de ediciones muestran en el COA dos claves, la Physical Key para el host, y la Virtual Key para las 1 (standard), 4 (Enterprise) o ilimitadas (Datacenter) instancias virtuales de Windows Server que vayan a correr encima del servidor licenciado.
Sin embargo, algunas de estas ediciones de Windows Server vienen protegidas por el fabricante para evitar su instalación sobre un hardware diferente. Recordemos que toda versión OEM de Windows (cliente o servidor) “nace y muere” con el equipo junto al que se adquieren. Para ello se suele recurrir a un sistema denominado BIOS-Lock, que en tiempo de instalación comprueba la existencia de ciertas cadenas de caracteres introducidas por el fabricante en ciertos sectores de la BIOS. Para poderlas instalar sobre una máquina virtual, debemos simular la existencia de dicha información en la BIOS de la máquina virtual, lo que se logra mediante la propiedad BiosLockString, documentada aquí. La manera de especificarla es mediante la creación de la siguiente clave del registro en la partición padre, en la que debemos escribir una cadena de exactamente 32 caracteres provista por el fabricante:
Información específica del ROK (Reseller Option Kit) de HP:
Por último, dos consideraciones importantes relativas al mundo de los Windows OEM en relación a la virtualización:
Se puede consultar online, y también descargar desde aquí:
http://viewer.zmags.com/publication/54ef6966#/54ef6966/1
Los grupos de producto de Failover Clustering e Hyper-V acaban de ampliar el limite de numero de máquinas virtuales que pueden correr por nodo en un cluster de Hyper-V. Hasta ahora ese límite era de 64 VMs por nodo de cluster, lo que nos daba un máximo de 1024 VMs por cluster (16 nodos x 64 VMs por nodo)
Los nuevos límites son:
ó
La documentación actualizada está aquí:
Aquí tenéis una tabla de referencia rápida para clústeres de diferente número de nodos en los que se asume al menos un nodo pasivo:
Número de nodo en el Clúster
Número máximo de VMs por nodo
Máximo número de VMs en el cluster
2 Nodos (1 activo + 1 pasivo)
384
3 Nodos (2 activos + 1 pasivo)
768
4 Nodos (3 activos + 1 pasivo)
333
1000
5 Nodos (4 activos + 1 pasivo)
250
6 Nodos (5 activos + 1 pasivo)
200
7 Nodos (6 activos + 1 pasivo)
166
8 Nodos (7 activos + 1 pasivo)
142
9 Nodos (8 activos + 1 pasivo)
125
10 Nodos (9 activos + 1 pasivo)
111
11 Nodos (10 activos + 1 pasivo)
100
12 Nodos (11 activos + 1 pasivo)
90
13 Nodos (12 activos + 1 pasivo)
83
14 Nodos (13 activos + 1 pasivo)
76
15 Nodos (14 activos + 1 pasivo)
71
16 Nodos (15 activos + 1 pasivo)
66
Simplemente mencionar que esto afecta a HA, Live Migration y Quick Migration, ya que las tres funcionalidades dependen por debajo de las capacidades de Failover Clustering de la partición padre
http://office.microsoft.com/en-us/web-apps
Una vez activadas (a fecha de hoy se requiere tener Office 2010, pero en un futuro próximo no será así), es más impresionante usarlas desde un equipo que NO tenga Office instalado.
Word Web App:
Excel Web App
PowerPoint Web App
OneNote Web App
A las versiones de evaluación que se publicaron en la web hace unas semanas se unen las finales para todos aquellos que tengáis subscripciones a TechNet/MSDN. También estarán ya disponibles en la web de volumen.
Se acaba de publicar una guía excelente de despliegue de Remote Dektop Services que cubre sus dos principales escenarios de uso, deteniéndose en los detalles específicos de todos y cada uno de los roles que componen este conjunto de servicios (RD Session Host, RD Web, RD Gateway, RD Licensing, RD Virtualization Host y RD Connection Broker)
Imprescindible para todos aquellos que quieran implementar una estrategia de escritorios centralizados en aquellos escenarios donde eso tenga sentido sin caer en el peligroso error del café para todos.