En este post veremos como migrar máquinas virtuales de VMware vSphere a Microsoft Hyper-V, para ello, vamos a utilizar Windows Admin Center.

Fuente captura de pantalla y post: Microsoft Learn

• Para empezar, tenemos que tener desplegado y configurado en nuestra infraestructura Windows Admin Center, en estos post que realizamos hace algún tiempo en este mismo blog podéis ver como se instala y configura Windows Admin Center.
• Estos son los requisitos que nos indica Microsoft que debemos de tener instalados en nuestro Windows Admin Center:
• Instalamos PowerCLI, para ello, nos abrimos PowerShellcomo administrador, y ejecute el siguiente comando para instalar el módulo PowerCLI, Install-Module -Name VMware.PowerCLI:

• Comprobamos que el módulo está instalado, ejecutando, Get-Module -Name VMware.PowerCLI -ListAvailable:

• Probamos la conexión a vCenter Server mediante la ejecución de, Connect-VIServer -Server «<vCenterServerFQDN_or_IP>» -User «<username>» -Password «<password>» -Force:

• Instalamos:
• Microsoft Visual C++ Redistributable
• Paquetes redistribuibles de Visual C++ para Visual Studio 2013
• Descargamos VMware Virtual Disk Development Kit (VDDK) versión 8.0.3. Extraemos el contenido y lo copiamos en el directorio, C:\Archivos de programa\WindowsAdminCenter\Service\VDDK, debemos asegurarnos de descargar VDDK versión 8.0.3 específicamente, no se admiten otras versiones.
• Aquí las tenemos descargadas, las vamos instalando en el orden indicado:

• Uso de la puerta de enlace de Windows Admin Center V2: número de compilación de versión mínima 24102.4.12.10:

• Requisitos previos del host vCenter o ESXi

Ninguno.

• Requisitos previos del host de Windows Server

Ninguno.

• Versiones de vCenter admitidas:
• La extensión admite VMware VCenter versión 6.x o 7.x o 8.x.
• Para conectarse a vCenter desde la extensión, mantenga la siguiente información de vCenter a mano:
• Nombre de dominio completo (FQDN)
• Nombre de usuario
• Contraseña
• Sistemas operativos invitados compatibles:
• Sistemas operativos Windows:
• Windows Server 2025, 2022, 2022 Azure Edition, 2019, 2016, 2012 R2
• Windows 10, Windows 11
• Sistemas operativos basados en Debian:
• Ubuntu Linux
• Ubuntu 20.04, 24.04
• Debian 11, 12, 13

• Accedemos a nuestro Windows Admin Center:

• Nos vamos a configuración:

• Accedemos a Puerta de enlace > Extensiones > Extensiones disponibles > VM Conversion (Preview) > Instalar:

• Accedemos a Puerta de enlace > Extensiones > Extensiones instaladas > VM Conversion (Preview) y vemos que ya está instalada:

• Ahora desde Windows Admin Center > Todas las conexiones, accedemos a nuestra puerta de enlace (host de Windows Admin Center):

• Sobre Extensiones > Conversión de VM (versión preliminar), conectamos nuestro vCenter:

• Introducimos el FQDN de nuestro vCenter con sus credenciales, Enviar:

• Como podemos ver, ya estamos conectado a nuestro vCenter, y podemos visualizar todas las máquinas virtuales de VMware vSphere:

• Ahora, vamos a migrar una máquina de nuestro vCenter a un servidor de Hyper-V ubicado en un Failover Cluster, para ello, accedemos al servidor de Hyper-V en Windows Admin Center al que queramos migrar la máquina virtual:

• Sobre el Servidor de Hyper-V > Extensiones > Conversión de VM (versión preliminar), seleccionamos la máquina virtual y damos a Sincronizar:

• Sobre Sincronizar máquina virtual, vemos la ruta de acceso para almacenar los datos, Sincronizar:

• Como podemos ver, la sincronización está en curso:

• Como vemos, la sincronización ha sido completada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, que el disco virtual de la máquina ha sido migrado al formato .vhdx que utiliza Hyper-V:

• Ahora, ya podemos crear una nueva máquina virtual y adjuntarle este disco que hemos migrado:

• Aquí tenemos ya, la máquina virtual migrada, operativa y funcionando sobre Hyper-V:

Saludos y espero que os sea de ayuda

En este post veremos cómo migrar máquinas virtuales de Hyper-V a Proxmox VE 9.0.

• Esta será la máquina virtual, que vamos a migrar de Hyper-V a Proxmox VE 9.0:

• Para empezar, copiamos el disco de la máquina virtual que queremos migrar a otro equipo desde el que tenemos acceso al hypervisor de proxmox:

• Una vez que tenemos copiado el disco, vamos a importarlo a nuestro proxmox con el comando scp E:\UBUNTU1804.vhdx root@proxmoxlab11.ragasys.net:/mnt/pve/ISO:

• Ahora nos abrimos una consola en nuestro proxmox y accedemos al directorio en el que hemos copiado el disco vhdx de Hyper-V:

• Con el comando qemu-img convert -p -f vhdx -O qcow2 UBUNTU1804.vhdx UBUNTU1804.qcow2, vamos a convertir el disco vhdx a qcow2 que es el formato que utiliza proxmox:

• Ahora nos creamos una máquina virtual sin disco:

• Ahora con este comando, le vamos a agregar el disco qcow2 a la máquina que hemos creado, qm importdisk 102 qcow2 DTS01VMCT:

• Como vemos se ha importado correctamente:

• Si accedemos al datastore, vemos que ya nos aparece el disco:

• Si accedemos al Hardware de la máquina virtual, vemos que ya nos aparece el disco virtual que hemos importado, pero nos aparece sin usar:

• Para añadirlo, lo editamos y damos a Agregar:

• Como vemos ya forma parte de la máquina virtual:

• Iniciamos la máquina virtual:

• Y aquí tenemos nuestra máquina Ubuntu migrada de Hyper-V a Proxmox funcionando y operativa:

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error en las réplicas de máquinas virtuales que hemos mandado desde Hyper-V a Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Lo primero que vamos a ver, es como se realiza una Conmutación por error de prueba, para ello, accedemos a almacén de recovery service > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error de prueba:

• Le indicamos la dirección de conmutación por error y la red virtual, clic sobre Aceptar:

• Aquí vemos como se está realizando el trabajo:

• Una vez terminada la conmutación por error de prueba, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina levantada:

• Una vez realizada la prueba, vamos a proceder a realizar la limpieza de la conmutación por error de prueba, para ello, accedemos al elemento replicado y sobre Información general, damos a Limpiar conmutación por error de prueba:

• Le ponemos una nota y marcamos el check de que la prueba está completa, Aceptar:

• Como vemos, la limpieza de la conmutación por error de prueba se ha realizado correctamente:

• Ahora vamos a realizar una Conmutación por error planeada, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Como podemos ver, la conmutación por error planeada, se ha realizado correctamente:

• Una vez terminada la conmutación por error planeada, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

• Ahora vamos a suponer, que nuestra máquina virtual principal en el servidor on-premise de Hyper-V, no nos inicia, por el motivo que sea, vemos que esta apagada:

• Vamos a realizar entonces una Conmutación por error, para ello, accedemos a almacén de recovery services > Elementos protegidos > Elementos replicados y clicamos sobre la réplica:

• Una vez en el elemento replicado, sobre Información general, damos a Conmutación por error:

• Nos indica la dirección de conmutación por error, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error:

• Como podemos ver, la conmutación por error se ha realizado correctamente:

• Una vez terminada la conmutación por error, podemos ver, que nos ha desplegado la máquina virtual con sus dos discos:

• Accedemos a la IP privada que nos ha dado, podemos acceder por la IP privada, ya que tenemos un VPN site to site entre nuestro entorno On-premise y Azure:

