Virtualización anidada con Windows Server 2016 y Windows 10 + Hyper-V sobre Hyper-V en Windows Server 2012 R2

Virtualización anidada con Windows Server 2016 y Windows 10 + Hyper-V sobre Hyper-V en Windows Server 2012 R2 

En este video realizo unas pequeñas demostraciones de cómo activar y usar la virtualización anidada en WS2016 y cómo activar el Hyper-V sobre Hyper-V en WS2012R2.

Video:

Virtualización anidada con Windows Server 2016  + Hyper-V sobre Hyper-V en Windows Server 2012 R2

Video:

Virtualización anidada con Windows Server 2016 + nested en Windows 10 1607

 

Requisitos necesarios para poder usar esta nueva función:

  • Memoria dinámica debe ser desactivada en la máquina virtual que contiene la instancia anidada de Hyper-V
  • La máquina virtual debe tener al menos 2 vCPU
  • La opción de MAC Address Spoofing debe estar habilitada en la tarjeta de red asignada a la máquina virtual.

Las extensiones de virtualización necesita ser habilitada a la máquina virtual como se ve a continuación:

Get-VM

Get-VMProcessor -VMName <nombre de VM> | FL *

Set-VMProcessor -VMName <nombre de VM> -ExposeVirtualizationExtensions $true

Para usar esta opción se necesita TP4 o superior.

Algunas funciones no funcionarán por el momento, recordemos que la versión de Windows Server 2016 aún se encuentra en TP:

  • Live Memory Resize will not work (6)
  • Checkpoints will not work
  • Live Migration does not work
  • Save/Restore will not work
  • Does not work on AMD chips currently.
  • Other Hypervisors will not work

Algunas novedades en Windows Server 2016

  1. VM compute resiliency:

Proporciona resistencia a fallos transitorios como por ejemplo fallos de red o un nodo de un Cluster que no responde.

En el caso de que se produzca el aislamiento de un nodo del Cluster, las máquinas virtuales seguirán funcionando temporalmente incluso si el nodo es apartado del Cluster.

El tiempo por defecto está configurado a 4 minutos, pero es ajustable por el administrador.

  1. VM storage resiliency:

Preserva el estado de la sesión del cliente o “tennant” en el caso de perder conectividad con el sistema de almacenamiento. La máquina virtual queda configurada de inmediato a un estado “Paused Critical”.

La máquina virtual es notificada de inmediato de que no puede acceder al disco duro virtual debido a un fallo en una dependencia como por ejemplo conexión con el sistema de almacenamiento.

Aunque el equipo esta “ejecución” (pero en pausa), no es posible conectar a él. Cuando se restablece la conexión con el sistema de almacenamiento, el equipo automáticamente regresa al estado de ejecución normal.

  1. Node Quarantine:

Imaginemos el caso en el que un nodo está siendo apartado del Cluster repetidamente. Podemos suponer que dicho nodo puede tener un problema de hardware, de conectividad, etc… por lo que podemos inferir que no presenta un estado adecuado para operar correctamente. Diremos que dicho nodo es “Unhealthy”.

Los nodos calificados como “Unhealthy” son puestos en cuarentena y no se les permite volver a unirse al Cluster, evitando que afecten al Cluster negativamente.

Un nodo será puesto en estado de cuarentena si abandona el Cluster inesperadamente tres veces en una hora. Una vez el nodo ha sido declarado en cuarentena, las máquinas virtuales son migradas mediante el proceso de “live migration” a otros nodos sin ningún tipo de “downtime”, a diferencia de los casos anteriores.

  1. Guest Cluster:

Por lo que respecta a un “guest cluster”, existe un nuevo tipo de disco duro virtual llamado Shared Drive (shared vhdx) con el que no hay necesidad de presentar la capa de almacenamiento física al sistema operativo de la máquina virtual.

Además, este tipo de disco puede ser redimensionado online.

Puede ser presentado simultáneamente a varias máquinas virtuales, como almacenamiento compartido.

Otra importante novedad de este tipo de disco es que soporta Hyper-V Replica y Host-Level Backup, esto último era algo que no estaba disponible en ninguna versión anterior.

  1. Hyper-V Replica:

En el caso de Hyper-V Replica, se soporta añadir discos duros virtuales VHDX en caliente. Cuando se añade un nuevo disco duro virtual a un equipo que está siendo replicado mediante Hyper-V Replica, se añade al “conjunto de discos no replicados”, una nueva área en donde podemos ver que discos de una máquina virtual estan siendo replicados.

Podremos añadirlo al conjunto de discos replicados mediante PowerShell.

  1. Administración de Memoria:

En cuanto a la memoria, partimos de la memoria estática que es la se asigna a una máquina virtual independientemente de si la va a consumir o no.

