Get best of the week

Windows Server 2019 vs. Instantáneas de VMware con inactividad: una solución elegante al problema



Hola Habr!

Las máquinas virtuales de Windows Server 2019 con emulación EFI en VMware tienen un problema con las instantáneas basadas en aplicaciones. Se ve así: se realiza una instantánea, alcanza el 100%, se cuelga durante 5 minutos y luego cae en el error No se pudo detener la máquina virtual.
 


La investigación mostró que la causa de este error fue un conflicto entre el VSS de Windows Server 2019 y el proveedor de instantáneas VMware, que es responsable del bloqueo de la aplicación. Esto prepara la máquina virtual para las instantáneas: detiene las aplicaciones y las operaciones de escritura para que después de la recuperación de las instantáneas, todos los datos sean consistentes.

Microsoft ha afirmado y afirma que las instantáneas basadas en aplicaciones son perfectamente compatibles con el sistema operativo. De hecho, tal problema no ocurre en Hyper-V. VMware invitó modestamente a sus usuarios a simplemente desactivar la inactividad (y qué, esa instantánea no será coherente a nivel de aplicación). O rechace los discos del sistema con marcado GPT y emulación EFI (¡en 2020!). 

Hoy le mostraré cómo solucionar este problema de manera hermosa y obtener instantáneas consistentes que reconozcan las aplicaciones de las máquinas virtuales de Windows Server 2019 y, al mismo tiempo, le recordaré la forma compatible con Microsoft de instalar Windows Server en una máquina virtual.

¿Quién es culpable?


Comenzar de nuevo. Al crear una máquina virtual en VMware ESXi en VM Options, la emulación predeterminada es la emulación de BIOS. Y, si bien no existen requisitos especiales para la seguridad o el tamaño del disco del sistema, este escenario es bastante apropiado. Pero tan pronto como necesitemos configurar el Arranque seguro o la cantidad de vCPU supere los 128, tendremos que crear una VM con emulación UEFI. Aunque solo sea porque hay:

  • Arranque seguro: protección contra el arranque desde medios extraños.
  • Soporte de cifrado (requiere soporte de TPM, pero en ESXi 6.7 el mismo problema).
  • Soporte para unidades de más de 2 TB (dudoso, pero sucede).
  • Soporte para una gran cantidad de procesadores.

Si instala Windows en máquinas virtuales VMware, como solíamos hacer (crear máquinas virtuales, palmarse de ISO, cargar con controladores, siguiente, siguiente ...), luego, cuando GPT particiona la unidad del sistema, aparece la sección Recuperación junto a la partición EFI y la partición con el sistema.

Recordamos el material:

Partición de recuperación : una partición protegida en el disco duro del sistema, que se utiliza para restaurar la configuración de fábrica del sistema en caso de problemas. Cuando instala Windows Server en un disco GPT, Recovery escribe el Entorno de recuperación de Windows (WinRE). Los fabricantes de computadoras, como regla, complementan esta sección con sus configuraciones personalizadas y controladores diseñados para un hardware específico.

¡Detener! 

Pero no estamos trabajando con hardware, sino con una máquina virtual. No se requieren retrocesos a ninguna configuración de fábrica. Al final, si desea devolver la VM a su estado original, simplemente la volvemos a implementar. Por lo tanto, la partición de recuperación en la VM no tiene sentido y no es particularmente necesaria.

La sección Recuperación está protegida contra modificaciones y borrados accidentales: "no se congela". Como resultado, surge un conflicto entre VSS VMware Snapshot Provider y Microsoft Windows VSS: el proveedor de VMware está tratando de capturar todas las particiones del disco y Windows Server no le permite hacer esto. Los registros nos informan estas buenas noticias:



¿Qué hacer?


Se trata de manera simple. Puede instalar Windows en una máquina virtual con el cmdlet Convertir imagen de Windows. En realidad, tal secuencia de comandos de instalación es recomendada y compatible con el propio Microsoft (esta secuencia de comandos está en la imagen RTM de Windows Server 2016 en el directorio con la imagen de Nano Server, pero esta es otra historia no menos interesante;)).

El script creará automáticamente una plantilla con el Windows Server sysprepped actualizado, los controladores necesarios e incluso roles. Este enfoque es interesante porque la instalación y configuración del sistema operativo se puede automatizar, ya que el script admite unattend.xml. Además, esta opción proporciona libertad para la ingeniería: desde el prelanzamiento de una VM en Hyper-V con instalación a través de Invoke-Command hasta la creación de un servicio personalizado mediante la edición del registro. 

