elstir

Posts anteriores:

• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Objetivo y consideraciones generales
• Montando Laboratorios, Pruebas de Concepto y Pilotos de Virtualización: Requerimientos: El Directorio Activo
• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Requerimientos: Red
• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Requerimientos: Almacenamiento
• Montando Laboratorios, Pruebas de concepto y Pilotos de Virtualización: Instalación de los hosts de Hyper-V y el cluster

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:

          

• Opción VMM Server.
  • La base de datos. VMM se apoya en una base de datos SQL. Durante el proceso de instalación nos solicitará elegir una instancia ya existente en la red, o podemos también usar el SQL Express  2005 SP3 que viene incluido en el producto. En este último caso, la instalación y configuración de SQL y la creación de la base de datos se realizan de manera completamente desatendida.

•  
  • La librería. Este componente de VMM es el encargado de mantener el conjunto de “ingredientes” que necesitaremos para desplegar nuevas máquinas virtuales, y constituye un almacén para plantillas y VMs que no es necesario que estén desplegadas en los hosts. ISOs, VHDs, perfiles de hardware, perfiles de software, scripts, etc. se alojan en file shares disponibles en la red, a los que se despliega el agente de Virtual Machine Manager. Es obligatorio que exista al menos una carpeta compartida en la máquina en la que se instala el servicio, por lo que tendremos que elegir donde reside su path por defecto, o proporcionar una carpeta compartida local ya existente. Si no se van a usar otro servidores para la biblioteca, y si VMM se esta montando virtualizado, hay que tener en cuenta que esa carpeta crecerá según vayamos definiendo plantillas, VHDs y máquinas virtuales. En estos casos es interesante asignar por pass-thought o por iSCSI una LUN del almacenamiento, para evitar que el VHD de la propia VM de Virtual Machine Manager crezca indiscriminadamente.

•  
  • El servicio de VMM. El motor principal de Virtual Machine Manager es este servicio, con su capa de PowerShell por encima. Aquí tenemos que decidir cuales son los puertos que se utilizarán (por defecto el 8100, el 80 y el 443) y especificar si correrá con la cuenta LocalSystem (defecto) o con una cuenta de usuario del directorio activo, que tendremos que hacer administradora local del equipo. Los criterios para elegir entre una u otra opción están listados en estos enlaces, pero será más fácil la integración con SCOM, y, sobre todo, habilitar la posibilidad de compartir ISOs remotamente (How to Enable Shared ISO Images for Hyper-V Virtual Machines in VMM) si se utiliza una cuenta del directorio activo.
    • When should I consider running my VMM Service by using a domain account?
    • Hardening the VMM Server

• Opción VMM Administrator Console: La instalación del servicio no incluye la consola gráfica de administración. Deberá instalarse separadamente sobre el servidor, si así se desea, y sobre los equipos cliente desde los cuales se quiera administrar Virtual Machine Manager. Lo único que nos pregunta la instalación es el puerto que se utilizará para conectarse con el servicio, que será el que hayamos especificado arriba. Al lanzar la consola también puede cambiarse, ya que se usa el clásico formato server:puerto:

• Opción VMM Self Service Portal: El Portal de Autoservicio se instala sobre un servidor que tenga instalado un IIS con los componentes que se citan como requisitos en el pantallazo de abajo. Tendremos que indicar cual es el servidor donde esta corriendo el servicio de VMM y su puerto, y especificar las opciones del servidor Web. Si, como es lo más frecuente, se encuentra con un site ya definido en el puerto 80, dará un error y tenemos tres opciones para salir del paso:
  • Usar otro puerto
  • Usar host headers, para lo que habrá que definir el nombre elegido como alias en el DNS
  • Si no se va a utilizar ese servidor Web para otros menesteres, simplemente borramos o desactivamos el Default Web Site

    

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:

