Category: Virtualizacion


En este post veremos los aspectos y planeacion que hay que tener en cuenta para la Virtualizacion de Domain COntrollers.

Mas de 1 Domain Controller.

Se Debe intentar evitar la creación de posibles puntos únicos de falla al planear la implementación del controlador de dominio virtual, creando mas de un Domain Contoller:

  1. Ejecutar al menos dos controladores de dominio virtualizados por dominio en hosts de virtualización diferentes, lo que reduce el riesgo de perder todos los controladores de dominio, si un host de virtualización única falla.
  2. Recomendado para otras tecnologías, diversificar el hardware (utilizando diferentes procesadores, motherboards, adaptadores de red u otro hardware) en el que están ejecutando los controladores de dominio. Diversificación de hardware limita el daño que podría ser causado por un fallo que es específico para una configuración de proveedor, un controlador o una sola pieza o tipo de hardware.
  3. Si es posible, los controladores de dominio se deben ejecutar en el hardware que se encuentra en diferentes regiones del mundo. Esto ayuda a reducir el impacto de un desastre o falla que afecta a un sitio en el que están alojados los controladores de dominio.
  4. Mantener los controladores de dominio físico en cada uno de sus dominios. Esto reduce el riesgo de un fallo de la plataforma de virtualización que afecta a todos los sistemas de host que utilizan esa plataforma.

Consideraciones de seguridad

El equipo de host en el que se ejecutan los controladores de dominio virtual debe administrarse cuidadosamente como un controlador de dominio de escritura, incluso si ese equipo es sólo un equipo se unió el dominio o grupo de trabajo. Se trata de una consideración de seguridad importante. Un host mal administrado es vulnerable a un ataque de elevación de privilegios, que se produce cuando un usuario malintencionado obtiene acceso y privilegios del sistema que no fueron autorizados o legítimamente asignados. Un usuario malintencionado puede usar este tipo de ataque en peligro todas las máquinas virtuales, dominios y los bosques que los hosts de este equipo.

Asegúrese de tener las siguientes consideraciones de seguridad en cuenta cuando se planea virtualizar los controladores de dominio:

  • El administrador local del equipo que aloja el dominio virtual, se puede escribir controladores deben considerarse equivalentes en las credenciales del administrador de dominio predeterminado de todos los dominios y los bosques que pertenecen esos controladores de dominio.
  • La configuración recomendada para evitar problemas de seguridad y el rendimiento es un host que ejecuta una instalación Server Core de Windows Server 2008, con ninguna aplicación distinta de Hyper-V. Esta configuración limita el número de aplicaciones y servicios que están instalados en el servidor, que debe conducir a un mayor rendimiento y menos aplicaciones y servicios que podrían aprovecharse malintencionadamente para atacar el equipo o la red. El efecto de este tipo de configuración se conoce como una superficie de ataque reducida. En una sucursal o en otros lugares que no pueden ser garantizados satisfactoriamente, se recomienda un controlador de dominio de sólo lectura (RODC). Si existe una red de administración separada, recomendamos que el host se conecta sólo a la red de gestión.

Límites de seguridad

Uso de máquinas virtuales hace posible tener muchas configuraciones diferentes controladores de dominio. Debe prestarse especial atención a la forma en que las máquinas virtuales afectan a límites y confía en su topología de Active Directory. Configuraciones posibles para un controlador de dominio de Active Directory y el host (servidor de Hyper-V) y sus equipos invitados (máquinas virtuales que se ejecutan en el servidor de Hyper-V) se describen en la tabla siguiente.

Máquina Configuración 1 Configuración 2

Host

Grupo de trabajo o miembros de equipo

Grupo de trabajo o miembros de equipo

Invitado

Controlador de dominio

Grupo de trabajo o miembros de equipo

Domain Controllers running on Hyper-V server

  • El administrador en el equipo host tiene el mismo acceso como administrador de dominio en los huéspedes de controlador de dominio de escritura y debe ser tratado como tal. En el caso de un invitado RODC, el administrador del equipo host tiene el mismo acceso como administrador local en el huésped RODC.
  • Un controlador de dominio en una máquina virtual tiene derechos administrativos en el host, si el host está unido al mismo dominio. Hay una oportunidad para que un usuario malintencionado poner en peligro todas las máquinas virtuales, si el usuario malintencionado primero obtiene acceso a la máquina Virtual 1. Esto se conoce como un vector de ataque. Si hay controladores de dominio para varios dominios o bosques, estos dominios deben tener una administración centralizada en la que el administrador de un dominio es de confianza en todos los dominios.
  • La posibilidad de ataque de la máquina Virtual 1 existe incluso si está instalada la máquina Virtual 1 como un RODC. Aunque un administrador de un RODC explícitamente no tienen derechos de administrador de dominio, el RODC puede utilizarse para enviar las políticas para el equipo host. Estas políticas pueden incluir scripts de inicio. Si esta operación se realiza correctamente, el equipo host puede estar en peligro y, a continuación, puede utilizarse para poner en peligro las otras máquinas virtuales en el equipo host.