• Aquí tenemos la máquina virtual levantada:

• Este proceso también nos puede valer para migrar máquinas virtuales de Hyper-V On-premise al Cloud de Azure, en caso de querer migrar daríamos a Aceptar:

• Ahora en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Ahora, para volver a dejar todo como estaba, es decir, que la máquina virtual replique desde el entorno on-premise de Hyper-V a Azure, debemos de hacer otra conmutación por error planeada, para ello, en el elemento replicado, sobre Información general, damos a Conmutación por error planeada:

• Nos indica la dirección de conmutación por error planeada, que ahora es al contrario que antes, clic sobre Aceptar:

• Si accedemos al almacén de recovery services > Trabajos de Site Recovery, aquí vemos el proceso que va a seguir la conmutación por error planeada:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver, como se está realizando la conmutación por error en sentido inverso, y todos los cambios que se hayan hecho en la máquina virtual levantada en Azure, se van a aplicar a la máquina virtual on-premise:

• Cuando nos salga este aviso, debemos de Completar la conmutación por error:

• Le indicamos que Sí:

• Como podemos ver, la conmutación por error planeada en el sentido inverso, se ha realizado correctamente:

• Vemos que la máquina virtual en Azure se ha detenido:

• Y se está ejecutando de nuevo, en nuestro entorno on-premise de Hyper-V:

• Para terminar, en el elemento replicado, sobre Información general, damos a Confirmar:

• Nos indica si queremos confirmar la conmutación por error planeada, Aceptar:

• Aquí vemos que la confirmación ha sido correcta:

• Como podemos ver, si accedemos al grupo de recursos donde se ubicaba la máquina virtual que habíamos levantado en Azure tras la conmutación por error planeada, esta máquina ha desaparecido, tras la confirmación:

• Una vez confirmada, debemos de habilitar la replicación inversa, para ello, nos vamos al Elemento replicado > Información general > … > Replicación inversa y Aceptar:

• Como podemos ver, todo nos ha quedado como estaba originalmente en Azure:

• Como podemos ver, todo nos ha quedado como estaba originalmente en on-premise Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo replicar máquinas virtuales desde un entorno on-premise con Hyper-V a un entorno cloud con Microsoft Azure.

El diagrama de la infraestructura que vamos a utilizar será el siguiente:

• Para empezar, vemos que tenemos nuestro servidor de Hyper-V con la máquina virtual que vamos a replicar a Azure, esta máquina tiene dos discos, uno de sistema y otro de datos:

• En Azure vamos a crear un grupo de recursos llamado replicas-hv-rg, dónde vamos a ubicar todo lo necesario para realizar las réplicas de las máquinas virtuales de Hyper-V, en este link de este mismo blog, podemos ver como se crea un grupo de recursos:

• También nos debemos de crear una red virtual con su espacio de direcciones y con una subred, para cuando realicemos una conmutación por error de la réplica, podamos levantar la máquina virtual en Azure, en este link de este mismo blog, podemos ver como se crea una red virtual:

• Ahora nos creamos una cuenta de almacenamiento, para ello, nos vamos a Cuentas de almacenamiento > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el Grupo de recursos, el nombre de la cuenta, la Región, el Rendimiento que es nuestro caso será Estándar y la Redundancia que en nuestro caso será Almacenamiento con redundancia local (LRS):

• Sobre Avanzado, lo dejaremos todo por defecto:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Protección de datos, debemos de deshabilitar, la eliminación temporal para blobs, la eliminación temporal para contenedores y la eliminación temporal para recursos compartidos de archivos, ya que si no, cuando configuremos el almacén de recovery services nos dará error:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya la tenemos creada, esta cuenta de almacenamiento será usada para almacenar los datos de las réplicas y los puntos de recuperación de las máquinas virtuales:

• Ahora vamos a crear un almacén de recovery services, que se va a encargar de gestionar los puntos de recuperación y las réplicas de las máquinas virtuales, para ello, accedemos a Almacénes de Recovery Services > Crear:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos, le asignamos un nombre y la región:

• Sobre Redundancia, le indicamos Redundancia local:

• Sobre Cifrado, lo dejaremos todo por defecto:

• Sobre Propiedades del almacén, lo dejamos tal cual está, no habilitamos la inmutabilidad:

• Sobre Redes, lo dejaremos todo por defecto:

• Sobre Etiquetas las podemos configurar ahora o a posteriori, en mi caso, no vamos a configurar ninguna en este momento, ya dedicaremos un post a las Etiquetas, que como veremos pueden ser muy útiles:

• Sobre Revisar y crear, nos muestra un resumen de las configuraciones y que la validación ha sido superada, clic sobre Crear:

• Podemos ver que la implementación se ha completado correctamente:

• Si nos vamos al grupo de recursos, podemos ver, que ya tenemos creado este almacén de recovery services:

• Ahora accedemos al almacén de recovery services y nos vamos a Infraestructura de Site Recovery:

• Como podemos ver, tenemos para configurar todo tipo de infraestructuras, para máquinas virtuales de Azure, máquinas físicas, máquinas de VMware (que lo vamos a ver en otro post), para System Center VMM, y la que nos interesa a nosotros en estos momentos que son Para sitios de Hyper-V:

• Lo primero que vamos a realizar será crearnos un Sitio de Hyper-V, donde le indicamos un nombre:

• Como vemos, ya tenemos creado el sitio:

• Lo siguiente será, agregar un host de Hyper-V, para ello nos vamos a Hosts de Hyper-V > Agregar servidor:

• Aquí se nos muestran todos los pasos para agregar el host de Hyper-V:

• Los dos primeros pasos, los cumplimos, procedemos por tanto a descargar el instalador del proveedor de Microsoft Azure Site Recovery (paso 3) y a descargar la clave de registro del almacén para registrar el host en un sitio de Hyper-V (paso 4):

• Una vez descargados, sobre nuestro servidor de Hyper-V vamos a proceder a instalar el proveedor de Microsoft Azure Site Recovery usando la clave de registro del almacén para registrar el servidor en el almacén (paso 5).
• Activamos las actualizaciones de Microsoft update:

• Damos a instalar:

• Comienza el proceso de instalación:

• Aquí vemos que ha finalizado correctamente, ahora procedemos a registrar el servidor en el almacén de recovery services de Azure, clic en Registrarse:

• Sobre Configuración del almacén, añadimos el Archivo de clave:

• Sobre Configuración de proxy, le indicamos que nos vamos a conectar directamente con Azure Site Recovery sin un servidor proxy:

• Comienza con el registro:

• Pasados unos minutos, ya tenemos nuestro servidor de Hyper-V registrado en nuestro almacén de recovery services de Azure, finalizamos:

• Para verificar que todo está correcto, nos vamos a nuestro almacén de recovery services en Azure, a la parte de Infraestructura de Site Recovery > Hosts de Hyper-V, y vemos que nos aparece como un servidor registrado y en estado Conectado:

• Ahora vamos a crear una directiva de replicación, para ello, nos vamos a Infraestructura de Site Recovery > Directivas de replicación > + Directiva de replicación:

• Le indicamos un Nombre, el tipo de origen que será Hyper-V, el tipo de destino que será Azure, la frecuencia de copia, retención de puntos de recuperación en horas, la frecuencia de instantáneas coherentes a nivel de aplicación y la hora de inicio de la replicación inicial:

• Aquí vemos la directiva de replicación creada:

• Una vez creada, la tenemos que asociar al sitio de Hyper-V:

• Como podemos ver, ya está asociada:

• Una vez definida la infraestructura de Site Recovery para Hyper-V, vamos a proceder a configurar las réplicas de nuestras máquinas virtuales de HyperV, para ello, accedemos a nuestro Almacén de recovery services > Elementos protegidos > Elementos replicados > Replicar > Máquinas de Hyper-V a Azure:

• Sobre Entorno de origen, seleccionamos el sitio de Hyper-V que nos creamos anteriormente:

• Sobre Entorno de destino, seleccionamos la suscripción, el grupo de recursos, el modelo de implementación, el tipo de almacenamiento y la red dónde se va a ubicar la máquina virtual en caso de que tengamos que levantarla en Azure al hacer la conmutación por error:

• Sobre el Tipo de almacenamiento debemos de hacer una aclaración, ya que vamos a usar un disco administrado (esta opción es nueva), esto no era posible usarlo antes, y teníamos que hacerlo con una cuenta de almacenamiento, de ahí que anteriormente nos creásemos esa cuenta, si usamos un discos administrados no hace falta crearnos la cuenta de almacenamiento:

• Sobre Selección de la máquina virtual, seleccionamos las máquinas que nos interesen:

• Sobre Configuración de replicación, seleccionamos el tipo de sistema operativo, el disco del sistema operativo, los discos a replicar, en este caso replicamos los dos discos que tiene la máquina virtual, le indicamos el tipo de disco administrado y la cuenta de almacenamiento en caché:

• En Directiva de replicación, seleccionamos la directiva que nos creamos anteriormente:

• En Revisar, nos muestra un resumen de todo lo configurado, damos a Habilitar replicación:

• Sobre el almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el proceso está en curso:

• Si clicamos sobre el proceso, en Información general, podemos ver el estado y una vista de la infraestructura de replicación:

• Si accedemos a nuestro servidor de Hyper-V, podemos ver que la réplica inicial está en proceso:

• Sobre el servidor de Hyper-V, y la máquina virtual a replicar > Replicación > Ver mantenimiento de la replicación, podemos ver, que la réplica se está realizando correctamente:

• Accedemos de nuevo a almacén de recovery services > Elementos protegidos > Elementos replicados, vemos que el Estado se encuentra esperando el primer punto de recuperación:

• Pasados unos minutos, podemos ver, que el Estado se encuentra en Protected, esto quiere decir que la réplica ya la tenemos hecha y que disponemos de puntos de recuperación, para levantar la máquina virtual en Azure:

• Si accedemos al elemento replicado, información general, Puntos de recuperación más recientes, vemos que ya nos muestra los últimos cinco puntos de recuperación:

• Sobre General > Propiedades, podemos ver, todas las propiedades del proceso de replicación configurado:

• Sobre General > Proceso y red, vemos las propiedades de la máquina virtual en Azure:

• Sobre General > Discos, vemos los discos que estamos replicando de la máquina virtual de Hyper-V:

• Si accedemos al grupo de recursos que nos configuramos anteriormente, podemos ver, los dos discos de réplica que se han creado:

• Con esto, ya tendríamos configuradas las réplicas desde un entorno on-premise con Hyper-V hacia un entorno cloud en Azure, en el próximo post veremos como realizar una conmutación por error de prueba, una conmutación por error planeada y una conmutación por error.

Saludos y espero que os sea de ayuda

En este post vamos a ver, cómo mover las máquinas virtuales de Hyper-V, en algunas ocasiones nos vamos a encontrar en el caso de que tengamos que mover nuestras máquinas virtuales de ubicación dentro del mismo servidor de Hyper-V, ya sea en el mismo disco en otro directorio, a otro disco porque en el que está se está quedando sin espacio por ejemplo, etc…, también tendremos la opción de mover la maquina a otro servidor distinto de Hyper-V, aquí vamos a mostrar la manera correcta de mover estas máquinas virtuales.

• Como podemos ver, tenemos esta máquina virtual y la tenemos ubicada en:

• Para mover de forma correcta la máquina virtual, damos clic derecho sobre la máquina y Mover:

• Se nos abrirá este asistente, que nos va a guiar en el proceso, sobre Antes de empezar nos muestra la información del proceso, clic en Siguiente:

• Sobre Elegir tipo de movimiento vamos a seleccionar Mover la máquina virtual, clic en Siguiente:

• Sobre Especificar destino, vamos a seleccionar otro hypervisor de nuestra infraestructura, clic en Siguiente:

• Sobre Elegir opciones de movimiento, vamos a seleccionar la primera opción, Mover los datos de la máquina virtual a una sola ubicación, clic en Siguiente:

• Sobre Máquina virtual, le indicamos la ubicación en el equipo de destino, clic en Siguiente:

• Sobre Resumen, nos muestra todo lo que hemos configurado, clic en Finalizar:

• Una vez finalizado el movimiento, si accedemos al hypervisor de destino, podemos ver ya la máquina virtual:

• Aquí vemos la estructura de carpetas que nos ha creado tras el movimiento:

Saludos y espero que os resulte de ayuda

En este post vamos a ver, cómo actualizar la versión de configuración en las máquinas virtuales de Hyper-V.

La versión de configuración de las máquinas virtuales en Hyper-V nos indica que configuraciones y funcionalidades están disponibles para nuestras máquinas virtuales, cuando Microsoft lanza actualizaciones importantes para sus sistemas operativos suele cambiar la versión de configuración, para poder aplicar estas nuevas funcionalidades.

• Como podemos ver tenemos cuatro máquinas virtuales en este servidor de Hyper-V, dos están en versión 9.0 y otras dos en versión 8.0:

• Vamos a cambiar la versión de configuración de las máquinas virtuales que están en versión 8.0 para que estén en la última versión 9.0, lo vamos a hacer de dos formas, una a través de la consola de Hyper-V y otra a través de PowerShell.
• Empezamos por cambiar la versión de configuración a través de la consola de Hyper-V, para ello, damos botón derecho sobre la máquina que queremos cambiar, y seleccionamos Actualizar versión de configuración:

• Nos indica, si estamos seguros del cambio, ya que este cambio implica que si queremos migrar esta máquina a otro servidor de Hyper-V con una versión de configuración inferior no va a ser posible, damos a Actualizar:

• Como podemos ver, ya la tenemos cambiada a versión 9.0:

• Ahora vamos a cambiar la versión de configuración a través de PowerShell, para ello, nos abrimos un PowerShell como Administrador:

• Y ejecutamos el siguiente cmdlet, Update-VMVersion nombreMV, nos indica si estamos seguros del cambio, ya que este cambio implica que si queremos migrar esta máquina a otro servidor de Hyper-V con una versión de configuración inferior no va a ser posible, le indicamos que Sí:

• Ahora si accedemos a la consola de Hyper-V, podemos ver, que ya la tenemos cambiada a versión 9.0:

• Si damos botón derecho sobre cualquiera de las máquinas, que están ya en versión 9.0, esta opción no está disponible en la máquina virtual, esto quiere decir que ya tiene la versión de configuración más alta compatible con el host de Hyper-V:

• Si ejecutamos el cmdlet, Get-VMHostSupportedVersion, podemos ver qué versiones de configuración de máquina virtual admite el host de Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo solucionar el error “La vinculación de un conmutador virtual a un equipo de LBFO está en desuso”, este error se produce cuando creamos un nuevo virtual switch con las interfaces de red en NIC Teaming.

• Aquí vemos el NIC Teaming realizado en el servidor, realizado con dos interfaces de red:

• Cuando intentamos crear el virtual switch con la interface de NIC Teaming, nos dará este error, indicándonos que la arquitectura LBFO está “deprecated” en desuso:

• Para solucionar este error, lo primero que debemos de hacer es eliminar el NIC Teaming:

• Como podemos ver, el NIC Teaming ya está deshabilitado, si en los ADAPTADORES E INTERFACES no nos aparece alguna interface de red, debemos de ir a las Conexiones de red y sobre las Propiedades de la interface, desmarcar el check Conmutador virtual extensible para Hyper-V:

• Una vez eliminado el NIC Teaming, para crearnos el conmutador virtual con dos interfaces y tener redundancia, nos abrimos un PowerShell con permisos de administrador y ejecutamos el comando New-VMSwitch -Name vSwitchLAN -NetAdapterName «LAN1″,»LAN2» -EnableEmbeddedTeaming $true como podemos ver, ya nos ha creado el Conmutador Virtual con dos NICs:

• Si accedemos a la consola de Hyper-V, podemos ver, que ya tenemos creado el Virtual Switch:

• Si accedemos a las conexiones de red, podemos ver, la interface virtual que se ha creado para este conmutador virtual, aquí es dónde se debe de configurar el protocolo TCP/IP:

Saludos y espero que os sea de ayuda

En este post vamos a ver como iniciar la conmutación por error en las réplicas de nuestras máquinas virtuales en caso de fallo crítico en uno de nuestros hypervisores de Hyper-V.

• Tenemos dos hipervisores de Hyper-V con la replicación habilitada en ambos sentidos:

• Vamos a suponer que nos falla el Servidor Principal, por ejemplo, por un fallo de RAM o CPU y no podemos levantar la máquina virtual, entonces nos debemos de ir al Servidor de Réplicas y habilitar la Conmutación por error:

• Le indicamos el punto de restauración que vamos a utilizar y pulsamos sobre Conmutación por error:

• Una vez aplicada la conmutación por error, podemos ver que la máquina se inicia sin problemas, crea un punto de control que eliminará cuando invirtamos la replicación y el estado de la replicación nos muestra que ha completado la conmutación por error:

• Ahora se supone que estamos trabajando sobre el Servidor principal para solucionar nuestros problemas con el hardware y una vez solucionado iniciamos nuestro hypervisor y nos encontramos la máquina en el siguiente estado, la máquina apagada y con errores en el estado de la replicación:

• Lo que vamos a realizar ahora será irnos al Servidor de réplicas e invertir la replicación, lo que conseguimos con este proceso es que todos los cambios que se han realizado en la máquina virtual durante la conmutación por error, se le van a pasar a la máquina que se encuentra en el servidor principal y una vez terminado el proceso los hypervisores van a intercambiar sus roles, es decir, el que era servidor de réplicas se va a convertir en el servidor principal y el principal pasará ahora a ser el de réplicas:

• Se nos abrirá, este asistente, clic en siguiente para continuar:

• Seleccionamos el servidor que va a pasar a ser el servidor de réplicas:

• Especificamos los parámetros de conexión, en este caso, los dos servidores de réplicas autentican por Kerberos ya que estas dos máquinas pertenecen al mismo dominio de Active Directory, si estuviésemos en un grupo de trabajo utilizando certificados, entonces seleccionamos la opción basada en certificados:

• Configuramos la frecuencia de la replicación:

• Le indicamos los puntos de control que queremos mantener:

• Sobre el método de replicación inicial, seleccionamos la opción que Use una máquina virtual existente en el servidor de réplicas como copia inicial:

• Nos muestra un resumen y finalizamos:

• Como podemos ver, comienza a enviar la réplica inicial y los servidores han intercambiado los roles:

• Una vez finalizada la replicación inicial, podemos ver que todo está correcto:

• Ahora si queremos dejar todo como estaba al principio, es decir, el servidor Hyperv03 como principal y el servidor Hyperv04 como réplicas, lo primero que tenemos que hacer es Apagar la máquina virtual en el servidor principal, en este caso, HyperV04:

• Y volvemos a repetir todo el proceso ya explicado de conmutación por error:

• Una vez finalizado, podemos ver que ya está todo como lo teníamos al principio:

Saludos y espero que os sea de ayuda

Hyper-V Réplicas es una opción del rol de Hyper-V para replicar máquinas virtuales de un Servidor a otro Servidor.

El principal uso que se le da es para la recuperación rápida ante desastres, como puede ser el fallo de un servidor, de forma que el sistema pueda volver a ponerse en funcionamiento de forma rápida en el entorno de respaldo.

No proporciona una solución de alta disponibilidad, dado que ante una caída de los servidores de producción:

• Se perderán los últimos datos almacenados, dependiendo de la frecuencia de replicación asíncrona y su duración
• La reactivación del sistema en los servidores de respaldo se realizará de forma manual por parte de un operador

Tampoco es una solución de backup, dado que no protege de corrupción de datos, fallos en actualizaciones, o errores humanos, que se distribuirán también a las réplicas.

CARACTERÍSTICAS

Las principales características de Hyper-V Replicas son:

• Replica asíncrona de máquinas virtuales entre servidores Hyper-V
  • Frecuencia programable
  • Soporta la exclusión de discos (VHDX)
  • Replica extendida (a un tercer nivel de respaldo)
  • Soporte de VSS para la consistencia de los datos de aplicaciones
  • Almacenamiento de múltiples puntos de recuperación
  • Varios mecanismos para la primera réplica
• Almacenamiento
  • No requiere almacenamiento compartido ni hardware especial
• Comunicaciones
  • Comunicación a nivel IP entre servidores
  • Se puede realizar réplicas a través de LAN o WAN
  • Permite el cifrado y compresión de las comunicaciones
• Requisitos Windows
  • Mínimo Windows server 2012 R2
  • No es necesario que los equipos estén dentro de un dominio o cluster, pero pueden formar parte de dominios distintos
  • Soporte de broker de réplica si se usa cluster

• Lo primero que vamos a realizar será empezar a preparar nuestras máquinas, esta parte de la preparación ya la hemos visto en un post anterior, por lo tanto, podemos seguir este enlace.
• Hemos preparado en ambos servidores.
• El rol de Hyper-V:

• NIC Teaming para la red LAN:

• Configuramos los conmutadores virtuales en ambas máquinas:

• Asignación de direccionamiento IP a la red LAN:

• Una vez que tenemos nuestros servidores preparados con las configuraciones iniciales, vamos a habilitar la siguiente regla en el firewall de Windows de ambos servidores de Hyper-V:

• Los dos equipos Hyper-V deberán tener un nombre DNS que se pueda resolver desde el otro servidor, y no debe cambiarse tras la generación de los certificados autofirmados, que los vamos a generar en un paso posterior, para ello, será necesario añadir en cada servidor su IP y su nombre completo; y los del otro servidor, mediante el fichero hosts ubicado en C:\Windows\System32\Drivers\etc\hosts:

• Una vez configurado confirmar que se pueden hacer ping el uno al otro usando el nombre:

• Como estamos trabajando en un entorno de trabajo en grupo, hay que configurar las credenciales de autenticación y certificados digitales.
• Para establecer las credenciales, desde la consola de sistema con privilegios de administrador, ejecutamos el comando siguiente, sustituyendo el nombre del servidor y el usuario por el que corresponda en cada caso.
• Para el servidor Hyperv01, cmdkey /add:hyperv02 /user:hyperv02\administrador /pass:mipassword

• Para el servidor Hyperv02, cmdkey /add:hyperv01 /user:hyperv01\administrador /pass:mipassword

• Ahora vamos a generar los certificados autofirmados para ambos servidores de Hyper-V.
• Lo primero que debemos hacer es obtener la herramienta makecert que viene incluida en «Windows Software Development Kit (SDK) for Windows 8», pero para facilitaros este tema y no tener que descargar el paquete completo y su posterior despliegue en un equipo, en este link os dejo el makecert.
• Nos creamos el directorio C:\PKI en ambos servidores e incluimos el ejecutable makecert que nos hemos descargado:

• En el primer servidor llamado hyperv01 vamos a lanzar una consola CMD como administrador y ejecutaremos los siguientes comandos:
  • cd C:\PKI
  • .\makecert -pe -n «CN=PrimaryRootCA» -ss root -sr LocalMachine -sky signature -r «PrimaryRootCA.cer»
  • .\makecert -pe -n «CN=hyperv01» -ss my -sr LocalMachine -sky exchange -eku «1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2» -in «PrimaryRootCA» -is root -ir LocalMachine -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 PrimaryCert.cer