• Desplegar los agentes a los hosts con Hyper-V (http://blogs.technet.com/b/davidcervigon/archive/2008/11/21/instalaci-n-de-un-servidor-de-gesti-n-y-monitorizaci-n-de-entornos-f-sicos-y-virtuales-ii.aspx)
• Conectar con un VMware Virtual Center, si lo hubiera
• Definir los perfiles de hardware que tendrán nuestras máquinas virtuales
• Definir los perfiles de sistema operativo (esto representa ficheros de respuesta desatendidos de sysprep)
• Definir plantillas
• Definir Administradores delegados
• Definir Usuarios de Autoservicio
• Etc.etc.

Mas información (http://blogs.technet.com/b/davidcervigon/p/systemcenter.aspx)

• TechCenter de System Center Virtual Machine Manager 2008 and Virtual Machine Manager 2008 R2

Saludos

David Cervigón

Hola

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:

• RD Virtualization Host Capacity Planning in Windows Server 2008 R2

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:

• Remote Desktop Session Host Capacity Planning in Windows Server R2

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.

Saludos

David Cervigón

Hola

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:

• Remote Desktop Connection Manager 2.2 (RDCMan)

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.

Saludos

David Cervigón

Hola

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….

Saludos

David Cervigón

Hola

Estos son los dos documentos básicos

• Teaming HP
  • Using HP ProLiant Network Teaming Software with Microsoft® Windows® Server 2008 Hyper-V or with Microsoft® Windows® Server 2008 R2 Hyper-V: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01663264/c01663264.pdf

• Virtual Connect
  • HP Virtual Connect Ethernet Cookbook: Single and Multi Enclosure Domain (Stacked) Scenarios: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01990371/c01990371.pdf

Mis comentarios:

• Activa siempre el role de Hyper-V antes de instalar el software de Teaming (NCU). Si este consejo llega tarde, simplemente renombra cpqteam.dll (http://support.microsoft.com/kb/950792)
• En Server Core, simplemente ejecuta HPTeam.cpl o CPQTeam.cpl (versiones antiguas) para configurar el Teaming cómodamente mediante interfaz gráfica.
• A medida que se genera el Team y se van agregando VLANs, empiezan a proliferar NICs en el sistema. Es mas que recomendable ir renombrándolas para tener control en cada momento que es cada cosa (puertos físicos que forman el Team, NICs asociadas a cada VLAN y que conforman virtual switches, NICs virtuales que se generan en Hyper-V para la partición padre y conectadas a los switches virtuales, etc.)
• Existe una manera mucho mas sencilla de hacer las cosas. Que sea solamente el Virtual Switch de Hyper-V quien haga el VLAN Tagging, para lo cual ni en el Team ni en Virtual Connect deberemos definir estas opciones (Para poder hacer eso, el dominio de Virtual Connect debe estar en modo “VLAN Tunneling”)
• El Proliant Support Pack, SmartStart, CD de Firmware, etc. son buenos compañeros de viaje. El comportamiento de todo esto puede ser muy dependiente de versiones de firmware, drivers y software

Saludos

Hola

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.

• Licenciamiento en entornos virtualizados: ¿Y que Clave de Producto le pongo al Windows de la Máquina Virtual?

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:

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\BiosLockString (REG_SZ)

Información específica del ROK (Reseller Option Kit) de HP:

• http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01403345/c01403345.pdf (pag. 20)

Por último, dos consideraciones importantes relativas al mundo de los Windows OEM en relación a la virtualización:

• Es ilegal instalar cualquier edición OEM de Windows Server o Client sobre un hypervisor, salvo en el caso que estamos tratando en este post. Solo es legal instalar una versión OEM de Windows en el mismo hardware con la que dicho producto fue adquirido. Es frecuente encontrarse con escenarios de VDI donde el SO de las máquinas virtuales es in Windows XP/Vista/7 OEM (ver Instalando VECD)
• La consolidación de servidores OEM mediante P2V hace que dicha licencia OEM se pierda, ya que en ningún caso puede asignarse al servidor que albergará la VM. Recordemos que las licencias no se asignan nunca a las máquinas virtuales, sino al host sobre el que corren (Windows Server) o al dispositivo desde el que se acceden (Windows Client). En este caso, el host destino debe tener licencias “sobrantes”, consecuencia de haber sido “sobrelicenciado” con una o varias licencias de Enterprise, o todos sus procesadores con Datacenter 

Saludos

David Cervigón

Hola

Se puede consultar online, y también descargar desde aquí:

http://viewer.zmags.com/publication/54ef6966#/54ef6966/1

Saludos

David Cervigón

Hola

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:

• 384 VMs por nodo

ó

• 1000 VMs por cluster

La documentación actualizada está aquí:

• http://technet.microsoft.com/en-us/library/ee405267(WS.10).aspx

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

384

3 Nodos (2 activos + 1 pasivo)

384

768

4 Nodos (3 activos + 1 pasivo)

333

1000

5 Nodos (4 activos + 1 pasivo)

250

1000

6 Nodos (5 activos + 1 pasivo)

200

1000

7 Nodos (6 activos + 1 pasivo)

166

1000

8 Nodos (7 activos + 1 pasivo)

142

1000

9 Nodos (8 activos + 1 pasivo)

125

1000

10 Nodos (9 activos + 1 pasivo)

111

1000

11 Nodos (10 activos + 1 pasivo)

100

1000

12 Nodos (11 activos + 1 pasivo)

90

1000

13 Nodos (12 activos + 1 pasivo)

83

1000

14 Nodos (13 activos + 1 pasivo)

76

1000

15 Nodos (14 activos + 1 pasivo)

71

1000

16 Nodos (15 activos + 1 pasivo)

66

1000

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

Saludos

David Cervigón

Hola

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

Saludos

David Cervigón

Hola

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.

Saludos

David Cervigón

Hola

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)

• Escritorios completos y/o aplicaciones remotas basados en sesión (los Terminal Services de toda la vida)
• Escritorios VDI

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.

• Remote Desktop Services Deployment Guide

Saludos

David Cervigón

Hola

Han publicado un completo poster con un buen compendio de detalles de la arquitectura y funcionalidades de Hyper-V R2, y que se une a los Windows Server 2008 R2 Feature Components Poster y Windows Server 2008 Component Posters

Lo podéis descargar de aquí.

Saludos

David Cervigón

Hola

Como podréis observar, nos han migrado la plataforma de blogs de TechNet. Se han perdido algunas personalizaciones, a cambio de, por lo poco que he estado viendo, más flexibilidad a la hora de configurar funcionalidades y apariencia.

Lamentablemente todo esto llega en una temporada especialmente mala para encontrar huecos para escribir y personalizar.

Si alguien tiene ideas (frames a la izquierda a la derecha, a los dos lados, contenido, etc.), serán bienvenidas

Saludos

David Cervigón

Hola

Es frecuente encontrarse con el debate de la conveniencia o no de instalar un antivirus en la partición padre. Es muy conveniente evaluar cuidadosamente este punto, ya que un antivirus mal configurado puede hacer estragos en la infraestructura virtualizada, no solamente en términos de rendimiento, sino también de estabilidad. En particular, en el apartado Planning for Hyper-V Security de la TechNet Library puede leerse lo siguiente al respecto:

If you run programs in the management operating system, you should run your antivirus solution there and add the following to the antivirus exclusions:

• Virtual machine configuration files directory. By default, it is C:\ProgramData\Microsoft\Windows\Hyper-V.
• Virtual machine virtual hard disk files directory. By default, it is C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.
• Snapshot files directory. By default, it is %systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots.
• Vmms.exe
• Vmwp.exe

If you need to use the full version of Windows Server 2008 and run applications in the management operating system, then you should run an antivirus program there.

Como puede observarse, el párrafo es bastante ambiguo. En una partición padre “Full”, además de exponer más binarios susceptibles de exponer una hipotética vulnerabilidad, es muy fuerte la tentación de instalar y utilizar en ella aplicaciones. En Server Core los anterior se minimiza, pero no se evita del todo si no se fortifica el host mediante otras técnicas.

Por otro lado, instalar un antivirus sin configurar adecuadamente las exclusiones también conlleva sus riesgos. En http://support.microsoft.com/kb/961804 se habla de los problemas más frecuentes causados por una mala configuración del antivirus, y también se recomienda la configuración de estas exclusiones:

• Default virtual machine configuration directory (C:\ProgramData\Microsoft\Windows\Hyper-V)
• Custom virtual machine configuration directories
• Default virtual hard disk drive directory (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)
• Custom virtual hard disk drive directories
• Snapshot directories
• Vmms.exe (Note: May need to be configured as process exclusions within the antivirus software)
• Vmwp.exe (Note: May need to be configured as process exclusions within the antivirus software)

Por tanto tenemos que gestionar adecuadamente uno de estos dos riesgos:

1. No usar Antivirus en la partición padre
2. Enfrentarnos a los problemas derivados de usar un antivirus mal configurado.

Generalmente, todos los antivirus admiten exclusiones por proceso, path y extensión de ficheros. Las tres son importantes. Por ejemplo. Un cluster que este utilizando GUIDs para referirse a los discos comparticos pone muy complicado el configurar los paths a excluir. También puede ocurrir que a alguien se le ocurra almacenar máquinas virtuales en una nueva carpeta, cuyo nombre se improvisa en el momento. En ese caso, la exclusión de extensiones puede evitarnos algún que otro problema.

He aquí una buena lista de exclusiones para el antivirus de las particiones padre, incluyendo además las recomendables para System Center Virtual Machine Manager y System Center Operations Manager, cuyos agentes es posible que corran en ella:

• Procesos:
  • VMMS.EXE
  • VMWP.EXE
  • VMSWP.EXE
  • VMMAGENT.EXE
  • MONITORINGHOST.EXE
  • VSSVC.EXE
  • VDS.EXE
• Paths:
  • C:\ClusterStorage
  • C:\ProgramData\Microsoft\Windows\Hyper-V
  • C:\Users\Public\Documents\Hyper-V
  • Cualquier otro path en el que puedan llegarse a almacenar máquinas virtuales. Es importante ser consistente con la nomenclatura a lo largo y ancho de toda la “nube interna”
  • C:\ProgramData\Microsoft\Virtual Machine Manager
  • C:\Program Files\System Center Operations Manager 2007\Health Service State\Health Service Store
• Extensiones de ficheros:
  • *.VHD
  • *.VSV
  • *.ISO
  • *.AVHD
  • *.VFD
  • *.XML

Saludos

David Cervigón

Hola

Es frecuente encontrarse con el debate de la conveniencia o no de instalar un antivirus en la partición padre. Es muy conveniente evaluar cuidadosamente este punto, ya que un antivirus mal configurado puede hacer estragos en la infraestructura virtualizada, no solamente en términos de rendimiento, sino también de estabilidad. En particular, en el apartado Planning for Hyper-V Security de la TechNet Library puede leerse lo siguiente al respecto:

If you run programs in the management operating system, you should run your antivirus solution there and add the following to the antivirus exclusions:

• Virtual machine configuration files directory. By default, it is C:\ProgramData\Microsoft\Windows\Hyper-V.
• Virtual machine virtual hard disk files directory. By default, it is C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.
• Snapshot files directory. By default, it is %systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots.
• Vmms.exe
• Vmwp.exe

If you need to use the full version of Windows Server 2008 and run applications in the management operating system, then you should run an antivirus program there.

Como puede observarse, el párrafo es bastante ambiguo. En una partición padre “Full”, además de exponer más binarios susceptibles de exponer una hipotética vulnerabilidad, es muy fuerte la tentación de instalar y utilizar en ella aplicaciones. En Server Core los anterior se minimiza, pero no se evita del todo si no se fortifica el host mediante otras técnicas.

Por otro lado, instalar un antivirus sin configurar adecuadamente las exclusiones también conlleva sus riesgos. En http://support.microsoft.com/kb/961804 se habla de los problemas más frecuentes causados por una mala configuración del antivirus, y también se recomienda la configuración de estas exclusiones:

• Default virtual machine configuration directory (C:\ProgramData\Microsoft\Windows\Hyper-V)
• Custom virtual machine configuration directories
• Default virtual hard disk drive directory (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)
• Custom virtual hard disk drive directories
• Snapshot directories
• Vmms.exe (Note: May need to be configured as process exclusions within the antivirus software)
• Vmwp.exe (Note: May need to be configured as process exclusions within the antivirus software)

Por tanto tenemos que gestionar adecuadamente uno de estos dos riesgos:

1. No usar Antivirus en la partición padre
2. Enfrentarnos a los problemas derivados de usar un antivirus mal configurado.

Generalmente, todos los antivirus admiten exclusiones por proceso, path y extensión de ficheros. Las tres son importantes. Por ejemplo. Un cluster que este utilizando GUIDs para referirse a los discos comparticos pone muy complicado el configurar los paths a excluir. También puede ocurrir que a alguien se le ocurra almacenar máquinas virtuales en una nueva carpeta, cuyo nombre se improvisa en el momento. En ese caso, la exclusión de extensiones puede evitarnos algún que otro problema.

He aquí una buena lista de exclusiones para el antivirus de las particiones padre, incluyendo además las recomendables para System Center Virtual Machine Manager y System Center Operations Manager, cuyos agentes es posible que corran en ella:

• Procesos:
• VMMS.EXE
• VMWP.EXE
• VMSWP.EXE
• VMMAGENT.EXE
• MONITORINGHOST.EXE
• VSSVC.EXE
• VDS.EXE
• Paths:
• C:\ClusterStorage
• C:\ProgramData\Microsoft\Windows\Hyper-V
• C:\Users\Public\Documents\Hyper-V
• Cualquier otro path en el que puedan llegarse a almacenar máquinas virtuales. Es importante ser consistente con la nomenclatura a lo largo y ancho de toda la “nube interna”
• C:\ProgramData\Microsoft\Virtual Machine Manager
• C:\Program Files\System Center Operations Manager 2007\Health Service State\Health Service Store
• Extensiones de ficheros:
• *.VHD
• *.VSV
• *.ISO
• *.AVHD
• *.VFD
• *.XML

Saludos

David Cervigón

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

Hola

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:

• Estudio de Virtual Reality Check - Phase II version 2.0: Comparan las ultimas versiones de los tres Hypervisores (es decir, han pasado por la revisión correspondiente), sobre hardware de ultima generación. La carga de trabajo elegida es Terminal Server, ya que ha sido siempre una de las más complicadas debido a la concurrencia de demanda simultánea de memoria, CPU, e I/O de disco y red producida por la suma de usuarios utilizando el sistema operativo, a lo que hay que sumar un gran número de cambios de contexto usuario/kernel. Describen perfectamente la metodología y además, en línea de lo que exponía en el post anterior, la herramienta que simula la carga de los usuarios concurrentes parece estar muy refinada y ceñirse muy bien a lo que sería un escenario real. Los resultados han sido revisados muy recientemente. Hace unas semanas daban un claro perdedor, pero han incluido un update de ultima hora de vSphere, y además han demostrado dos cosas: Que ASLR tiene un impacto negativo en el rendimiento, y el Transparent Page Sharing no influye ni a mejor ni a peor en el rendimiento de este escenario en particular. El estudio tiene un montón de conclusiones importantes, pero para el tema que nos ocupa, parece que lo que hace unas semanas era una goleada a favor de Hyper-V pasa a ser un empate técnico tras la fase de apelaciones. No obstante, las barritas de las figuras son las mas largas en un caso, y las mas cortas en otro… :-). Podéis descargaros gratuitamente el whitepaper en este enlace, pero requiere registro. De verdad que merece la pena:
• http://www.projectvrc.com/index.php?option=com_docman&task=cat_view&gid=39&Itemid=

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…

• Estudio de Citrix para un entorno de VDI: Este claramente no ha pasado por ningún tipo de revisión legal, ya que habla de Hyper-V, XenServer y “Otro”. De hecho, se basan en el estudio anterior, dicen haber usado el mismo tipo de hardware y la misma herramienta de simulación de carga, pero en lugar de Terminal Servers (o XenApps en su caso) han usado Windows 7 y Windows XP para montar un entorno VDI puro, con XenDesktop y Provisioning Server. Desconozco si se han incluido las modificaciones de ultima hora en vSphere que citan en el caso anterior y en cualquier caso hay una cosa del escenario que dicen haber probado que me no me acaba de cuadrar. Que se haya accedido al almacenamiento en  todos los caso a través de NFS. El título lo dice todo. Goleada de Hyper-V si se usa Windows 7 y de XenServer si XP (la razón es una confirmación del párrafo final del post anterior)
• Best Hypervisor for VDI? Only Two Make the Cut
• Un par de estudios de competencia de Dell con HP, encargados a Principled Consultants, usando herramientas de benchmarking propietarias de Dell, donde Hyper-V y vSphere parece que simplemente pasaban por allí.
• 35 Proliants y 18 Storage Works sobre 5 blades de Dell y 5 Equalogics. Si nos quedamos con los titulares, Hyper-V da un 20% mas de rendimiento y se recupera la inversión un mes antes
• http://www.principledtechnologies.com/clients/reports/Dell/35DL385onto5PEM610-vSphere.pdf
• http://www.principledtechnologies.com/clients/reports/Dell/35DL385onto5PEM610.pdf
• 7 Proliants y una MSA sobre un R710 de Del y una Equalogic. En este caso los titulares no hablan de rendimiento, pero si de que se recupera la inversión 2 meses antes con Hyper-V. Es importante mencionar que aquí se usan las versiones anteriores de Hyper-V y ESX
• http://www.principledtechnologies.com/clients/reports/Dell/Paybackperiod-DellR710vHPDL385ESX.pdf
• http://www.principledtechnologies.com/clients/Reports/Dell/Payback%20period%20-%20Dell%20R710%20v%20HP%20DL385%20Hyper-V.pdf

Tenéis más estudios de rendimiento de Hyper-V recogidos en este post de mis compañeros del grupo de soporte a plataformas:

• http://blogs.technet.com/plataformas/archive/2010/03/23/informacion-de-rendimiento-de-hyper-v.aspx

¿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.

Saludos

David Cervigón

Hola

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:

• System Center Data Protection Manager 2010: http://technet.microsoft.com/en-us/evalcenter/bb727240.aspx
• System Center Essentials 2010: http://www.microsoft.com/systemcenter/en/us/essentials/sce-try-it.aspx

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.

Saludos

David Cervigón

Hola

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)

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.

Saludos

David Cervigón

Hola

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:

• Infrastructure Planning and Design: Dynamic Data 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:

• System Center Configuration Manager 2007
• System Center Data Protection Manager 2007 SP1
• System Center Operations Manager 2007
• System Center Virtual Machine Manager 2008

Saludos

David Cervigón