Seguridad de los archivos VHD

Un archivo VHD de un controlador de dominio virtual es equivalente a la unidad de disco duro física de un controlador de dominio físico. Como tal, debe ser protegido con la misma cantidad de atención que se dedica a proteger el disco duro de un controlador de dominio físico. Asegúrese de que sólo los administradores de confianza pueden acceder a los archivos VHD del controlador de dominio.

RODC

Una ventaja de RODC es la capacidad para colocar en lugares donde garantizar la seguridad física no puede ser, tal como en las sucursales. Puede utilizar el cifrado de unidad de Windows ® BitLocker ™ para proteger los archivos VHD (no los sistemas de archivos en él) de que se vea comprometida en el host a través del robo del disco físico. Para obtener más información acerca de BitLocker en Hyper-V, consulte Windows Server 2008 Hyper-V y el cifrado de unidad BitLocker (http://go.microsoft.com/fwlink/?LinkID = 123534).

Consideraciones de implementación de controladores de dominio virtualizado

Esta sección describe algunas cosas a tener en cuenta al implementar controladores de dominio en máquinas virtuales. Hay varias prácticas comunes de máquina virtual que se deben evitar al implementar controladores de dominio. También hay consideraciones especiales para el almacenamiento y sincronización de tiempo. Las siguientes secciones describen estas consideraciones.

Prácticas de implementación de virtualización para evitar

Plataformas de virtualización, como Hyper-V, ofrecen una serie de características de conveniencia que administrar, mantener, realizar copias de seguridad y migrar equipos más fácil. Sin embargo, hay algunas características que no deben utilizarse los controladores de dominio virtual y prácticas comunes de implementación. La lista siguiente describe las prácticas para evitar al implementar controladores de dominio:

  • No aplicar los diferenciación disco discos duros virtuales (VHD) en una máquina virtual que está configurando como un controlador de dominio. Esto es demasiado fácil revertir a una versión anterior, y también disminuye el rendimiento. Para obtener más información acerca de los tipos VHD
  • No clonar la instalación de un sistema operativo sin necesidad de utilizar Sysprep.exe porque no se actualizará el identificador de seguridad (SID) del equipo. (http://go.microsoft.com/fwlink/?LinkId = 137100).
  • Para ayudar a prevenir una potencial situación de deshacer actualización secuencia número (USN), no utilice copias de un archivo VHD que representa un controlador de dominio ya desplegados para implementar controladores de dominio adicionales. Los siguientes tres elementos en esta lista también se recomiendan evitar la potencial reversión de USN.  USN y USN Rollback.
  • No utilice la función Hyper-V exportar para exportar una máquina virtual que se ejecuta en un controlador de dominio.

Consideraciones operacionales para controladores de dominio virtualizado

Los controladores de dominio que se ejecutan en máquinas virtuales tienen restricciones operacionales que no se aplican a los controladores de dominio que se ejecutan en máquinas físicas. Cuando se utiliza un controlador de dominio virtualizados, hay algunas funciones de software de virtualización y prácticas que no se deben utilizar:

  • No pausar, detener, o almacenar el estado guardado de un controlador de dominio en una máquina virtual para períodos de tiempo más largos que el desecho del bosque y luego reanudar desde el estado guardado o en pausa. Haciendo esto puede interferir con la replicación. Para aprender cómo determinar el desecho del bosque, vea determinar el desecho del bosque (http://go.microsoft.com/fwlink/?LinkId = 137177).
  • No copiar o clonar discos duros virtuales (VHD).
  • No tomar o utilizar una instantánea de un controlador de dominio virtual.
  • No utilice un disco VHD de diferenciación en una máquina virtual que está configurada como controlador de dominio. Esto hace que revertir a una versión anterior demasiado fácil y también disminuye el rendimiento.
  • No utilice la función de exportación en una máquina virtual que se ejecuta en un controlador de dominio.
  • No restaurar un controlador de dominio o intentar revertir el contenido de una base de datos de Active Directory por cualquier medio distinto utilizando una copia de seguridad compatible. Para obtener más información, vea copia de seguridad y restaurar las consideraciones para virtualizar los controladores de dominio.

Backup y Restore consideraciones para controladores de dominio virtualizado

La copia de seguridad de controladores de dominio es un requisito fundamental para cualquier entorno. Copias de seguridad protegen contra pérdida de datos en caso de fallo del controlador de dominio o error administrativo. Si se produce este evento, es necesario revertir el estado del sistema del controlador de dominio a un punto en el tiempo antes de la falla o error. El método admitido de restaurar un controlador de dominio a un Estado saludable es utilizar una aplicación de backup de Directory–compatible activo, como Windows Server Backup, para restaurar una copia de seguridad de estado de sistema que se originó a partir de la instalación actual del controlador de dominio. ¿Para obtener más información acerca de cómo utilizar copia de seguridad de Windows Server con servicios de dominio de Active Directory (AD DS), consulte la Guía de paso a paso de recuperación y Backup de AD DS (http://go.microsoft.com/fwlink/?LinkId = 138501).

Con la tecnología de máquina virtual, ciertos requisitos de Active Directory restauración operaciones toma mayor importancia. Por ejemplo, si restaurar un controlador de dominio mediante una copia del archivo de disco duro virtual (VHD), omita el paso crítico de la actualización de la versión de base de datos de un controlador de dominio después de que ha sido restaurada. Replicación procederá con números de seguimiento inadecuado, resultando en una base de datos inconsistente entre réplicas de controlador de dominio. En la mayoría de los casos, este problema va sin ser detectados por el sistema de replicación y no se informa de ningún error, a pesar de las inconsistencias entre los controladores de dominio.

Hay una forma compatible para realizar backup y restore de un controlador de dominio virtualizados:

  1. Ejecutar copias de seguridad de Windows Server en el sistema operativo huésped.

Prácticas de backup y restore para evitar

Como se mencionó, los controladores de dominio que se ejecutan en máquinas virtuales tienen restricciones que no se aplican a los controladores de dominio que se ejecutan en máquinas físicas. Al volver arriba o restaurar un controlador de dominio virtual, existen ciertas funciones de software de virtualización y prácticas que no se deben utilizar:

  • No copiar o clonar archivos VHD de controladores de dominio en lugar de realizar copias de seguridad periódicas. Si el archivo VHD de él es copiado o clonado, quede obsoleto. Entonces, si el VHD se inicia en modo normal, podría ser una divergencia de datos de replicación en el bosque. Debe realizar las operaciones de backup adecuadas que son compatibles con los servicios de dominio de Active Directory (AD DS), como el uso de la función de copia de seguridad de Windows Server.
  • No utilice la función de instantánea como una copia de seguridad para restaurar una máquina virtual que se ha configurado como controlador de dominio. Problemas se producen con la replicación cuando se volver la máquina virtual a un estado anterior. Para obtener más información, vea USN y USN Rollback. Aunque usando una instantánea para restaurar un controlador de dominio de sólo lectura (RODC) no causará problemas de replicación, no todavía se recomienda este método de restauración.

Restauracion

Utilizar el proceso en la siguiente ilustración para determinar la mejor manera de restaurar el controlador de dominio virtualizado.

Writeable domain controller restoration in Hyper-V

Mas info: http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx#operational_considerations_for_virtualized_domain_controllers

Erores comunes  P2V

Recientemente he realizado un proyecto de conversion de decenas de servidores físicos a virtuales, utilizando el System Center Virtual machine manager de Microsoft 2008 SP1.  Mientras que la gran mayoría de convertir sin ningún problema en absoluto hubo algunos errores encontrados en el camino que eran fáciles de solucionar.

VSS Writer did not respond within the expected time interval – Error 13243

Esto fue un error más interesantes que surgieron en dos ocasiones y en ambas ocasiones la solución era la misma. Mientras que el error se ve como un problema con el VSS en realidad es un problema de perfil. Cuando traté de iniciar una sesión en el servidor para investigar el tema VSS el inicio de sesión que no con un perfil de usuario no se pudo cargar error. . Para resolver este problema, siga estos pasos para solucionar el perfil dañado:

  1. Iniciar sesión en el servidor con una cuenta diferente
  2. Eliminar la carpeta de perfil de usuarios% systemdrive% \ Users \% username%
  3.  Regedit yHKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ ProfileList
  4. Localizar  SID con una extensión. BAK
  5. Eliminar esta clave del Registro
  6. Salga del editor
  7. Cierre la sesión
  8. Inicie sesión como el usuario afectado y que un nuevo perfil se creará
  9. Iniciar el proceso P2V de nuevo

VMM Does not have the appropriate permissions to the resource – Error 2910

P2V Error 2

Este es un problema muy fácil de resolver. La cuenta utilizada para realizar la conversión P2V tiene que tener permisos para instalar el agente P2V de la máquina de origen. . Una vez que haya añadido a su accout al grupo Administradores local en la máquina de origen, reinicie el proceso P2V.

Si eso no funciona puede haber un problema con WMI o DCOM y Microsoft ha publicado un artículo de Knowledge Base que le guiará a través de la reparación de este.

VMM Discovered that a restart is pending – Error 3240

P2V Error 2

Este es otro fácil de resolver el problema que se produce cuando hay una actualización o una aplicación que requiere un reinicio, pero se ha instalado el servidor de origen no se ha reiniciado todavía. Debido a la actual solicitud de reiniciar ninguna instalación adicional puede llevarse a cabo y el P2V un error cuando la instalación del Agente de P2V se intenta. Basta con reiniciar el servidor de origen y reiniciar el trabajo P2V.

Agent installation timed out while waiting on service VMMAgentInstaller – Error 416

P2V error 4

Este error también se produjo en dos servidores diferentes y la solución para ambos era la misma. En este caso la instalación del Agente P2V ha fallado debido a un problema con el servicio de instalación de Windows en el servidor de origen.  Aca hay un articulo reparar el instalador MSI Una vez que haya completado estos pasos, puede reiniciar el trabajo P2V.

Online P2V of a Domain Controller is not recommended – Error 13249

P2V Error 5

Aunque no es exactamente un error no seguir esta práctica dará lugar a errores . El equipo de servicios de directorio en Microsoft afirma lo siguiente …

Hay dos opciones para solucionar este problema, crear una nueva máquina virtual y que DCPromo o realizar un P2V en línea de la DC.

VMM is unable to complete the request – Error 3157

P2V Error 7

Este es muy simple, pero puede ser causada por tres cuestiones diferentes. El servidor está apagado, no existe, tiene el firewall que bloquea WMI y / o el tráfico HTTP.

Unable to uninstall the SCVMM P2V Agent – Warning 13235

P2V error 6a

Este error se produce de vez en cuando y por lo general en combinación con otros después de los problemas de instalación MSI P2V. La resolución es entrar simplemente en la máquina virtual y desinstalar el agente de SCVMM P2V desde Programas y características. Normalmente aparece en conjunción con el siguiente error.

Timeout occured while waiting for the VM integration services to be installed – Warning 13210

P2V Error 6b

Este error aparece cuando no se pueden instalar los guest . En algunos casos no había ningún problema real, . En los otros casos se puede iniciar sesión en el Vm a través del Administrador de Hyper-V e instalar los servicios de integración de forma manual.

VMM is unable to complete the requested file transfer – Error 2940

Este error puede ocurrir por una variedad de razones, pero normalmente es un problema relacionado con la red. Cualquier cosa, desde una pérdida temporal de conectividad de red para HTTP \ HTTPS está bloqueado en el servidor de destino host de Hyper-V. El agente de transferencia de P2V la instantánea VSS del servidor de origen hasta el destino host Hyper-V a través de HTTP o HTTPS. Si el firewall en el host de Hyper-V es el bloqueo de estas conexiones o el servidor de origen y \ o el host de destino pierde conectividad de red de la P2V no se inicia o se producirá un error durante el proceso.

 

Hyper-V R2 tiene la funcion de brindar Alta Disponibilidad a nuestras maquinas virtuales en el siguiente esquema funcional vemos como funciona:

 

Algunos de lso beneficios:

  • Reducción de Costos: consolidando sus servidores obtiene un ahorro sustancial en inversión de equipamiento, manteniendo las mismas funcionalidades y performance actuales, como así también el ahorro energético y de espacio que esto implica.
  • Mejoras en la Productividad: esto se logra dado que la virtualización simplifica la administración de servidores, pudiendo automatizar gran cantidad de operaciones de IT.
  • IT Siempre Disponible: utilizando nuestra solución se asegura que su negocio siempre este en funcionamiento, esto se traduce en incremento de ingresos, como así también en la Seguridad, yen la recuperación de datos ante desastres.

En particular, en el mundo Microsoft existen tres tecnologías diferentes para cada uno de estos tipos de clustering. Dos de ellas están incluidas en Windows Server, y la otra en una edición especial.

  • Failover Cluster: Conocido también como MSCS o de almacenamiento compartido. Se utiliza para dotar de alta disponibilidad por tolerancia a fallos de servicios que por lo general tienen una dependencia del almacenamiento. Ejemplos de esto serían bases de datos, buzones de correo, máquinas virtuales, etc.
  • Clústeres de NLB (Network Load Balancing): Pensados para dotar de alta disponibilidad por tolerancia a fallos y escalabilidad a servicios de red. El ejemplo más frecuente son granjas Web o de Terminal Services. Se asume que todos los frontales tienen la información que sirven a los clientes correctamente replicada o en un repositorio central o back-end (generalmente este en Failover Cluster).

En adelante nos vamos a centrar únicamente en Failover Clustering y su relación tanto con los hosts de hyper-V como con las VMs que montemos encima. Distinguimos entonces:

  • Host Clustering: de 2 a 16 nodos con Hyper-V funcionando conjuntamente de modo que las Máquinas Virtuales puedan pivotar entre ellos, según sea necesario:
    • Bien por una caída no planificada del Host que la alberga. En este caso la VM reiniciará en alguno de los hosts del cluster automáticamente
    • Bien de manera manual o automática, por un mantenimiento planificado del host, o porque queramos redistribuir de forma diferente las cargas de trabajo entre los nodos del cluster. Esto es lo que hoy en día conocemos por Quick Migration, y en Windows Server 2008 R2 podremos hacer también con Live Migration.
  • Guest Clustering: Esto se refiere a un Failover Cluster en el que los diferentes nodos del mismo son máquinas virtuales corriendo en Hyper-V. Rizando el rizo puedes tener guest clustering en HA, es decir que las VMs que componen el cluster virtual, estén albergadas a su vez en un host cluster de Hyper-V

Vamos a tratar de aclarar las dudas más frecuentes que suelen surgir sobre todo esto:

Host Clustering

Creo que esto se entiende fácilmente simplemente diciendo que es la combinación de la característica (role) de Hyper-V y la funcionalidad (feature) de Failover  Cluster incluidos en Windows Server 2008 x64 Enterprise y Datacenter. La configuración hardware más típica para montar esto consiste en:

  • Almacenamiento compartido (típicamente SAN, con Fiber Channel, iSCSI o SAS, aunque este tipo de tecnologías proliferan). Muy importante en este punto y en lo que sigue: Windows Server 2008 NO SOPORTA Failover Clustering usando el tradicional bus SCSI
  • De 2 a 16 servidores que tienen la capacidad de acceder a un cierto numero de LUNs expuestas a todos ellos por el almacenamiento compartido
  • Dos o tres subredes diferentes para gestión, acceso publico y heartbeat.

Por suerte, puedo ahorrarme el hacer un paso a paso de la creación de un cluster de Hyper-V porque abundan. Si que creo que es importante referenciar la documentación que considero “autoritativa” para ello:

Hyper-v  configurado para “Alta disponibilidad” con pocos recursos = export + import + diskshadow + robocopy

Primero que todo aclarar un poco el titulo “alta disponibilidad”, ya que realmente no trataremos de alta disponibilidad, ya que no tenemos un storage ni un cluster.

Este articulo tratará el caso típico de una PYME que implementa Hyper-v en 2 host Físicos,  para crear Vms

La típica pregunta del Cliente

¿ Que pasa si falla uno de los host físicos ? R: Caen todas las maquinas virtuales que estaban en ese servidor físico, ya que no se encuentran en una solución de alta disponibilidad.

¿ Puedo estar preparada ante una caída de uno de los servidores físicos ? R: SI , realizando periódicamente Export e imports de las máquinas entre los host físicos

¿ El proceso de export detiene la máquina ? R: SI, con lo cual se pierde la conexión a esta

Cliente : mmmmmmmmmmm

¿ Puedo respaldar las máquinas sin que estas pierdan conexión “Hot Backup ” ? R: SI, lo puede hacer con System Center DPM 2010 (muchos doalres en licencia)  o simplemente con la herramienta de línea de comando DiskShadow

Cliente 🙂

Pcampos:  ¿ Le propongo una solución ?

Paso 1 : Crearemos un Export de cada una de las maquinas virtuales y lo importaremos en el otro host físico y las dejaremos apagadas

Paso 2 : Crearemos una tarea programada con diskshadow el cual realizara un SnapShot de Disco, para así poder extraer los discos duros VHDs de las máquinas virtuales y trasladarlos al otro host físico y dejarlos en la misma ruta de la maquina virtual importada anteriormente

El diagrama seria el siguiente

image

Como Pueden ver el VMHOST1 tiene las maquinas VM1,VM2,VM3,VM4 en estado Encendido y las maquinas VM4,VM5.VM6,VM7 en estado apagado

Entonces el VMHOST2 tiene todo al revés, las maquinas VM4,VM5.VM6,VM7 en estado prendido y  las maquinas VM1,VM2,VM3,VM4 en estado apagado.

¿ Como llegamos a eso ? Simplemente realizando un Export en las maquinas de origen y realizando un Import en el host de destino, es decir una sola vez perdimos conectividad con nuestras maquinas

Exportación de Maquina Virtual

image

Exportamos la máquina a una carpeta local y después la movemos al VMHOST1 a la carpeta C:\maquinas\VM1

Importación de Maquina Virtual en VMHOST1

image

image

Entonces quedaría así el VMHOST1

image

y el VMHOST2

image

Realizaremos solo un ejemplo con la máquina VMH1 que se esta ejecutando en el VMHOST1 y esta apagada en el VMHOST2

La ruta de la maquina virtual en el VMHOST1 es C:\maquinas\VM1\ y la ruta del de la maquina virtual vm1 “apagada” en el VMHOST2 es C:\maquinas\VM1\

Ahora crearemos los scripts para hacer un HOT backup del disco C: del disco del VMHOST1

Nos creamos un archivo de texto RespaldaHypervDiskshadow.txt, este archivo lo guardaremos en C:\

———————RespaldaHypervDiskshadow.txt——————————
Delete Shadows all
set context persistent
set verbose on
add volume C: alias MaquinasVirtuales
create
Expose %MaquinasVirtuales% Q:
exec C:\HypervBK.bat
Delete Shadows all
unexpose Q:
Exit

————————————————————————–

Nos creamos otro archivo .bat llamado HyperBK.bat, el cual realizara una copia atreves de la red de la máquina VM1 a al VMHOST2 “la letra Q es donde se monta la instantánea de disco”, este archivo lo guardaremos en el disco D:\

————————-HypervBK.bat————————————————–
robocopy “Q:\maquinas\VM1 \\VMHOST2\C$\maquinas\VM1 *.vhd /E verify >nul
——————————————————————————————

Finalmente dejamos una tarea programada todos los dias en la noche con el siguiente comando

diskshadow -s C:\RespaldaHypervDiskshadow.txt

PD: Para que esto funcione correctamente, el nombre de la red al cual esta conectada nuestra maquina virtual, debe ser la misma en ambos servidores  

Muchas veces necesitamos copiar una maquina virtual a otro servidor (host)  ¿Es suficiente con copiar los Discos Virtuales?

Introducción y descripción del problema

Copiar o mover Máquinas Virtuales es una operación relativamente frecuente al trabajar con cualquier sistema de virtualización, ya sea Hyper-V, o cualquier otro (Xen, VMware, etc.).

Lo que se acostumbre es:

  • Copiar los Discos Virtuales a la ubicación deseada en el servidor destino.
  • Crear una nueva Máquina Virtual en el servidor físico (Host) destino, con la misma configuración que la Máquina Virtual original (CPUs, RAM, Tarjetas de Red, etc.), utilizando los Discos Virtuales previamente copiados.

Seguramente nos funcione pero tiene varios inconvenientes de este método (que no son pocos) :

  • Es neceario volver a crear manualmente la Máquina Virtual en el servidor físico (Host) destino, parametrizada de forma correcta (CPUs, RAM, Tarjetas de Red, Startup, Shutdown, carpeta de Snapshot, Controladoras SCSI, etc.).
  • Es necesario volver a configurar las Tarjetas de Red en la Máquina Virtual (Guest), es decir, la configuración TCP/IP y demás. Especialmente rollo, si la Máquina Virtual en cuestión es miembro de un Cluster NLB o de un Microsoft Cluster (MSCS), o si dispone de múltiples tarjetas de red, por poner algún ejemplo.
  • En algunos casos (ej: Windows Server 2008, Windows Storage Server 2008, etc.), al mover de este modo las Máquinas Virtuales, el Sistema Operativo Guest interpreta que lo estás clonando (malamente), y solicita volver a Activar Windows.

Para no tener este inconveniente lo recomendable es utilziar: Export,import

Sólo se puede hacer un Export de una Máquina Virtual en estado detenido (Off) o guardado (saved)

Al utilizar la opción Export de Hyper-V Manager, se nos solicita la ruta que se desea utilizar para depositar los ficheros correspondientes al Export de nuestra Máquina Virtual. Del mismo modo, también si no solicita si deseamos exportar sólo la configuración (Export only the virtual machine configuration), o en su defecto la Máquina Virtual completa (con su correspondientes Virtual Disks, Estado y los Snapshots de la Máquina Virtual).

Al realizar un Export de una Máquina Virtual completa (incluyendo los Discos Virtuales, Estado y Snapshots), en la ruta que hemos especificado para el Export (ej: F:\Exports) se creará una subcarpeta con el nombre de la Máquina Virtual (ej: F:\Exports\VSQL06). Dicha subcarpeta contendrá los siguientes elementos:

  • Un fichero denominado config.xml (ej: F:\Exports\VSQL06\config.xml). Almacena información, como la ubicación original de los Discos Virtuales en el Host de origen.
  • Una subcarpeta Snapshots (ej: F:\Exports\VSQL06\Snapshots). Almacenará todas las instantáneas (Snapshots) de la Máquina Virtual, si las tuviese.
  • Una subcarpeta Virtual Hard Disks (ej: F:\Exports\VSQL06\Virtual Hard Disks). Almacenará todos los Discos Virtuales de la Máquina Virtual.
  • Una subcarpeta Virtual Machines (ej: F:\Exports\VSQL06\Virtual Machines). Almacenará la exportación del fichero de configuración de la Máquina Virtual (ojo que no es el fichero XML de configuración de la Máquina Virtual, sino un fichero con extensión EXP), junto con una subcarpeta con los correspondientes ficheros de estado de la Máquina Virtual (los ficheros BIN y VSV). Evidentemente, los ficheros de estado sólo existirán sin la Máquina Virtual estaba en estado guardado (Saved) al realizar el Export, ya que si estaba en estado detenido, no existirá ninguno de estos ficheros de estado. Tanto el nombre del fichero de exportación de la Máquina Virtual como la subcarpeta, coincidirá con el Globally Unique Identifier (GUID) de la Máquina Virtual.

Del mismo modo, al realizar un Export de una Máquina Virtual especificando sólo la configuración (sin Discos Virtuales, ni Estado, ni Snapshots), en la ruta que hemos especificado para el Export (ej: F:\Exports) se creará una subcarpeta con el nombre de la Máquina Virtual (ej: F:\Exports\VSQL06). Dicha subcarpeta contendrá los siguientes elementos:

  • Un fichero denominado config.xml (ej: F:\Exports\VSQL06\config.xml). Almacena información, como la ubicación original de los Discos Virtuales en el Host de origen.
  • Una subcarpeta Snapshots (ej: F:\Exports\VSQL06\Snapshots). Almacenará información de configuración de las instantáneas (Snapshots) de la Máquina Virtual, si las tuviese, pero no almacenará el contenido de las Instantáneas.
  • Una subcarpeta Virtual Machines (ej: F:\Exports\VSQL06\Virtual Machines). Almacenará el fichero de configuración de la Máquina Virtual. Aunque puede contener la subcarpeta de los ficheros de estado de la Máquina Virtual (los ficheros BIN y VSV), estará vacía aunque la Máquina Virtual fuese exportada en estado guardado (Saved). Vamos, que en este caso, no se exporta el Estado.

Claro está, que un Export completo de una Máquina Virtual (incluyendo los Discos Virtuales, Estado y Snapshots), en función del tamaño de los Discos Virtuales, puede resultar una operación especialmente costosa, mientras que un Export de sólo la configuración de una Máquina Virtual será instantáneo, como el café ;-). Para aclarar conceptos:

  • Un Export completo de la Máquina Virtual, nos sirve de Copia de Seguridad (Backup) completo de la Máquina Virtual, ya que incluye toda la información asociada a la misma, pudiendo importarla en el mismo o diferente Host. Por el contrario es más pesado, ya que en función del tamaño de los Discos Virtuales y de los Snapshots, las necesidades de almacenamiento y el tiempo necesario para su ejecución, pueden aumentar considerablemente.
  • Un Export de sólo la configuración de la Máquina Virtual, puede resultar útil en algunos casos, como para cambiar la ubicación de la Máquina Virtual dentro del mismo Host. Sin embargo, al menos actualmente no recomiendo utilizarlo, ya que en las pruebas realizadas me ha dado algún problema en la Importación.Así, nos podemos encontrar con el mensaje de error Import Failed: Virtual Machine state was not copied. He leído por los interneses que como Workaround, podemos modificar el fichero config.xml, cambiando el valor de VmStateCopied de false a true, pero esto a mí no me ha funcionado (seguro que por alguna razón, pero no he pillado el porqué). Otra alternativa, es eliminar el fichero config.xml, teniendo en cuenta que esto no nos permitirá mantener el GUID de la Máquina Virtual (es decir, no podremos utilizar la opción Reuse old virtual machine IDs) y además tras la importación deberemos establecer manualmente alguna configuración (ej: la ubicación de los Discos Virtuales y carpeta de Snapshots, que vienen especificados en el config.xml que eliminamos). En cualquier caso, no he hecho muchas pruebas más, ya que me ha resultado un poco frustrante.

Contiamos. Una vez que ha finalizado el Export de la Máquina Virtual, estaremos en situación de poder realizar el Import de la Máquina Virtual, ya sea en un Host diferente o en el mismo Host.

Lo primero que deberemos tener en cuenta al hacer un Import de una Máquina Virtual de Hyper-V, es que el Import sólo se puede hacer una vez. El motivo, es que tras ejecutar el Import de una Máquina Virtual, el fichero config.xml es eliminado, y el fichero de exportación de la configuración de la Máquina Virtual (el fichero EXP) también es eliminado (en su lugar aparecerá un fichero XML de configuración de la Máquina Virtual). Evidentemente, sin estos dos ficheros clave, no podremos volver a ejecutar otra operación de Import.

Otro detalle importante a tener en cuenta, es que una Máquina Virtual importada es almacenada y ejecutada desde la ubicación desde la que ha sido importada. Evidentemente, esto hace que la operación de Import sea muy rápida, ya que evita tener que copiar los ficheros correspondientes a los Discos Virtuales a una ubicación diferente, lo cual suele ser una operación costosa por el tamaño de los mismos. Pero claro, deberemos tener claro dónde deseamos realizar el Export, y tener en cuenta que nos puede tocar copiar el Export una vez que lo hemos generado (lo cual, puede ser algo costoso).

Es decir, después de ejecutar el Export de una Máquina Virtual, es posible copiar o mover los ficheros del Export de la Máquina Virtual, para posteriormente importarlos desde la ubicación deseada, que en consecuencia no tiene porqué ser la misma ubicación del Export original. Este es un punto clave, ya que en función de las rutas definitivas sobre las que deseemos ejecutar la Máquina Virtual (tras su importación), tenemos claramente dos alternativas:

  • Realizar el Export de la Máquina Virtual directamente sobre la ubicación deseada.
  • Realizar el Export de la Máquina Virtual sobre una ubicación temporal, y posteriormente mover o copiar los ficheros del Export a la ubicación definitiva.

En ambos casos, tras la importación podremos cambiar la ubicación de los Discos Virtuales y la ubicación de la carpeta de Snapshot.

Continuando con nuestro caso de ejemplo, anteriormente realizar un Export desde un servidor denominado HOST01. Dicho Export lo almacenamos en el disco local F:\Exports, creándose una subcarpeta F:\Exports\VSQL06, con la información del export (el fichero config.xml y las subcarpetas Snapshots, Virtual Hard Disk y Virtual Machines).

Partiendo de esta situación, lo siguiente que podemos hacer el copiar los ficheros de dicho Export al Host de destino, que en este caso de ejemplo se denomina HOST02. Aprovecharemos para dejar los ficheros del export en la ubicación sobre la cual deseamos importar y ejecutar la Máquina Virtual, en particular, en la raíz del disco F del servidor HOST02. De este modo, tendremos:

  • F:\config.xml.
  • F:\Snapshots
  • F:\Virtual Hard Disks
  • F:\Virtual Machines

Realizadas estas operaciones de copia y movimiento de ficheros, en el servidor HOST02 abrimos la herramienta administrativa Hyper-V Manager, y seleccionamos la opción Import Virtual Machine del menú contextual del servidor (esto es, click con el botón derecho), como se muestra en la siguiente pantalla capturada.

En el diálogo Import Virtual Machine, especificaremos la ubicación desde la que deseamos importar, en nuestro caso la ruta F:\, que es donde se encuentra el fichero config.xml y el resto de subcarpetas con el contenido de la Exportación. La opción Reuse old virtual machine IDs, hace referencia al Globally Unique Identifier (GUID) de la Máquina Virtual, un númerito (dícese churro) generado aleatoriamente para cada máquina virtual y que debe ser único. Por ello, la práctica habitual implica que si estamos moviendo una Máquina Virtual seleccionaremos la opción Reuse old virtual machine IDs, y si estamos duplicando la Máquina Virtual dejaremos la opción Reuse old virtual machine IDs en blanco para que se genere un GUID nuevo y único para la nueva copia de la Máquina Virtual.

En mi caso de ejemplo, estoy moviendo una Máquina Virtual a un Host diferente, por lo que marcaré la opción Reuse old virtual machine IDs, como se muestra en la siguiente pantalla capturada.

La importación me insulta. Mensaje acojonativo: import completed with warning. Please check the Admin events in the Hyper-V Virtual Machine Management service event log for more information.

En el  el Event Log indicado, obtenemos el detalle que búscabamos.

 

Disk2vhd es una utilidad que crea VHD (Virtual Hard Disk – La máquina virtual de Microsoft en formato de disco)para su uso en Microsoft Virtual PC o Microsoft Hyper-V máquinas virtuales (VM). La diferencia entre Disk2vhd y otras herramientas de física a virtual es que puede ejecutar Disk2vhd en un sistema que está conectado. Disk2vhd utiliza la capacidad de Windows de instantáneas de volúmenes, introducido en Windows XP, para crear instantáneas puntuales consistentes en el tiempo de los volúmenes que desea incluir en una conversión. Usted puede incluso tener Disk2vhd crear los discos duros virtuales en los volúmenes de locales, incluso los que se convierten (aunque el rendimiento es mejor cuando el disco duro virtual en un disco diferente a los que se está convirtiendo).

La interfaz de usuario Disk2vhd listas de los volúmenes presentes en el sistema:

Se creará un disco duro virtual para cada disco en el que residen los volúmenes seleccionados. Conserva la información de partición del disco, pero sólo copia el contenido de los datos de los volúmenes del disco que están seleccionados. Esto le permite capturar sólo los volúmenes del sistema y excluir los volúmenes de datos, por ejemplo.

Nota: Virtual PC es compatible con un tamaño máximo de disco virtual de 127 GB. Si crea un disco duro virtual de un disco más grande no será accesible desde un Virtual PC.

Para usar VHD producido por Disk2vhd, crear una máquina virtual con las características deseadas y agregar el VHD en la configuración de la máquina virtual de los discos IDE. El primer arranque, una máquina virtual arranque de un ejemplar capturado de Windows detectará el hardware de la VM e instalar automáticamente los controladores, si está presente en la imagen. Si los controladores necesarios no están presentes, su instalación a través de la Virtual PC o componentes de integración de Hyper-V. También puede adjuntar a VHD con el Windows 7 o Windows Server 2008 R2 Administración de discos o empresas de servicios públicos Diskpart.

Nota: no se adhieren a discos duros virtuales en el mismo sistema en el que los creó, si usted planea en el arranque de los mismos. Si lo hace, Windows le asignará el VHD una firma de disco nuevo para evitar una colisión con la firma de disco de origen es el VHD. referencias de los discos de Windows en la base de datos de configuración de arranque (BCD) por la firma de disco, así que cuando eso ocurre arrancar Windows en una máquina virtual no podrá localizar el disco de arranque.

Disk2vhd ejecuta Windows XP SP2, Windows Server 2003 SP1 y superior, incluyendo los sistemas x64.

Aquí está una captura de pantalla de una copia de una cuenta de Windows Server 2008 R2 Hyper-V del sistema se ejecuta en una máquina virtual en la parte superior del sistema se realizó a partir de:

Uso del comando de línea

Disk2vhd incluye opciones de línea de comandos que le permiten el guión de la creación de discos duros virtuales. Especificar los volúmenes que desee incluir en una instantánea por letra de unidad (por ejemplo C:) o use “*” para incluir todos los volúmenes.

Usage: disk2vhd <[drive: [drive:]…]|[*]> <vhdfile>
Example: disk2vhd * c:\vhd\snapshot.vhd

Download Disk2vhd

(811 KB)