Archivos del escritorioImplementación de Windows en un mundo virtual

Wes Miller

La informática virtual está en todas partes. Si aún no ha pensado en aprovecharlo, debería considerarlo. La virtualización reduce la dependencia del hardware, creando en esencia un nivel de abstracción propio y dejándole mover uno o más sistemas invitados, como Windows Server o sistemas operativos cliente de Windows, entre otros sistemas host.

La virtualización es, por supuesto, diferente de la emulación en que no imita el procesador del invitado. Representa simplemente los recursos del sistema host de una manera en la que los sistemas invitados pueden tener acceso a los mismos. Como resultado, los sistemas host son genéricos para los invitados. Generalmente, puede mover un invitado virtual de un sistema creado por un OEM a uno creado por otro OEM, el hardware del host normalmente no importa. Sin embargo, hay advertencias. Por ejemplo, si mueve un invitado de hardware con un procesador de un proveedor de CPU, como AMD, a otro, como Intel, podría tener problemas (dependiendo de la tecnología de virtualización que esté usando). Esto es porque la tecnología de cálculo virtual sólo pasa información del host al invitado y viceversa; no emula una CPU específica para el invitado (como lo hace, por ejemplo, Microsoft® Virtual PC cuando se ejecuta en un Macintosh basado en PowerPC heredado).

Sin embargo, la virtualización emula componentes de hardware clave para el invitado. Con más frecuencia esto se limita a las redes, a vídeo (generalmente un dispositivo muy restringido sin una GPU emulada avanzada) y a almacenamiento masivo. Todas estas combinaciones funcionan presentando uno o más tipos de dispositivos de software emulados al invitado. Ahora, si es asiduo de mi columna desde hace tiempo, advertirá que se trata de la misma lista de dispositivos de la que se ocupa Windows® PE. En virtualización, éstos son los mismos tipos de dispositivos que necesita tener con el objeto de que Windows haga realmente cualquier trabajo. De manera adicional, todas las tecnologías de virtualización deben emular un BIOS. Aunque éstas pueden emular también la Interfaz extensible de firmware (EFI), la selección limitada de sistemas operativos basados en EFI que existe hoy en día hace que su uso sea limitado. Toda esta emulación permite que los invitados virtuales puedan arrancar. El BIOS y cada uno de los dispositivos emulan un dispositivo real en el software y presentan ese dispositivo a los invitados. Esto significa que requieren los mismos controladores (no siempre controladores proporcionados por Windows) que requería el dispositivo real. Se trata de un concepto importante a tener en cuenta.

Aunque algunas tecnologías de virtualización también permiten a los dispositivos USB (o USB 2.0) interactuar con éstas, no me extenderé en la explicación de estas tecnologías en este caso. Aparte de estos dispositivos USB que requieren tanto controladores (impresoras, NIC inalámbricas USB, etcétera) como cierta compatibilidad con DirectX® (normalmente no presente en la mayoría de tecnologías de virtualización), no hay mucho que tenga que hacer para que funcionen. Tenga en cuenta que la compatibilidad con los dispositivos USB u otros dispositivos no emulados depende, por supuesto, de la tecnología de virtualización que esté usando. Asegúrese de conocer las limitaciones (los sutiles límites, tal como me gusta llamarlos) del producto de virtualización que está usando antes de intentar obtener nuevos dispositivos con los que trabajar.

Hoy día hay dos proveedores principales de tecnología de virtualización en Windows: Microsoft y VMware (vmware.com). También hay otros proveedores como Parallels (parallels.com).

Ahora que tiene una idea de lo que es la virtualización, emplearé el resto de la columna en explicar cómo configurarla, cómo evitar los errores más comunes y cómo implementarla en diversos equipos de su entorno.

Implementación virtual

La implementación de sistemas virtuales no tiene por qué ser diferente a la de sistemas físicos. Pero como verá hay algunas buenas razones que la hacen diferente.

En los primeros tiempos de Windows NT®, la implementación se realizaba a través de la instalación. Podía redactar un script, pero debía ejecutar todo el proceso. Una vez que finalizaba la instalación, la copia de la imagen en varios sistemas, aunque fuera un concepto bastante útil, no era compatible.

