La administración de ESXi falla y rechaza las conexiones después de copiar en la unidad de arranque desde una copia de seguridad

Question

Escribo esto después de haber encontrado la solución yo mismo, porque fue un problema tan extraño que merece ser documentado.

Aunque encontré este problema mientras realizaba una restauración, es posible que esto surja en otros casos de inicio en otro sistema operativo mientras la unidad de inicio de una instalación de ESXi está conectada al sistema, particularmente si el tamaño del disco ha cambiado.

Recientemente restauré la unidad de arranque de una instalación de VMware ESXi, que también contiene un almacén de datos que contiene la mayoría de las máquinas virtuales y sus discos virtuales de arranque/sistema, solo para descubrir que este estado supuestamente bueno estaba de alguna manera alterado.

Según la pantalla de la consola local del servidor, ESXi parecía estar arrancando normalmente, pero mostraba muchos síntomas problemáticos:

• No se pudo iniciar sesión con vSphere Client, lo que mostró el mensaje "vSphere Client no pudo conectarse aanfitrión. Se produjo un error de conexión desconocido. (La solicitud falló debido a un error de conexión. (No se puede conectar al servidor remoto))”.

• El registro de vSphere Client incluía un error:

  System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it

• Al intentar iniciar sesión en el servidor con un navegador web, el navegador informó que la conexión fue rechazada.

• No se pudo ingresar mediante SSH al servidor incluso después de habilitarlo en la consola local.

• Reiniciar la red de administración y los agentes de administración a través de la consola local no solucionó el problema.

• En la consola local, lo descubierto hostdno se estaba ejecutando y el reinicio no solucionó el problema.

• esxcliLos comandos siempre daban:Connect to localhost failed: Connection failure

• Había menos directorios de /vmfs/volumeslos esperados y ninguno de ellos parecía ser alguno de mis almacenes de datos.

• Incluso "Restablecer configuración del sistema" en la interfaz de usuario local no solucionó el problema. (Solo intenté esto porque tenía una imagen en buen estado que podía restaurar nuevamente, lo cual hice después de resolver el problema, aunque no estoy seguro de que haya cambiado algo).

La copia de seguridad que estaba restaurando era una imagen de bajo nivel del disco lógico RAID tomada con el servidor inactivo. Después de eliminar una matriz RAID potencialmente dañada y recrearla, utilicé una unidad separada conectada a un HBA para iniciar una instalación física de Windows Server y copiar la imagen en el nuevo RAID. Utilicé la herramienta HDD Raw Copy dehddguru.com, que es básicamente una alternativa menos críptica y mordaz al ddcomando de Linux.

(Esta es una forma ciertamente bárbara, aunque bastante completa, de hacer una copia de seguridad de VMware, pero este disco principalmente solo almacena discos de arranque/sistema de VM, no datos, por lo que no se realiza una copia de seguridad con mucha frecuencia, de todos modos, excepto cuando se realizan cambios importantes. Tenemos sistemas de respaldo mucho mejores para datos primarios).

Hice el nuevo disco lógico RAID más grande que el que había sido respaldado, ya que actualizamos a unidades más grandes en el RAID y el almacén de datos estaba un poco lleno. Había estado planeando hacer crecer el almacén de datos, después de confirmar que la copia de seguridad funcionó.

Tan pronto como terminé la copia sin formato, inicié ESXi y encontré que estaba defectuoso. ¡¿Qué pasó?!

Este es un ESXi 5.0 U3 bastante antiguo. (Ha estado satisfaciendo bien nuestras necesidades actuales y no tenemos personal de TI a tiempo completo para administrar las actualizaciones por el simple hecho de actualizarlas, solucionar los problemas que a menudo causan, etc.)

Answer 1

En mi caso, el daño puede provenir de Windows, pero otro software podría causar el mismo problema.

Esto definitivamente se aplica a ESXi 5.0 U3 y probablemente a cualquier ESXi 5.x, y supongo que posiblemente a cualquier ESXi 6.x. Es menos probable que se aplique a ESXi 7, que utiliza un diseño de partición diferente y más simple.

Antecedentes de la investigación

Estaba muy cerca de realizar una instalación nueva cuando finalmente comencé a resolverlo.