Ahora tenemos la nueva característica “Runtime Resize” que permite incrementar o disminuir la memoria de una máquina virtual sin “downtime”.

No puede ser disminuida por debajo de la demanda actual que tenga la máquina virtual ni obviamente por encima de la memoria física del sistema.

  1. Mejoras en los adaptadores de red virtuales:

Hot Add/Remove de adaptadores virtuales a un equipo virtual sin “downtime”. Esta característica está habilitada por defecto en los equipos de Generación 2 y dicha operación puede realizarse a través el entorno gráfico o mediante comandos de PowerShell.

Cualquier sistema operativo invitado soportado ya sea Windows o Linux puede beneficiarse de esta mejora.

Dentro de estas novedades de Hyper-V se incluye una nueva capacidad denominada “vNIC identification” permite nombrar a un adaptador de red virtual en las propiedades de la máquina virtual y ver dicho nombre desde el interior de dicha máquina virtual. Esto permite acabar con la molestia de tener que relacionar por ejemplo las tarjetas de red virtuales con las físicas. Cuando tenemos un equipo virtual con cuatro tarjetas virtuales no tenemos que ir comprobando dónde están conectadas físicamente.

  1. Actualizaciones de Cluster (Cluster con nodos ejecutando distintos sistemas Operativos):

Con la nueva versión podremos actualizar un Cluster Windows Server 2012 R2 nodo a nodo sin “downtime” para los equipos virtuales, incluso en un SOFS (Scale-Out File Server).

Los pasos generales son los siguientes:

Un nodo del Cluster se pone en pausa y se vacía (evict) de máquinas virtuales trasladándolas otro nodo mediante “Live Migration” u otro mecanismo.

El nodo es separado del Cluster, se actualiza el Sistema Operativo con una instalación “limpia” de Windows Server 2016.

El nodo actualizado es re-unido al Cluster como nodo activo. En este punto el Cluster funcionará en un “modo mixto” (2012-2016). El proceso se repite para los demás nodos.

Debemos recordar que esto no era posible en versiones anteriores, donde todos los nodos de un Cluster debían ejecutar la misma versión de Sistema Operativo. En el pasado debíamos crear un nuevo Cluster y mover las máquinas virtuales entre el Cluster antiguo y el nuevo.

El nivel funcional del Cluster se mantiene en Windows Server 2012 R2 hasta que todos los nodos han sido migrados. Finalmente, y a conveniencia del administrador, mediante un comando de PowerShell se actualiza el nivel funcional del Cluster a 2016, lo que permitirá aprovechar nuevas funcionalidades.

Una vez elevado el nivel funcional del Cluster, ya no se soportarán nodos con distintos sistemas operativos en el mismo.

En el proceso de mover una máquina virtual desde un nodo Windows Server 2012 R2 a un nodo Windows Server 2016 debemos actualizar la configuración de la máquina virtual para que pueda aprovechar nuevas características como vTPM, actualización de vNICs, etc… se produce un cambio en la configuración, que pasa de un archivo en formato XML a formato BIN.

Todo el proceso de actualización de un Cluster puede automatizarse por supuesto con PowerShell pero también desde SCVMM 2016 (System Center Virtual Machine Manager), dado que ya está preparado para entender este “modo mixto” y el proceso de actualización de un Cluster nodo a nodo. Para ell deberemos tener en la VMM Library un Host Profile para desplegar un equipo Host de cero.

  1. Production CheckPoints:

Permiten usar el servicio VSS (Volume Snapshot Service) del sistema operativo de la máquina virtual para crear “Production Checkpoints”, en lugar de CheckPoints tradicionales basados en “Saved State”.

Los Production Checkpoints no incluyen un estado “Saved State”. Esto quiere decir que, si volvemos a un Production Checkpoint que hayamos tomado con anterioridad, el equipo virtual iniciará de cero, de forma limpia y con un sistema de archivos y aplicaciones en un estado consistente.

En el caso de que no se puedan tomar Production Checkpoints, pro cualquier motivo, como por ejemplo que el sistema operativo de la máquina virtual no los soporta, o que el servicio VSS no funciona correctamente se podrán tomar checkpoints tradicionales.

  1. PowerShell Direct:

Otra de las grandes novedades de Hyper-V es PowerShell Direct, una gran característica para troubleshooting de máquinas virtuales. Nos brinda la capacidad de gestionar máquinas virtuales a través de PowerShell sin necesidad de tener ningún tipo de conectividad IP con la máquina virtual. En situaciones donde una máquina virtual ha perdido conectividad, no nos queda más remedio que entrar a través de consola y solucionar el problema. En un entorno multi-tennant, o en un datacenter con un gran volumen de máquinas virtuales, PoerShell Direct resulta una herramienta muy útil debido a que no necesita configuración alguna de PS Remoting, únicamente necesitaremos las credenciales del equipo virtual al que queremos acceder.