No obstante, finalmente, Microsoft decidió que tenía sentido añadir compatibilidad con sistemas Windows NT "clonados" o de disco duplicado. Así pues, hoy en día, todos los métodos disponibles al implementar sistemas físicos están disponible también para la implementación de sistemas virtuales. Es posible usar: Winnt32 (o setup.exe en el caso de Windows Vista® y Windows Server® 2008); Windows PE (1.x o 2.x, dependiendo del cliente que esté implementando tal como se ha explicado en mis columnas anteriores); Servicios de instalación remota (RIS) o Servicios de implementación de Windows (WDS); o Sysprep (la herramienta de preparación del sistema para la implementación integrada en Windows NT 4.0) y su tecnología de duplicación de disco favorita (ImageX, por ejemplo).

Pero, por supuesto, esto sólo lo tiene que hacer la primera vez que implementa un sistema operativo específico. Después, si lo desea sólo tiene que copiarlo. Aunque hay un problema con los métodos de duplicación basados en disco como los que acabo de mencionar.

Uso de Sysprep

La decisión original de Microsoft de no hacer compatible la duplicación basada en disco estaba motivada principalmente por el Identificador de seguridad (SID) de Windows NT. Afortunadamente, Sysprep proporciona una solución. Pero, en primer lugar, observemos el problema que resuelve. Tal como se explicó en support.microsoft.com/kb/314828, el SID consiste en un número de revisión de la estructura de SID (generalmente un Identificador único global o GUID) que identifica un equipo individual basado en Windows. Este identificador se usa, a continuación, en la parte de raíz del identificador para todas las cuentas locales. Las cuentas locales tienen su propio identificador único, llamado Identificador relativo (RID). El RID consiste en un identificador de cuenta concatenado con el final del SID. Así pues, la combinación de las dos se convierte en el identificador de las cuentas locales.

Veamos por qué esto es un problema usando el SID de administrador S-1-5-21-191058668-193157475-1542849698-500. Aquí, S-1-5 es el descriptor que indica que esto es un SID (la S está omnipresente en la representación textual de un SID) y 1 y 5 representan el número de revisión de SID de Windows NT y el valor de identificador de autoridad (aquí Windows Security), respectivamente. El resto es el SID real, incluido 500, que identifica esto como un SID muy conocido, la cuenta de administrador de Windows. La cuenta de administrador creada de forma predeterminada (y que no puede ser eliminada) en todas las instalaciones de Windows tiene un SID que termina en 500. Las cuentas de usuario local se agregaron a Windows una vez que la instalación comenzó la iteración sobre 1000.

PSGetSID, disponible en Windows Sysinternals (mencionado en mi columna en PSTools en technetmagazine.com/issues/2007/03/DesktopFiles), le permite enumerar un SID para un usuario determinado en un sistema o el SID del sistema. Consulte la figura 1 para ver la salida de PSGetSID para el SID de mi sistema virtual y el SID de mi cuenta de usuario, 1003.

Figura 1** La salida de PSGetSID de un SID de sistema virtual y el SID de la cuenta de usuario 1003 **(Hacer clic en la imagen para ampliarla)

Puesto que los RID de cuenta local se basan en este SID, el problema que ocurre cuando realiza una duplicación de disco de un sistema o simplemente copia una imagen de equipo virtual debe ser relativamente aparente. Si no cambia el SID (la tarea principal de Sysprep pero no la única), terminará con una copia del componente clave que hace de un sistema de Windows algo único. Si ambos Sistemas, tanto A como B, tenían el mismo SID de administrador, los usuarios en cada uno de los sistemas se identificarían a sí mismos legítimamente como el mismo usuario. Lo mismo sería verdad de todas las cuentas locales del Sistema B al autenticar al Sistema A y viceversa. Lo que es peor, estos sistemas tendrán el mismo SID cuando se presenten en Active Directory®. Así pues, si permite al Sistema A autenticarse en un recurso de dominio, pero no se lo permite al Sistema B, provocará una colisión. Si configura B para que sea denegado, entonces A será denegado también.

Así pues, es muy importante que regenere los SID en sistemas que usan Sysprep, especialmente en escenarios de sistema virtuales ya que las imágenes de sistema se pueden propagar muy fácilmente. No debe usar una herramienta de cambio de SID de terceros, sólo Sysprep. Sysprep se ha diseñado, probado y es compatible con Microsoft para preparar los sistemas para la duplicación (incluso sistemas virtuales). Consulte la figura 2 para ver un ejemplo del aspecto de Sysprep antes de cambiar el SID en un sistema. Ahora asegúrese de que la opción "No regenerar identificadores de seguridad" está siempre desactivada si prepara el sistema para la duplicación como siguiente paso.

