Instalar Windows Server 2019 en NVMe 4Kn + 64 B: guía completa

Al intentar instalar Windows Server 2019 en un SSD NVMe con sectores 4 KiB + 64 B aparecen huecos «sin asignar» y la instalación falla. Esta guía explica la causa y cómo reformatear la unidad a 4Kn puro para completar el proceso.

Índice

Naturaleza del problema

Las unidades NVMe modernas pueden presentar varios LBAF. El perfil 4Kn «puro» expone sectores de 4096 bytes exclusivamente para datos de usuario. En cambio, el perfil 4Kn + 64 B reserva 64 bytes adicionales por sector para metadatos de protección (DIF/DIX), totalizando 4160 bytes físicos.

El cargador EFI de Windows Server 2019 y su pila NVMe solo están validados para arrancar desde dispositivos cuyo tamaño de sector lógico no exceda 4096 bytes. Al detectar un tamaño superior (4160 bytes) más una etiqueta de protección, el instalador:

pierde el alineamiento de las particiones primarias,
muestra «espacios sin asignar» de 0 MB,
informa capacidades inexactas y, finalmente,
deniega la instalación en la unidad afectada.

Cómo verificar el formato actual de la unidad

Antes de reformatear, asegúrate de que el LBAF activo es el causante. Desde una consola WinPE o ya dentro del SO:

Get-Disk | Select Number, FriendlyName, LogicalSectorSize, PhysicalSectorSize

Un valor de 4096/4160 confirma la presencia de 64 bytes extra de metadatos.

Por qué Windows Server 2019 rechaza 4Kn + 64 B

Las rutinas de arranque de Windows descargan el núcleo desde la partición EFI usando llamadas de lectura de bloque que esperan un múltiplo exacto de 512 o 4096 bytes. Al encontrarse con sectores de 4160 bytes:

El firmware UEFI puede aceptar la geometría, pero la fase de boot loader no dispone de lógica para saltar los 64 bytes de metadatos.
Las funciones de particionado (setup.exe / diskpart) intentan redondear al límite inferior, provocando los «huecos» de 0 MB.
El proceso concluye con un mensaje ambiguo o simplemente impide seleccionar el disco.

Síntomas típicos durante la instalación

Comportamiento	Interpretación
Entradas de 0 MB “sin asignar”	Desalineación por metadatos DIF/DIX
Capacidad útil reducida	Bytes de metadatos mal contados como espacio no disponible
Imposibilidad de “Siguiente”	Setup detecta geometría no válida para arranque

Solución inmediata: volver a 4Kn “puro”

Reformatea la unidad a un LBAF que exponga únicamente bloques de 4096 bytes. Casi todos los controladores NVMe incluyen una utilidad CLI o GUI para ello. Ejemplo genérico en entornos Linux Live:

# El parámetro --lbaf puede variar; consulta la tabla de la unidad
nvme format /dev/nvme0 --lbaf=1 --ses=1

Interpretación rápida de los argumentos:

--lbaf=1 – índice de LBAF asociado a 4Kn puro.
--ses=1 – Solicita un formato destructivo (borra datos).

Para controladores Samsung, Intel o Kioxia, el mismo procedimiento existe con herramientas propietarias (Magician Portable, Intel MAS, Kioxia SSD Utility). En plataformas sin interfaz NVMe CLI, inicia un entorno WinPE y utiliza la aplicación DOS/UEFI correspondiente.

Pasos detallados para administradores

Respaldar los datos críticos – El formateo a otro LBAF borra la tabla de particiones.
Identificar el índice LBAF adecuado – En la salida de nvme id-ns busca aquel con lbads = 0xC (4096 bytes) y ms = 0.
Ejecutar el comando de formateo.
Apagar el equipo – Descarta la caché volátil del controlador.
Arrancar el medio de instalación de Windows Server 2019; el disco aparecerá con la capacidad correcta y sin huecos.

Comprobación posterior al formateo

Una vez instalado el sistema, valida de nuevo:

Get-PhysicalDisk | Where BusType -eq NVMe |
    Select MediaType, LogicalSectorSize, PhysicalSectorSize

El resultado debe ser 4096/4096. Revisa además Get-Volume para confirmar el tamaño íntegro de la partición del sistema.

Alternativas cuando se necesitan metadatos DIF/DIX

En entornos que exigen protección end‑to‑end:

Montar la unidad como volumen de datos – Usa el disco NVMe 4Kn + 64 B en un servidor distinto y preséntalo vía iSCSI o SMB, dejando el arranque en un SSD convencional.
Adoptar Linux como SO de arranque – Distribuciones con kernel > 5.x permiten arrancar con 4Kn + 64 B si el firmware expone host‑aware DIF/DIX.
Esperar soporte oficial – Mientras Microsoft no publique parches o la próxima versión de Windows Server no lo certifique, no hay garantía de éxito.

Compatibilidad de versiones de Windows Server

Versión	Arranque 4Kn puro	Arranque 4Kn + 64 B	Volumen de datos 4Kn + 64 B
2016	Soportado	No soportado	Lectura/Escritura limitada*
2019	Soportado	No soportado	Lectura/Escritura limitada*
2022	Soportado	No soportado	Lectura/Escritura limitada*

*El controlador puede montar la unidad solo si se presenta como volumen secundario y el HBA oculta los metadatos.

Buenas prácticas de administración

Documentar el LBAF antes de agregar nuevos servidores al inventario.
Aplicar firmware actualizado al SSD y a la tarjeta madre; algunos BIOS recientes filtran tamaños de sector no estándar.
Usar scripts de post‑instalación para comprobar LogicalSectorSize y generar alertas.
Probar siempre en laboratorio – Clústeres de Hyper‑V y SQL Server pueden reaccionar de forma distinta a la capa de metadatos.

Fundamentos de DIF/DIX

DIF (Data Integrity Field) y DIX (Data Integrity Extension) son mecanismos definidos en la especificación T10 para proporcionar verificación de integridad fuera de banda entre la aplicación, el sistema operativo y el dispositivo de almacenamiento. Cada bloque de datos contiene:

Guard: CRC de los 4096 bytes de datos.
Application Tag: Identificador opcional definido por la aplicación.
Reference Tag: Número de bloque lógico que detecta escrituras fuera de orden.

Windows presenta alternativas de integridad a nivel de sistema de archivos (NTFS journal, ReFS integrity streams); sin embargo, carece de la ruta de datos completa que combine DIF/DIX desde la pila NVMe hasta la capa de aplicación, de ahí la imposibilidad de arrancar.

Script PowerShell de verificación rápida

# Comprueba todos los discos NVMe y genera alerta si el sector físico > 4096
$discos = Get-PhysicalDisk | Where-Object BusType -eq 'NVMe'
foreach ($d in $discos) {{
    if ($d.PhysicalSectorSize -gt 4096) {{
        Write-Warning \"El disco {0} presenta metadatos DIF/DIX (sector {1} bytes)\" -f $d.DeviceId, $d.PhysicalSectorSize
    }}
}}

Impacto potencial en funciones de alta disponibilidad

Algunas funciones de Windows Server como Storage Spaces Direct y Cluster Shared Volumes dependen de tamaños de sector homogéneos en todos los nodos. Introducir un disco 4Kn + 64 B puede provocar:

Incompatibilidad de la capa de “pool” y, por tanto, de la convergencia inicial.
Fallos intermitentes durante la redistribución de datos en caso de fallo de nodo.
Advertencias de salud en el Failover Cluster Manager.

Por ello se recomienda certificar la topología de discos y tamaños de sector en un entorno de maqueta antes de proceder al despliegue en producción.

Preguntas frecuentes

¿Puedo conservar el formato 4Kn + 64 B y arrancar desde otro disco SATA?
Sí. Windows Server 2019 puede montar la unidad NVMe como volumen secundario si el controlador o la controladora RAID abstraen los 64 bytes de metadatos.

¿Existen parches o hotfix de Microsoft?
A la fecha, no hay KB que habilite el arranque con metadatos DIF/DIX.

¿Perderé rendimiento al volver a 4Kn «puro»?
El impacto es mínimo. La protección de datos provista por DIF/DIX no afecta latencia o IOPS, pero su ausencia implica confiar el control de integridad a capas superiores (NTFS/ReFS y la aplicación).

Conclusión

La incompatibilidad entre el instalador de Windows Server 2019 y el formato 4Kn + 64 B radica en la falta de soporte para metadatos DIF/DIX durante el arranque. Revertir temporalmente la unidad a 4Kn puro restaura la funcionalidad sin renunciar a la velocidad NVMe. Para workloads que exijan protección reforzada, mantén el disco en 4Kn + 64 B como volumen de datos o evalúa plataformas Linux hasta que Microsoft amplíe el soporte.

Instalar Windows Server 2019 en NVMe 4Kn + 64 B: guía completa