Hasta la fecha soporta equipos Windows 10/2016 ejecutándose en Hosts Windows 10/2016.

  1. Virtualización Anidada:

Para personas que necesitamos crear un entorno de pruebas, por ejemplo, laboratorios y demás, siempre nos ha dado un poco más de trabajo, cuando no disuadido el hecho de que algunos de los equipos del laboratorio no pudieran virtualizarse, debido a que en Microsoft no se podía anidar la virtualización.

Como resultado, en un laboratorio, por ejemplo, los sistemas operativos de servidor que ejecutaban Hyper-V debían ser instalados en equipos físicos, lo cual es molesto y poco conveniente un gran número de razones, como la portabilidad, el hardware dedicado etc… La alternativa hasta la fecha, y lo sigue siendo debido a que esta característica en Microsoft aún está en pruebas, es crear el laboratorio con VMWare, en donde no existe este problema. Simplente con habilitar las extensiones de virtualización en un equipo virtual configurado con la opción de sistema operativo invitado configurada con “Hyper-V (Not supported)” es suficiente.

¿En qué consiste?

Tradicionalmente, la capa de Hardware, conocida también como Nivel 0, traslada las extensiones de virtualización de la CPU física al Hypervisor de Microsoft Hyper-V, el cual puede entonces ejecutar equipos virtuales. Este sería el Nievel 1 o primer nivel de virtualización, y el habitual hasta el momento en Microsoft.

Cuando podemos pasar estas extensiones de virtualización desde el Nivel 0 a través del primer nivel de virtualización hasta un equipo virtual que ejecute Microsoft Hyper-V, llegamos al Nivel 2 o segundo nivel de virtualización, es decir, ejecutamos una máquina virtual dentro de otra máquina virtual.

Esta característica todavía está en desarrollo y no soportada hasta la fecha actual (Technical Preview 4), y conlleva una serie de prerrequisitos y limitaciones que pasaremos a detallar.

Los requisitos son:

El equipo Host y el equipo virtual donde se va a realizar la anidación deberán ejecutar Windows Server 2016 (El Hypervisor de Windows 10 también dispone de esta capacidad)

La memoria dinámica debe estar deshabilitada en la máquina virtual donde vamos a anidar las extensiones de virtualización

Esta máquina virtual debe tener más de una CPU virtual

En la tarjeta de red virtual debemos habilitar MAC Spoofing

También debemos habilitar las extensiones de virtualización en el equipo virtual, mediante PowerShell lo cual nos permite trasladar las dichas extensiones desde el equipo físico a la máquina virtual.

Si obviamos el paso anterior no se nos permitirá ni tan siquiera instalar Hyper-V en el equipo virtual.

Las extensiones de virtualización están deshabilitadas por defecto en una máquina virtual y es necesario habilitar dicha característica.

A modo de muestra, el comando:

Get-VMProcessor –VMName <Nombre del equipo virtual a configurar> | FL *

Nos permite comprobar el estado de las extensiones de virtualización del equipo virtual. La propiedad ExposeVirtualizationExtensions estará configurada a “False” por defecto.

Con el siguiente comando habilitamos las extensiones habilitando el equipo virtual para ejecutar otras máquinas virtuales.

Set-VMProcessor –VMName <Nombre del equipo virtual a configurar>-ExposeVirtualizationExtensions $true

Existen scripts que podemos descargar que se encargan de realizar las todas comprobaciones pertinentes, pero el comando anterior es lo que necesitamos.

Hasta la fecha estas son las siguientes limitaciones, aunque esta funcionalidad está en fase de pruebas y es muy probable que cuando exista una versión definitiva, algunas de ellas desaparezcan:

“Live Migration” no funciona

“Live Memory Resize” no funciona

Los Checkpoints no funcionan

Guardar/Restaurar no funiona

Actualmente únicamente se soporta para procesadores Intel, y no para AMD.

 

Hyper V sobre Hyper V en Server 2012

Enable-WindowsOptionalFeature –Online -FeatureName Microsoft-Hyper-V –All -NoRestart

Install-WindowsFeature RSAT-Hyper-V-Tools -IncludeAllSubFeature

Install-WindowsFeature RSAT-Clustering -IncludeAllSubFeature

Install-WindowsFeature Multipath-IO

Restart-Computer

 

Anuncios

Acerca de Nestor Reveron

MCT, MCSD Azure Architect, MCSAx3 2016-Cloud Platform, MCSEx4 Cloud Platform-Infrastructure & Productivity, ITIL F
Vídeo | Esta entrada fue publicada en Education Microsoft, IT. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s