Figura 2** "No regenerar identificadores de seguridad" deben estar desactivada al prepararse para la duplicación. **

Además de actualizar el SID a un nuevo identificador, Sysprep modifica también cualquier almacén de datos privado que esté preparado para reflejar el SID y el nombre de equipo o para cambiar su cifrado para funcionar con el nuevo SID. Algunos ejemplos son el almacén de datos de Tareas programadas y valores en la metabase IIS (si IIS está instalado).

Sysprep también elimina forzosamente todas las NIC del sistema y se apropia de los datos de configuración de red para la NIC. Puesto que la configuración de red "depende" de la NIC en el registro y que la relación de esa NIC se basa en el identificador de hardware de la NIC (lo cual fuera de un movimiento de sistema virtual a virtual con frecuencia es probable que se interrumpa), Sysprep limpia estos datos normalmente abandonados.

Sysprep limpia también toda la información de pertenencia a Active Directory de un sistema. Como resultado, debe quitar forzosamente un sistema del dominio como parte de su trabajo. Esto asegura que los sistemas que acaban de recibir nuevos SID pueden unirse al dominio de manera segura. Algunas utilidades de cambio de SID le permiten cambiar un SID de máquina sin eliminarlo del dominio, pero esto tampoco es confiable ni seguro. Si está seguro sin ninguna duda de tener que ejecutar Sysprep en un equipo que sea un miembro de dominio, o lo quita del dominio antes de que Sysprep se ejecute o ejecuta Sysprep y le permite hacerse cargo de esa tarea por usted.

En una nota relacionada, si está virtualizando cualquiera de los controladores de dominio (DC), necesita duplicar sistemas que sean simplemente servidores independientes que no han sido aumentados a DC y no se han unido al dominio. A excepción de Windows Server 2003 Small Business Server Edition, no es posible duplicar de manera segura el disco de un DC. Para crear un DC de manera segura, debe crear una imagen de disco de un servidor que esté listo para ser unido al dominio y aumentado a un DC. Sysprep (excepto en la instancia SBS muy especializada, que es bosque único/servidor único), no está enterado de cómo cambiar de manera segura los SID en un DC.

Finalmente, además de cambiar el SID y eliminar el equipo del dominio, Sysprep cambia también el nombre del equipo.

Puede parecer abrumador decir que necesita realizar todas las tareas indicadas al crear imágenes (o sólo copiando) sistemas virtuales. Pero es muy importante, especialmente si usa estos sistemas en una red con otros sistemas físicos o virtuales, en un dominio, o con cualquier otra copia de sí mismos en la red.

Si no usa Sysprep para duplicar sistemas virtuales, casi con total seguridad encontrará una serie de problemas obvios (colisiones de Active Directory o de otras redes) y otros más inesperados. Por ejemplo, sus imágenes virtuales son muy susceptibles a los piratas informáticos puesto que piratear una otorgará acceso a las otras.

Niveles de abstracción de controladores y hardware

Mencioné que los dispositivos virtuales incluidos en una imagen virtual pueden no tener controladores incluidos para Windows. Asegúrese de tener controladores a mano para sus dispositivos al implementar (o al implementar imágenes de disco mediante Sysprep), pues el temido error de controlador 0x0000007B puede aparecer fácilmente al mover una imagen virtual desde un controlador de bus de almacenamiento a otro al igual que cuando se trabaja con hardware físico. Lo mismo se aplica a las NIC. Aunque la mayoría de los productos de virtualización han procurado ofrecer un dispositivo virtual bastante universal, quizás necesite un controlador adicional para el mismo.