• De igual forma, pero en el segundo servidor llamado hyperv02:
  • cd C:\PKI
  • .\makecert -pe -n «CN=ReplicaRootCA» -ss root -sr LocalMachine -sky signature -r «ReplicaRootCA.cer»
  • .\makecert -pe -n «CN=hyperv02» -ss my -sr LocalMachine -sky exchange -eku «1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2» -in «ReplicaRootCA» -is root -ir LocalMachine -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 ReplicaCert.cer

• Copiar desde el servidor hyperv02 al servidor hyperv01 el archivo «ReplicaRootCA.cer» ubicado en C:\PKI, copiarlo en la misma ruta:

• En el servidor hyperv01 ejecutamos el siguiente comando, certutil -addstore -f root ReplicaRootCA.cer:

• Copiar desde el servidor hyperv01 al servidor hyperv02 el archivo «PrimaryRootCA.cer» ubicado en C:\PKI, copiarlo en la misma ruta:

• En el servidor hyperv02 ejecutamos el siguiente comando, certutil -addstore -f root PrimaryRootCA.cer:

• Para terminar con el tema de los certificados autofirmados, en ambos servidores desactivamos la comprobación de certificados revocados, ejecutando, reg add «HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication» /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

• Ahora vamos a configurar nuestros servidores Hyper-V Replicas, en este caso, vamos a configurar los dos servidores con la función de Réplicas, así vamos a poder replicar nuestras máquinas virtuales en ambos sentidos, para ello editamos la configuración de Hyper-V:

• Sobre la configuración de Hyper-V en ambos servidores, nos vamos a la opción de Configuración de replicación Habilitado como servidor de réplicas, marcamos el check para habilitarlo y usamos Usar autenticación basada en certificados (HTTPS) sobre el puerto 10443, no utilizamos el puerto 443 ya que si tenemos otro servicio corriendo en este mismo puerto, como pudiera ser un IIS, las réplicas no se van a poder configurar, seleccionamos los certificados autofirmados que hemos generado anteriormente y permitimos la replicación desde cualquier servidor autenticado:

• Aquí nos indica que debemos tener configurado en el firewall de Windows la siguiente regla de entrada:

• Con esto ya tendríamos configurado nuestros dos servidores para replicar máquinas virtuales entre sí.
• Ahora vamos a ver como replicar las máquinas virtuales desde el servidor HYPERV01 al servidor HYPERV02, para ello, desde la consola de Hyper-V, damos clic derecho sobre la máquina que queremos replicar, y Habilitar replicación:

• Se nos abrirá este asistente, clic en siguiente para continuar:

• Especificamos el servidor de réplicas:

• Especificamos los parámetros de conexión:

• Seleccionamos los discos duros virtuales que vamos a replicar:

• Configuramos la frecuencia de la replicación:

• Configuramos el punto de recuperación más reciente:

• Elegimos el método de replicación inicial:

• Nos muestra un resumen y finalizamos:

• Sobre la pestaña replicación de la máquina virtual tenemos todos los datos del estado de la réplica:

• Aquí tenemos la máquina replicada en el servidor HYPERV02, la máquina virtual replicada no la podemos iniciar, pero si podemos exportarla y crear una nueva máquina:

• Sobre la máquina virtual replicada, si damos botón derecho Replicación, tenemos distintas opciones para trabajar con nuestras réplicas:

• Conmutación por error, nos indica que no debemos de realizar esta tarea a menos que se produzca un error en la máquina virtual principal, si realizamos una conmutación por error planeada, debemos cancelar y usar la tarea de conmutación por error planeada en la máquina virtual principal, y si no es planeada, porque ya tengamos la máquina virtual principal averiada, podemos proseguir con el proceso.

• Conmutación por error planeada, esta opción sólo está disponible en el servidor que alberga la máquina virtual principal, y debe estar apagada, esta opción va a iniciar la réplica en el otro servidor, si marcamos el check Invertir la dirección de la replicación después de la conmutación por error, todos los cambios realizados en la máquina de réplicas se van a replicar a la máquina principal:

• Probar conmutación por error, nos va a crear una nueva máquina virtual a partir de la réplica que tenemos realizada y así podemos verificar que la réplica es correcta:

• Pausar replicación, podemos para momentáneamente la réplica.
• Extender replicación, podemos replicar la réplica en otro servidor de réplicas:

• Ver mantenimiento de la replicación, podemos ver las estadísticas y estado de la réplica:

• Quitar replicación, le indicamos que esta réplica se va a convertir en una máquina principal y se eliminará la replicación desde la máquina original o principal.

Saludos y espero que os sea de ayuda

En este post vamos a ver como iniciar y apagar nuestras máquinas virtuales a través de PowerShell.

• Aquí vemos sobre la consola de Hyper-V, que tenemos las dos máquinas virtuales apagadas:

• Y con el cmdlet Get-VM también podemos ver el estado de nuestras máquinas virtuales:

• Nos abrimos un PowerShell con permisos de Administrador y ejecutamos el siguiente cmdlet para iniciar las máquinas virtuales, Start-VM -VMName maquinavirtual:

• Si volvemos a hacer un Get-VM podemos ver en el estado que están corriendo:

• Ahora para detener nuestras máquinas virtuales ejecutamos el siguiente cmdlet, Stop-VM -VMName maquinavirtual:

• Si volvemos a hacer un Get-VM podemos ver en el estado que están apagadas:

• Ahora para reiniciar nuestras máquinas virtuales ejecutamos el siguiente cmdlet, Restart-VM -VMName maquinavirtual:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como instalar y configurar Veeam Agent Windows para un Failover Cluster de Microsoft.

• Lo primero que vamos a realizar será crearnos un Grupo de protección, dónde añadiremos el Failover Cluster de Microsoft, para ello nos vamos a INVENTORY > Physical & Cloud Infraestructure > Create Protection Group:

• Se nos abre el siguiente asistente, dónde le indicamos un nombre y una descripción:

• Ahora seleccionamos como queremos descubrir los equipos, en mi caso lo haré a través del Active Directory:

• Especificamos uno de los controladores de dominio de nuestra infraestructura, con unas credenciales válidas, que ya teníamos registrada en la consola de VB&R:

• Ahora pulsamos sobre añadir y seleccionamos el Failover Cluster de Microsoft:

• El asistente nos permite excluir del grupo de protección, todas las máquinas virtuales, todos los equipos que lleven apagados más de 30 días, e incluso los equipos que nosotros le indiquemos:

• Como credenciales de los equipos usamos el master account, si realizamos un Test Now, podemos ver si las credenciales son válidas:

• Podemos configurar un discover programado y realizar algunas tareas como, instalar el agente automáticamente, actualizar el agente, instalar el nuevo driver CBT de Veeam, reiniciar el equipo:

• Ahora nos muestra los servicios y componentes que tiene que instalar en el servidor de VB&R:

• Como podemos ver los componentes para Veeam Agent Management se han instalado correctamente en nuestro servidor de VB&R:

• Para terminar clic sobre “Finish”:

• Al terminar nos muestra todas las operaciones realizadas sobre los dos nodos del Failover Cluster, y como podemos ver ha instalado el Veeam Agent for Windows y el driver CBT, tal y como le hemos indicado en la configuración, el error es debido a que debemos de reiniciar ambos nodos tras la instalación del driver CBT:

• Una vez que hemos reiniciado ambos nodos del Failover Cluster, ya tendremos los dos servidores con Veeam Agent Windows instalado, usando el nuevo driver CBT de Veeam y agregado a la consola de VB&R, desde dónde podremos administrar y gestionar todo:

• Una vez creado el Protection Group para el Failover Cluster y los Veeam Agents se han instalado sobre los nodos, ya podemos crear el backup job del Failover Cluster de Microsoft, para ello nos vamos al HOME > Backup Job > Windows computer:

• Se nos abre el siguiente asistente, y sobre el Job Mode, seleccionamos la opción de Failover Cluster:

• Introducimos un nombre y una descripción para la tarea:

• Agregamos el Failover Cluster de Microsoft que incluirá los dos nodos de Hyper-V:

• Le indicamos que queremos proteger los equipos completos, también tenemos otras opciones como elegir una unidad de disco o carpetas y ficheros individuales:

• Elegimos el repositorio de Veeam que nos interese, los puntos de restauración y sobre avanzadas le indicamos que nos haga una copia completa periódicamente (cada sábado), para no depender de una sola copia completa, que se nos puede hacer muy antigua con el paso del tiempo, como el repositorio dónde va a ir el backup es local, seleccionamos la opción Local target:

• Estas opciones las dejamos desmarcadas, en su día, ya quedaron explicadas, si queréis podéis echarle un vistazo aquí:

• Configuramos la programación de la tarea:

• Nos muestra un resumen de las opciones configuradas, clic en finalizar:

• Como podemos ver, ya tenemos la tarea de backup configurada y lista para empezar con las copias de seguridad de las máquinas físicas pertenecientes al Failover Cluster de Microsoft:

• Como podemos ver, desde el Protection Group, se puede crear el Recovery Media para nuestras máquinas físicas, en caso de que necesitemos restaurar la máquina completa en caso de desastre mayor:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como agregar un Failover Cluster de Hyper-V a nuestra infraestructura de backup con Veeam Backup & Replication 10.

• Lo primero que vamos a realizar será irnos hasta INVENTORY > Virtual Infraestructure > ADD SERVER:

• Como podemos ver estas son todas las opciones que soporta Veeam Backup and Replication 9.5 Update 4b:
• VMware vSphere: Suite de virtualización de VMware, podemos añadir servidores vCenter o servidores ESXi de forma individual.
• Microsoft Hyper-V: Suite de virtualización de Microsoft, podemos añadir clústers de servidores Hyper-V o servidores independientes.
• NDMP Server: permite añadir dispositivos de almacenamiento integrado como pueden ser las cabinas NetApp y EMC.
• Protection Group: Se trata de un grupo dónde podemos añadir nuestros servidores físicos, tanto Windows como Linux, para poder desplegarles los Veeam Agents que serán los encargados de realizar los backups de estos servidores, a través de estos Protection Group podemos gestionar los backups y restore de nuestras máquinas físicas Windows y Linux.

• En nuestro caso escogemos Microsoft Hyper-V:

• Le indicamos el nombre DNS o la dirección IP de nuestro Failover Cluster de Microsoft, con una descripción:

• En tipo, marcamos el check Microsoft Hyper-V cluster:

• Introducimos las credenciales con permisos administrativos sobre el Failover Cluster de Microsoft:

• Nos indica que se van a agregar los dos hosts de Hyper-V que tiene configurado el Failover Cluster:

• Como podemos ver se han agregado correctamente:

• Nos muestra un resumen y finalizamos:

• Aquí vemos que ya tenemos correctamente agregado nuestro Windows Failover Cluster con sus nodos de Hyper-V y todas sus máquinas virtuales:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar el almacenamiento de nuestras máquinas virtuales de un disco a otro en nuestro failover cluster.

• Para ello nos abrimos la consola de Administrador de clústeres de conmutación por error, y damos botón derecho sobre la máquina virtual que queremos migrar, sobre las opciones elegimos Mover > Almacenamiento de máquina virtual:

• Se nos va a abrir la pantalla para las opciones de migración, aquí lo podemos hacer de varias maneras, podemos ir arrastrando uno a uno con el ratón todas las opciones (.vhdx, Puntos de control, Paginación inteligente y Configuración actual), podemos arrastrar la máquina completa, en nuestro caso, sólo queremos mover de CSV (Cluster Storage Volume) el disco duro virtual (.vhdx) de nuestra máquina virtual, para ello, seleccionamos el CSV al que lo queremos mover (Volume1) ya que se encuentra en el CSV – Volume2, y arrastramos el disco duro virtual hacia abajo:

• Una vez arrastrado a su ubicación, damos a iniciar:

• Como podemos ver comienza a migrar el disco duro virtual de CSV y no perdemos servicio en nuestra máquina virtual:

• Como vemos en la configuración de la máquina virtual el disco duro .vhdx ha sido migrado correctamente al CSV – Volume1:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como migrar las máquinas virtuales de un nodo a otro en nuestro failover cluster.

• Para ello nos abrimos la consola de Administrador de clústeres de conmutación por error, y damos botón derecho sobre la máquina virtual que queremos migrar, sobre las opciones elegimos Mover > Migración en vivo:

• Seleccionar nodo:

• Seleccionamos el nodo y aceptamos:

• Como podemos ver comienza a migrar la máquina virtual al nodo que le hemos indicado:

• Aquí tenemos ya nuestra máquina migrada de nodo:

Saludos y espero que os sea de ayuda

Hyper-V Réplicas es una opción del rol de Hyper-V para replicar máquinas virtuales de un Servidor a otro Servidor.

El principal uso que se le da es para la recuperación rápida ante desastres, como puede ser el fallo de un servidor, de forma que el sistema pueda volver a ponerse en funcionamiento de forma rápida en el entorno de respaldo.

No proporciona una solución de alta disponibilidad, dado que ante una caída de los servidores de producción:

• Se perderán los últimos datos almacenados, dependiendo de la frecuencia de replicación asíncrona y su duración
• La reactivación del sistema en los servidores de respaldo se realizará de forma manual por parte de un operador

Tampoco es una solución de backup, dado que no protege de corrupción de datos, fallos en actualizaciones, o errores humanos, que se distribuirán también a las réplicas.

CARACTERÍSTICAS

Las principales características de Hyper-V Replicas son:

• Replica asíncrona de máquinas virtuales entre servidores Hyper-V
  • Frecuencia programable
  • Soporta la exclusión de discos (VHDX)
  • Replica extendida (a un tercer nivel de respaldo)
  • Soporte de VSS para la consistencia de los datos de aplicaciones
  • Almacenamiento de múltiples puntos de recuperación
  • Varios mecanismos para la primera réplica
• Almacenamiento
  • No requiere almacenamiento compartido ni hardware especial
• Comunicaciones
  • Comunicación a nivel IP entre servidores
  • Se puede realizar réplicas a través de LAN o WAN
  • Permite el cifrado y compresión de las comunicaciones
• Requisitos Windows
  • Mínimo Windows server 2012 R2
  • No es necesario que los equipos estén dentro de un dominio o cluster, pero pueden formar parte de dominios distintos
  • Soporte de broker de réplica si se usa cluster

TOPOLOGÍA

• Lo primero que vamos a realizar será empezar a preparar nuestras máquinas, esta parte de la preparación ya la hemos visto en un post anterior, por lo tanto, podemos seguir este enlace.
• Hemos preparado en ambos servidores.
• El rol de Hyper-V:

• NIC Teaming para la red LAN:

• Configuramos los conmutadores virtuales en ambas máquinas:

• Asignación de direccionamiento IP a la red LAN:

• Unimos las dos máquinas a nuestro dominio de Active Directory:

• Una vez que tenemos nuestros servidores preparados con las configuraciones iniciales, vamos a configurar nuestros servidores Hyper-V Replicas, en este caso, vamos a configurar los dos servidores con la función de Réplicas, así vamos a poder replicar nuestras máquinas virtuales en ambos sentidos, para ello editamos la configuración de Hyper-V:

• Sobre la configuración de Hyper-V, nos vamos a la opción de Configuración de replicación Habilitado como servidor de réplicas, marcamos el check para habilitarlo y usamos el protocolo de autenticación de red Kerberos sobre HTTP puerto 80, utilizamos Kerberos ya que estos dos servidores están unidos a un dominio de Active Directory, los datos enviados a través de la red no se cifrarán, si estuviésemos trabajando sobre un entorno de Grupo de trabajo, la única forma de poder replicar las máquinas, es usando la autenticación basada en certificados HTTPS puerto 443, dónde los datos enviados a través de la red se cifrarán:

• También debemos agregar el servidor o los servidores autorizados para enviar las réplicas de las máquinas virtuales:

• Aplicamos y Aceptamos los cambios:

• Aquí nos indica que debemos tener configurado en el firewall de Windows la siguiente regla de entrada:

• Configuramos el firewall de nuestros servidores de Hyper-V, con las reglas que nos ha indicado la advertencia al habilitar el servidor de réplicas:

• Con esto ya tendríamos configurado nuestros dos servidores para replicar máquinas virtuales entre sí.
• Desde el servidor HYPERV03, vamos a ejecutar este comando Test-VMReplicationConnection Hyperv04 80 Kerberos para verificar que podemos enviar réplicas al servidor HYPERV04:

• Desde el servidor HYPERV04, vamos a ejecutar este comando Test-VMReplicationConnection Hyperv03 80 Kerberos para verificar que podemos enviar réplicas al servidor HYPERV03:

• Ahora vamos a ver como replicar las máquinas virtuales desde el servidor HYPERV03 al servidor HYPERV04, para ello, desde la consola de Hyper-V, damos clic derecho sobre la máquina que queremos replicar, y Habilitar replicación:

• Se nos abrirá este asistente, clic en siguiente para continuar:

• Especificamos el servidor de réplicas:

• Especificamos los parámetros de conexión:

• Seleccionamos los discos duros virtuales que vamos a replicar:

• Configuramos la frecuencia de la replicación:

• Configuramos el punto de recuperación más reciente:

• Elegimos el método de replicación inicial:

• Nos muestra un resumen y finalizamos:

• Aquí podemos ver cómo está enviando la réplica y el porcentaje del trabajo:

• Sobre la pestaña replicación de la máquina virtual tenemos todos los datos del estado de la réplica:

• Aquí tenemos la máquina replicada en el servidor HYPERV04, la máquina virtual replicada no la podemos iniciar, pero si podemos exportarla y crear una nueva máquina:

• Sobre la máquina virtual replicada, si damos botón derecho Replicación, tenemos distintas opciones para trabajar con nuestras réplicas:

• Conmutación por error, nos indica que no debemos de realizar esta tarea a menos que se produzca un error en la máquina virtual principal, si realizamos una conmutación por error planeada, debemos cancelar y usar la tarea de conmutación por error planeada en la máquina virtual principal, y si no es planeada, porque ya tengamos la máquina virtual principal averiada, podemos proseguir con el proceso.

• Conmutación por error planeada, esta opción sólo está disponible en el servidor que alberga la máquina virtual principal, y debe estar apagada, esta opción va a iniciar la réplica en el otro servidor, si marcamos el check Invertir la dirección de la replicación después de la conmutación por error, todos los cambios realizados en la máquina de réplicas se van a replicar a la máquina principal:

• Probar conmutación por error, nos va a crear una nueva máquina virtual a partir de la réplica que tenemos realizada y así podemos verificar que la réplica es correcta:

• Pausar replicación, podemos parar momentáneamente la réplica.
• Extender replicación, podemos replicar la réplica en otro servidor de réplicas:

• Ver mantenimiento de la replicación, podemos ver las estadísticas y estado de la réplica:

• Quitar replicación, le indicamos que esta réplica se va a convertir en una máquina principal y se eliminará la replicación desde la máquina original o principal.

Saludos y espero que os sea de ayuda

En este post vamos a ver como asignar nombres a las interfaces de red en las máquinas virtuales de Hyper-V.

• Como podemos ver en la configuración de esta máquina virtual, nuestro host de Hyper-V le asigna por defecto el mismo nombre a todas las interfaces de red, los llama Adaptador de red, en infraestructuras grandes con muchas subredes y VLANs, podemos tener esta configuración mucho más ordenada asignándole un nombre descriptivo a cada interface de red, así sabremos a que red se está conectando cada máquina virtual:

• Para realizar esta configuración nos abrimos un PowerShell con permisos de Administrador y ejecutamos el siguiente comando, Add-VMNetworkAdapter -VMName “UBUNTU1804” -Name “DMZ” -DeviceNaming On:

• Si editamos la configuración de la máquina virtual, podemos ver que se ha creado una nueva interface de red llamada DMZ, esta nueva interface de red aparece en modo No conectado:

• Ahora le asignamos el conmutador virtual que nos interese:

• Ahora si ejecutamos el siguiente comando Add-VMNetworkAdapter -VMName “UBUNTU1804” -SwitchName “vSwitchPriv0” -Name «DMZ» -DeviceNaming On, también le podemos indicar a que conmutador virtual se va a conectar este nuevo adaptador de red:

• Si editamos la configuración de la máquina virtual, podemos ver que se ha creado una nueva interface de red llamada DMZ, esta nueva interface de red aparece conectada al conmutador virtual que le hemos indicado:

Saludos y espero que os sea de ayuda

En este post vamos a ver como configurar NAT en un conmutador virtual de Hyper-V para compartir la conexión a Internet en nuestras máquinas virtuales.

• Antes de empezar a configurar NAT, vamos a ver a través de que conmutador virtual vamos a compartir la conexión a Internet para nuestras máquinas virtuales a través de este NAT.
• En nuestro host de Hyper-V tenemos dos conmutadores virtuales, uno de ellos llamado vSwitchLAN configurado como Red externa a través del cuál el host de Hyper-V sale a Internet por una de las NIC físicas que tiene:

• Aquí podemos ver el direccionamiento IP que tiene el host de Hyper-V a través del vSwitchLAN (Red externa):

• El otro conmutador virtual llamado vSwitchIntNAT está configurado como Red interna, pues a través de éste vamos a compartir la conexión a Internet para nuestras máquinas virtuales, realizándole un NAT a través de PowerShell:

• Aquí podemos ver el direccionamiento IP que tiene el host de Hyper-V a través del vSwitchIntNAT (Red interna), esta será la puerta de enlace para nuestras máquinas virtuales, ya que a través de esta conexión vamos a dar salida a Internet:

• Una vez que tenemos configurado los conmutadores virtuales nos vamos a abrir un PowerShell como administrador y vamos a introducir el siguiente comando para crear el NAT en el conmutador virtual vSwitchIntNAT, New-NetNat -Name “IntNAT” -InternalIPInterfaceAddressPrefix 192.168.100.0/24:

• Con el comando Get-NetNat vamos a poder ver todos los NAT que tenemos configurado en nuestro Hyper-V:

• Con el comando Remove-NetNat -Name “IntNAT” podemos eliminar los NAT que tengamos configurado en nuestro Hyper-V:

• Ahora en nuestras máquinas virtuales vamos a agregarle el conmutador virtual que hemos configurado como NAT para darle salida a Internet:

• Configuramos el direccionamiento IP en la máquina virtual, y como gateway debemos de configurar la dirección IP que tiene nuestro host de Hyper-V en la conexión de red interna (vSwitchIntNAT):

• Como podemos ver ya tenemos salida a Internet para la máquina virtual a través del NAT que hemos configurado en el conmutador virtual interno de nuestro Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como combinar y compactar los discos virtuales de nuestras máquinas de Hyper-V, como ya vimos en un post anterior, al realizar puntos de control o snapshot sobre las máquinas, nos crea un fichero con extensión .avhdx, es lo que se llama disco de diferenciación, y a partir de ese momento en el que se crea es dónde se van a ir guardando todas las modificaciones que le realicemos a nuestra máquina, muchas veces al eliminar los puntos de control no se combinan los discos .avhdx con los primarios .avhdx (si hay más de un punto de control) o .vhdx (si solo hay un punto de control), entonces debemos de editar estos discos para combinarlos y una vez combinados procedemos a compactarlos, para combinar los discos la máquina puede estar encendida, pero para compactar debe de estar apagada.