En la salida, obtenemos un disco VHD grueso, que puede deslizar VMware , iniciar la VM, poner VMware Tools y convertirlo en una plantilla. Como resultado, la VM tendrá un marcado GPT en su interior, adecuado para ejecutarse en una VM EFI y sin una sección de recuperación por diseño. Como beneficio adicional: en mi ejemplo, crearé inmediatamente un adaptador paravirtual para proporcionar rendimiento. Y lo más importante: para una máquina virtual de este tipo, la instantánea con reconocimiento de aplicaciones se puede hacer sin problemas.

Ahora todo se detalla en pasos.

Extracción del controlador


  1. Descargue la imagen del repositorio .
  2. Monta la imagen.

  3. Ejecute cmd.exe y vaya a la raíz de la imagen montada
  4. Ejecute el instalador con las teclas:
    setup64.exe /A /P <  >
  5. En el segundo paso del asistente, repetimos la ruta para desempaquetar:

  6. Los controladores están aquí: VMWToolsExtract \ VMware \ VMware Tools \ VMware \ Drivers

Windows Server 2019


  1. . , .
  2. : Servicing Stack Update. How to get this update , MS update catalog:

  3. Windows Server 2019 Cumulative Update Servicing Stack Update.



  4. CAB- :



  1. PowerShell .

  2. Install-Module -Name Convert-WindowsImage
  3. - Convert-WindowsImage:
    $ConvertWindowsImageParam = @{
	#    Windows Server 2019
	SourcePath = "C:\work\en_windows_server_2019.iso"
	#   
	VHDFormat = "VHD"
	#   
	SizeBytes = 40GB
	#   - GPT
	DiskLayout = "UEFI"
	BCDinVHD = "VirtualMachine"
	#   
	DiskType = "Fixed"
	#  - Windows Server 2019 Standard (Desktop Expirience)
	<#
	 :
	1 - Windows Server 2019 Standard (Core)
	2 - Windows Server 2019 Standard (Desktop Expirience)
	3 - Windows Server 2019 Datacenter (Core)
	4 - Windows Server 2019 Datacenter (Desktop Expirience)
	#>
	Edition = @("2")
	#  Remote Desktop
	RemoteDesktopEnable = $True
	#   
	Feature = @("TelnetClient","WindowsServerBackup","NetFx3")
	#   (     CAB)
	#       :  SSU,  
	Package = @("C:\work\Windows10.0-KB4523204-x64.cab","C:\work\Windows10.0-KB4534321-x64_PSFX.cab")
	#     
	Driver = @("C:\work\VMWToolsExtract\VMware\VMware Tools\VMware\Drivers")
	}
  4. Windows Server 2019 :
    Convert-WindowsImage @ConvertWindowsImageParam





La instalación lleva hasta 30 minutos.

En este ejemplo, el resultado es un sistema operativo totalmente preparado en el estado Sysprep, pero nada nos impide usar Unattend.xml para la personalización (las especificaciones de personalización se complican un poco cuando ve la plantilla sysprep y la VM no se expande).

Lea más sobre las claves de este maravilloso kmlet aquí y en Obtener ayuda del kmlet mismo.

Después de eso, puede cargar el disco en ESXi, crear una VM e instalar VMware Tools. E implemente máquinas virtuales sin preocuparse por los problemas de instantáneas inmovilizadas.

Pero, ¿qué pasa si ya hay una plantilla "defectuosa"?


Es suficiente simplemente eliminar la partición de recuperación a través de diskpart.exe y mover el EFI y las particiones del sistema por la belleza del marcado (pero no puede hacerlo). ¿Es compatible? En una máquina virtual, ¡definitivamente!

  1. Comenzamos cmd.exe.
  2. Comenzamos diskpart.
  3. Obtenga la lista de unidades:
    list disk
  4. Selecciona un disco:
    select disk n

    donde n es el número de disco.
  5. Enumeramos las secciones:
    list partition
  6. Observamos el número de partición de Recuperación (n) y lo seleccionamos:
    select partition n
  7. Eliminar la protección de la sección:
    gpt attributes=0x8000000000000000
  8. Eliminar:
    delete partition
  9. ¡Lucro!





¡VM está lista para las instantáneas de Quescing!

En lugar de una conclusión


Este enfoque es solo una de las opciones para implementar Windows Server y resolver el problema KB60395 . Por supuesto, en este caso podemos hacer VDH delgado y luego usar la utilidad quemu-img para convertir el disco virtual al archivo OVF, que ESXi entiende muy bien. Tal escenario es bastante apropiado, por ejemplo, en el caso cuando el disco virtual necesita ser transferido a través de la red. Comprender la historia del problema y la verdadera naturaleza del problema siempre hace posible encontrar una solución adecuada para una infraestructura particular. La implementación técnica es un campo para experimentos y fantasías interesantes, que es ilimitado.

More articles:


All Articles