No es posible tampoco omitir ese molesto nivel de abstracción de hardware (HAL). Lo ideal es crear equipos virtuales que sean compatibles con multiprocesadores de Interfaz avanzada de configuración y energía (ACPI) (consulte intel.com/technology/iapc/acpi), si eso es con lo que es compatible su tecnología de virtualización. Normalmente la conversión entre HAL no es compatible (consulte support.microsoft.com/kb/309283 para obtener más información sobre aspectos específicos). Sin embargo, algunas tecnologías de virtualización, o, lo que es más importante, muchas tecnologías de migración, prometen que pueden mover sin riesgos una instalación de Windows que no sea ACPI a una instalación ACPI, o viceversa. Esto no es cierto y, para que arranque, la instalación resultante de Windows no es compatible con Microsoft si encuentra problemas. Las mismas limitaciones tratadas en la página web de asistencia técnica que acabo de mencionar son ciertas para los sistemas virtualizados. Consulte la figura 3 si desea obtener un ejemplo del aspecto del HAL en el Administrador de dispositivos en uno de mis equipos virtuales, en este caso se ejecuta usando el HAL uniprocesador ACPI. No se debe confundir con procesador único, éste es intercambiable con su equivalente multiprocesador.

Figura 3** HAL en el Administrador de dispositivos en un equipo virtual **(Hacer clic en la imagen para ampliarla)

Cambios varios

Cambie lo que pueda y acepte lo que no pueda

A la hora de considerar la migración de física a virtual o viceversa, necesita recordar las cosas que puede y no puede cambiar. Puede cambiar los siguientes aspectos de una instalación de Windows:

• La HAL (pero sólo de monoprocesador a multiprocesador o viceversa, siempre que se basen en la misma configuración de energía).
• Controladores de almacenamiento masivo (esto no es fácil, pero la mayoría de las soluciones de migración de física a virtual intentan hacer esto por su cuenta). Tenga en cuenta que la mayoría de los proveedores proporcionan una solución de almacenamiento IDE y otra SCSI. Elija sabiamente cuando implemente, puesto que moverse de una a otra no resulta muy fácil. Generalmente, si elige SCSI podrá disfrutar de un dispositivo más confiable (éste es el caso con la mayoría de las implementaciones de emulación de dispositivos SCSI del proveedor).
• Controlador de red (aunque en un escenario de migración virtual a virtual, esto será generalmente lo mismo con las tecnologías de un proveedor).

No puede cambiar los siguientes aspectos de una instalación de Windows:

• El HAL (menos en el caso mencionado anteriormente, cuando la misma configuración de energía está en uso). No debe asumir que una solución de migración que hace esto tendrá como resultado una instalación de Windows que sea fija o confiable (y lo que es más importante, no será compatible con Microsoft).

Además de cambiar el SID y el nombre del equipo, necesita también cambiar ciertos valores que pueden ser específicos de la tecnología informática virtual que usa. En particular, necesita cambiar la dirección MAC (el identificador único para dispositivos de red). Además, muchas aplicaciones virtuales tienen también su propio identificador único. La mayoría los almacenan en sus propios archivos de configuración del equipo, por lo que deseará saber cómo manipular estas entradas (y mantener su validez). Tenga en cuenta que muchos productos de virtualización que son compatibles con el Entorno de ejecución previo al arranque (PXE) bloquean el UUID de SMBIOS según su propio identificador único, acentuando la necesidad de cambiar esto (o de permitir al software de virtualización cambiarlo por usted, si es compatible) si lo une a un dominio; de lo contrario, la administración de sistemas cliente WDS o RIS podría no ser posible (si los GUID se oponen). La mayor parte de las soluciones de virtualización con las que he trabajado puede tener graves problemas de red en el caso de direcciones MAC duplicadas; por lo tanto, si no está moviendo simplemente un equipo virtual, es muy importante que cambie la dirección MAC si el software de virtualización no lo hace por usted.

Otros componentes que necesita tener en cuenta al preparar un sistema virtual para la implementación son los discos o instantáneas vinculados. Dependiendo de su solución de virtualización, es posible referirse a los mismos como discos diferenciales, pero pueden tener otro nombre. Aunque si ejecuta Sysprep para preparar un sistema y tiene instantáneas (u otra condición reversible) que vayan con el sistema virtual, éstas deben destruirse para que la imagen permanezca segura y sea confiable cuando se duplique. En el caso de una instantánea u otro enfoque de tecnología "deshacer cambios del disco", revertir una instantánea podría significar un retroceso hacia donde más de un sistema originado desde el equipo virtual original entra en conflicto con otro (o incluso con el sistema de origen original si éste es devuelto). Así que cualquier relación de instantánea o de disco diferencial debe haber ejecutado Sysprep en ella.