• Aquí podemos ver los discos que queremos combinar:

• Ahora debemos de tener muy en cuenta (IMPORTANTE) cuál es el disco de diferenciación más actual, es decir, el que está utilizando la máquina actualmente y a partir de este averiguar cuáles son sus primarios, para ello, nos vamos a ir a la configuración de la máquina, seleccionamos la unidad de disco que queremos combinar y damos clic a Inspeccionar:

• Una vez que sabemos el orden para combinarlos, procedemos a editar los discos:

• Se nos abre este asistente, clic en siguiente:

• Localizamos el primer disco de diferenciación, este disco es el que la máquina está utilizando actualmente:

• Elegimos la acción de combinar:

• Le indicamos que queremos combinarlo con el primario:

• Nos muestra un resumen y finalizamos:

• Aquí podemos ver como ya se ha combinado:

• Ahora vamos a combinar el disco de diferenciación .avhdx que nos ha quedado con el disco primario .vhdx, para ello, volvemos a Editar disco:

• Se nos abre este asistente, clic en siguiente:

• Localizamos el primer disco de diferenciación, este disco es el que la máquina está utilizando actualmente:

• Elegimos la acción de combinar:

• Le indicamos que queremos combinarlo con el primario:

• Nos muestra un resumen y finalizamos:

• Aquí podemos ver como ya se ha combinado:

• Ahora debemos abrir la configuración de la máquina virtual y asignarle el disco que hemos combinado:

• Una vez combinados los discos, procedemos a compactar el disco resultante, para ello, volvemos a Editar disco, para compactar el disco la máquina virtual debe de estar apagada:

• Se nos abre el asistente:

• Localizamos el disco que queremos compactar:

• Elegimos la acción de compactarlo:

• Nos muestra un resumen y finalizamos:

Saludos y espero que os sea de ayuda

En este post vamos a ver como se trabaja y se administran los puntos de control en las máquinas virtuales de Hyper-V, los puntos de control o snapshot nos sirven para guardar el estado de nuestras máquinas virtuales en un momento determinado, uno de los casos más típicos dónde los podemos utilizar, es cuando realizamos alguna configuración importante a nuestras máquinas virtuales y no estamos seguro si esa configuración nos va a venir bien, entonces realizamos un punto de control antes de realizar estas configuraciones, si una vez que hemos realizado las configuraciones, no nos ha ido bien, siempre podemos volver al estado que guardamos en el punto de control, algo a tener en cuenta y muy importante, los puntos de control o snapshot, no son backups.

• Para empezar, vamos a ver como se crea un punto de control, nos situamos sobre la máquina, clic derecho y punto de control:

• Como podemos ver ya tenemos creado el punto de control:

• Ahora si nos vamos a la ruta dónde tenemos ubicado el disco duro virtual (.vhdx) de la máquina a la que le hemos realizado el punto de control, podemos ver que nos ha creado un fichero con extensión .avhdx, a partir de este momento, es en este fichero o disco virtual dónde se van a ir guardando todas las modificaciones que le realicemos a nuestra máquina:

• Si editamos la configuración de la máquina virtual, podemos ver que el disco duro virtual se ha cambiado a .avhdx:

• Para eliminar un punto de control, simplemente nos situamos sobre el punto de control, clic derecho y Eliminar punto de control:

• Como podemos ver, ya no tenemos ningún punto de control:

• Ahora si nos vamos a la ruta dónde tenemos ubicado el disco duro virtual (.vhdx) de la máquina a la que le hemos eliminado el punto de control, podemos ver que el fichero .avhdx o disco duro virtual de diferenciación ha desaparecido, ¿Qué operación se ha realizado aquí?, lo que ha hecho nuestro Hyper-V es combinar los dos discos virtuales o ficheros en uno sólo, y dejarlo con extensión de disco duro virtual .vhdx:

• Podemos cambiar el nombre a los puntos de control de las máquinas virtuales, y poder darle así un nombre descriptivo del estado de la máquina virtual en ese momento:

• Si aplicamos el punto de control, volvemos al estado en el que se encontraba la máquina en ese mismo instante:

• También podemos ver la configuración que tenía la máquina virtual cuando realizamos el punto de control:

• Aquí tenemos una de las opciones más interesantes de los puntos de control o snapshots en Hyper-V, y es que podemos exportar estos puntos de control como máquinas virtuales y desplegarlas en otros hosts:

• Le indicamos la ubicación y exportamos:

• Aquí podemos ver la máquina virtual exportada desde el estado en el que se encontraba en el punto de control, lista para ser importada en otro host de Hyper-V:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como se exportan e importan las máquinas virtuales en Hyper-V.

• Desde la consola de Administrador de Hyper-V, nos situamos sobre la máquina virtual y con un clic derecho de ratón elegimos la opción de Exportar:

• Le indicamos la ubicación dónde vamos a guardar la máquina exportada:

• Damos clic sobre Exportar:

• Aquí podemos ver el progreso de la exportación:

• Una vez terminada la operación aquí podemos ver la máquina exportada:

• Ahora vamos a ver como se importa una máquina virtual a otro host de Hyper-V, para ello, desde la consola Administrador de Hyper-V del host nos vamos a ir a la acción Importar máquina virtual…

• Se nos va a abrir este asistente, clic sobre siguiente:

• Seleccionamos la carpeta de la máquina virtual que hemos exportado anteriormente:

• Seleccionamos la máquina virtual que queremos importar:

• Ahora debemos de elegir el tipo de importación, aquí nos vamos a encontrar con estas tres opciones, con respecto a las dos primeras “usar el identificador único existente” el SID (Secure Identifier) de la máquina no va a cambiar, con respecto a la tercera opción “crear un identificador único nuevo” se le va a asignar a la máquina un SID (Secure Identifier) nuevo, según el entorno dónde vayamos a importar la máquina nos va a interesar marcar uno u otro, en este caso vamos a elegir la tercera opción, este SID es asignado al equipo durante el proceso de instalación del sistema operativo y debe ser un identificador único para cada equipo, este SID es muy importante sobre todo en entornos de Active Directory, ya que si todas las máquinas importadas tienen el mismo SID , nuestro Active Directory no va a distinguir entre las distintas máquinas ya que el SID es el mismo para todos los equipos, podemos tener problemas por ejemplo, al añadir un equipo al dominio, ya que el sistema nos va a indicar que ese equipo ya se ha unido, podemos tener problemas si tenemos implementado un servidor WSUS en nuestra infraestructura, ya que en la consola de administración de WSUS sólo va a reconocer un equipo, es decir, de todos los que tengan el mismo SID, sólo va a mostrar el último equipo que haya solicitado descargar actualizaciones, estos son algunos de los casos que yo me he encontrado, pero seguramente que con el paso del tiempo podemos ver cosas raras en nuestros sistemas si no asignamos nuevos SID a nuestras máquinas, por eso recomendamos usar esta última opción, Copiar la máquina virtual (crear un identificador único nuevo):

• Elegimos los destinos dónde vamos a importar los archivos de configuración de la máquina virtual:

• Elegimos el destino dónde se van a importar los discos duros virtuales (vhdx) de la máquina virtual:

• Nos muestra un resumen con las opciones que hemos configurado durante la importación, clic en Finalizar:

• Comienza a copiar los archivos:

• Como podemos ver ya tenemos la máquina importada, lista para funcionar:

Saludos y espero que os sea de ayuda