Hurgando en /vmfs/volumes, una cosa extraña que noté fue que había $RECYCLE.BINdirectorios en todos ellos, y estos contenían DESKTOP.INIarchivos, con contenidos consistentes con las extensiones de shell del Explorador de Windows. Esto es un poco peculiar de encontrar en las particiones del sistema de un hipervisor que no está ni nunca ha estado basado en Windows.

Inmediatamente sospeché que el sistema operativo Windows que había usado para copiar la imagen del disco le había hecho algo. ESXi utiliza varias particiones FAT en su disco de arranque, por lo que quizás Windows pueda jugar con ellas. Teniendo en cuenta que la imagen del disco se tomó de un estado en buen estado conocido pero falló sin hacer nada en absolutodentroESXi, este parecía el curso de investigación más prometedor.

Inicialmente quedé consternado cuando descubrí, a través de un editor hexadecimal, que estos $RECYCLE.BINdirectorios también aparecían en la imagen del disco. Al principio entendí que esto significaba que el daño ya estaba hecho antes de que se tomara la imagen, también en Windows Server. Sin embargo, resultaron ser benignos, aunque me llevaron en la dirección correcta. Es probable que Windows los haya agregado tan pronto como vio el disco lógico original, que aún no había sido ampliado, y a pesar de que el disco se mantuvo "fuera de línea" todo el tiempo.

Hurgando más en el editor hexadecimal (HxD - Editor hexadecimal y editor de disco, herramienta realmente buena) reveló una pequeña y extraña diferencia entre la tabla de particiones GPT en la imagen del disco y la que se encuentra en el nuevo disco RAID. Esta no es una diferencia que habría mostrado un editor de particiones, porqueen realidad no hace ninguna diferencia lógicamente, Por lo que yo sé. Esto es algo que tendrías que estar hurgando en un vertedero hexadecimal sin procesar para encontrarlo.

Causa principal

En ambos casos, había siete entradas no vacías en la matriz de particiones. Sin embargo, según la forma en que ESXi había escrito originalmente la matriz, había un espacio de una entrada vacía (los 128 bytes puestos a cero) después de las primeras tres entradas, de modo que las últimas cuatro entradas válidas caían en su propio sector de 512 bytes. En el disco en vivo, donde se modificó ESXi, las últimas cuatro entradas válidas se habían movido una entrada hacia arriba para cerrar la brecha. Por lo demás, las entradas eran idénticas.

No sé quién hizo esto, Windows o HDD Raw Copy Tool, pero de alguna manera sospecho de Windows. Lo he probado nuevamente y este cambio estará presente.inmediatamenteuna vez realizada la copia, incluso si la unidad lógica RAID está "Sin conexión" en el complemento MMC de Administración de discos durante y después de la copia. Es un cambio obviamente intencionado, porque todos los CRC son correctos y el GPT de respaldo también se cambia.

Mi teoría es que quienquiera que esté haciendo esto está reescribiendo el GPT porque no coincide con el tamaño del disco, y que en lugar de simplemente copiar exactamente la matriz existente, está memorizando las particiones como una lista en alguna estructura interna y luego vuelve a escribir. escribir la matriz directamente, lo que por supuesto no produce un espacio.

Como nota al margen, las entradas en la matriz escritas por ESXi no estaban en el mismo orden en que las particiones ocurren físicamente en el disco, pero cualquier programa que cerró la brecha al menos no se tomó la libertad de ordenar las entradas también. ¡agradecidamente!

Reparación manual

No conozco ninguna manera fácil de recrear esta brecha, porque generalmente cualquier editor de particiones hará lo mismo: convertir la tabla existente en una representación interna utilizada por la herramienta, realizar los cambios que solicite en esa representación y luego escriba la tabla nuevamente en formato GPT de modo que tenga los datos correctos. Hasta donde yo sé, se supone que la posición exacta en el disco de las entradas de la matriz no es relevante y, por lo tanto, no formará parte de dichos "datos correctos" que escribe.

Sin embargo, tenía el presentimiento de que ESXi podría ser quisquilloso con el diseño exacto de la matriz, así que decidí arreglarlo manualmente para ver qué pasaba. El procedimiento fue:

1. Asegúrese de que el disco esté "Sin conexión" en el complemento MMC de Administración de discos (como precaución).
2. Abra el disco en un editor hexadecimal. En HxD está bajoExtras→Abrir disco...y tienes que elegirlo en "Discos físicos". Asegúrese de desmarcar "Abrir como sólo lectura", que está activado de forma predeterminada. Recibirá una advertencia adecuada acerca de que esto es peligroso.
3. En la matriz del GPT principal, que generalmente comienza en LBA 2 (confirme en la palabra cuádruple del encabezado a las 48 h), deslice hacia abajo las entradas que se supone que están después del espacio copiando rangos, pegándolos más hacia abajo y luego poniendo a cero el espacio. Mejor aún, simplemente copie la tabla real de la imagen de respaldo, si tiene una; pero tenga en cuenta que si el tamaño del LUN ha cambiado, no puede simplemente copiar en el encabezado GPT o, de lo contrario, es posible que la situación se repita, ya que ese encabezado tendrá valores incorrectos para los campos 20h y 30h.
4. Selecciona elcompletorango de la matriz del GPT. Técnicamente, debe determinar el rango utilizando el producto de las palabras dobles en 50h y 54h en el encabezado GPT, pero este número normalmente será de 16.384 bytes.
5. Tome el CRC32 del rango seleccionado en el paso 4. No pude encontrar los parámetros matemáticos del algoritmo CRC32 en la especificación UEFI, pero pude descubrir que es uno muy común, el de ISO 802-3. con el polinomio normal 04C11DB7h. Puedes calcularlo con una calculadora en línea.aquí, asegurándose de configurar "Tipo de entrada" en hexadecimal. Coloque esto en el encabezado GPT en little-endian a las 58 h.
6. Coloque temporalmente cero en los cuatro bytes del encabezado GPT a las 10 h.
7. Tome el CRC32 del encabezado, cuya longitud se especifica en el propio encabezado mediante la palabra doble en 0Ch. Coloque esto en el encabezado a las 10 h.
8. Repita los pasos del 3 al 7 para el GPT de respaldo. La matriz y su CRC serán los mismos, por lo que puede simplemente copiarlos, pero el encabezado será diferente y, por lo tanto, tendrá un CRC diferente. El encabezado de la copia de seguridad normalmente se encuentra en el último sector del disco, con la matriz inmediatamente antes, pero técnicamente debe marcar la palabra cuádruple 20h en el encabezado GPT principal y la palabra cuádruple 48h en el encabezado de la copia de seguridad para confirmar.
9. Si eresCompletamente seguroHas hecho todo esto bien, presiona Guardar. Nuevamente, HxD le dará aquí un mensaje de advertencia adecuado.

Puedes consultar elArtículo de Wikipediapara conocer los detalles técnicos básicos del formato GPT.

Capturas de pantalla

Así es como se veía parte de la matriz GPT "rota"; tenga en cuenta que las entradas válidas terminan en 77Fh y que no hay series largas de ceros antes de esa fecha:

Así es como lo arreglé; tenga en cuenta que las inscripciones válidas ahora finalizan a las 7FFh:

Resultado

Realmente no esperaba que esto funcionara. No lo he estudiado, pero esperaría que la especificación UEFI no le dé importancia al orden o espaciado de las entradas de la matriz. De hecho, cada partición tiene un GUID único.precisamenteasí que túnoTenemos que confiar en heurísticas tan frágiles. Como tal, dependiendo de que los índices de la matriz sean los mismos que cuando escribiste la tabla, sería una mala idea.

^{(Por otra parte, no sería la primera vez que veo software y firmware de nivel empresarial involucrarse en malas ideas. Parece que cada otra ocasión en la que me pongo el sombrero de administrador de sistemas, me enfrento a uno u otro increíblemente estúpido pieza de programación... pero no me dejen despotricar.)}

Entonces, guardé con cautela la tabla modificada, reinicié el RAID, se inició ESXi, se conectó vSphere Client y todo volvió a la normalidad.

Idealmente, normalmente sería mejor utilizar algo como Veeam Backup, pero en algunas situaciones es másad hocEs posible que las soluciones estén en orden, en cuyo caso podría encontrarse con este error.