Optimización

La mayoría de las tecnologías de virtualización incluyen complementos o herramientas para la máquina virtual que ayudarán a mejorar el rendimiento y la experiencia de interacción con el invitado del host. Normalmente se suelen incluir la optimización del mouse y la entrada del teclado, entre otras mejoras del rendimiento y, a menudo, incluye una interacción copiar y pegar mejorada (u otro tipo de host a invitado). Instale la versión más reciente de estas herramientas en sus sistemas virtuales antes de la implementación.

También necesita asegurarse de que la memoria de cliente se configura de manera óptima para el SO invitado, pero también en contexto con los hosts en los que se implementará. Lo último que desea hacer es implementar un conjunto de imágenes de Windows XP para usar 1 GB de RAM y hospedar sistemas que no tienen tanta RAM para empezar.

Recuerde también las limitaciones que la mayoría de las tecnologías virtuales tienen hoy día, por lo que es importante para sus usuarios interactuar con cualquier periférico adjunto al sistema virtual, así como qué aplicaciones funcionarán o no en el SO invitado (la mayoría no son compatibles con DirectX 9 ni 10, por ejemplo, ni son compatibles con las versiones anteriores de una manera limitada). Puede que los usuarios no sepan qué es lo que significa o cómo se manifiesta a sí mismo (algunas aplicaciones no tratan dicho error positivamente).

Preocupaciones relacionadas con el host

Tenga en cuenta que, en general, no hay mucho de lo que preocuparse con respecto al equipo host que ejecuta la tecnología de virtualización, a pesar de si lo que ejecuta de manera subyacente es un sistema operativo completo o un Hipervisor tipo 1 que se ejecuta directamente sobre el hardware. La mayoría de las tecnologías de virtualización se han diseñado para asegurar que el SO invitado no necesite saber nada (o muy poco) acerca del host. No obstante, asegúrese de conocer qué hosts están en uso en caso de que el invitado que se haya movido de un host a otro tenga problemas. Asegure también de conocer las limitaciones del producto de su proveedor de virtualización en ciertas plataformas. Aunque es posible moverse de uno a otro, puede perder o ganar ciertas características del Hipervisor tipo 2 del SO host (la aplicación de virtualización) en el proceso.

Otros mecanismos de implementación

Vínculos de Sysprep relacionados

Los documentos siguientes le ayudarán en gran medida con Sysprep:

• Diseño de instalaciones basadas en imágenes con Sysprep
• Cómo usar la herramienta Sysprep.exe para automatizar la correcta implementación de Windows XP
• Cómo usar la herramienta de preparación del sistema (Sysprep.exe) para realizar una duplicación del disco
• Uso de la herramienta de preparación de sistemas en equipos diferentes

El uso de Sysprep o de la duplicación de disco (o simplemente ejecutar Sysprep y copiar el equipo virtual) son las opciones obvias para implementar sistemas virtuales, pero hay otras. De hecho, tanto si usa la creación de imágenes o la instalación, el uso de Windows PE puede ser más fácil con la virtualización que con los equipos físicos puesto que trabaja con archivos ISO en lugar de un CD físico. Tenga en cuenta que algunas tecnologías de virtualización no pueden adaptarse bien a los medios de DVD, así que asegúrese de comprobar la compatibilidad con su proveedor de virtualización. Puede usar winnt32 o setup.exe (en el caso de Windows Vista o Windows Server 2008), pero no hay beneficios específicos. Si usa otras tecnologías de implementación de Microsoft tales como los Servicios de implementación automatizada, su tecnología de virtualización es compatible con PXE para iniciar una implementación basada en red, como si usara RIS o WDS.

Migración

Por último, aparte de migrar realmente un equipo completo, no se olvide de la Herramienta de migración del estado de usuario (USMT). USMT le permite mover una configuración de usuario de un cliente físico a un nuevo sistema virtual fácilmente. Así pues, si sus usuarios desean migrar sus datos y configuración anteriores a un nuevo equipo virtual, puede, por ejemplo, obtener fácilmente los archivos y configuración de Windows XP, almacenarlos en un UNC e insertarlos en un equipo virtual nuevo.

Wes Miller vive en Austin, Texas. Anteriormente, trabajó en Winternals Software, en Austin, y en Microsoft como director de programas y director de productos para Windows. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.