En entornos de virtualización empresarial, pocas situaciones generan tanta incertidumbre como una infraestructura de almacenamiento que aparentemente se ha recuperado, pero las rutas Fibre Channel (FC) siguen mostrando un estado incoherente. El enlace físico está levantado, el conmutador de fibra responde, los puertos del array están operativos, y sin embargo el hipervisor ESXi no logra ver los caminos esperados. Esa tensión operativa, donde el sistema no está en caída total pero tampoco es fiable, es el escenario que aborda este runbook sobre el reseteo de Fabric Login (FLOGI). No se trata de memorizar un comando, sino de entender cuándo y cómo aplicarlo sin provocar una interrupción evitable.
El comando esxcli storage san fc reset -A vmhbaX (o su equivalente para FCoE) fuerza al adaptador a reiniciar su relación con la trama de fibra, relanzando la secuencia FLOGI y PLOGI. Pero utilizarlo como primera reacción es peligroso. Una decisión apresurada puede convertir un problema de visibilidad parcial en una parada completa de aplicaciones. Por eso, empresas especializadas como Q2BSTUDIO, que desarrollan aplicaciones a medida y gestionan infraestructuras críticas, recomiendan seguir un proceso estructurado que combine análisis de redundancia, coordinación con equipos de almacenamiento y validación en múltiples capas.
El problema de fondoCuando un conmutador de almacenamiento se reinicia, sufre un failover o tiene un evento a nivel de puerto, el host ESXi puede quedar con rutas 'muertas', 'desconectadas' o simplemente ausentes. Un rescan estándar desde el cliente vSphere a menudo elimina entradas obsoletas pero no restaura las rutas activas. El enlace físico está up, pero el driver del HBA no inicia la secuencia FLOGI necesaria. El host está 'despierto pero ciego' ante la trama. Esa diferencia entre enlace levantado y acceso completo al almacenamiento es la clave del problema.
Por qué no empezar por el resetUn reset FLOGI actúa a nivel de adaptador, no corrige problemas de zonificación, enmascaramiento de LUN ni configuraciones del conmutador. Antes de ejecutarlo hay que responder cuatro preguntas: ¿La trama de fibra está realmente estable? ¿El host dispone de suficientes rutas alternativas para tolerar la desconexión momentánea? ¿Se ha identificado correctamente el adaptador afectado? ¿Se ha intentado un rescan menos disruptivo sin éxito? La regla de oro es: el reset solo debe ejecutarse tras haber demostrado que es necesario.
Síntomas y señales de riesgoLos síntomas se manifiestan como una discrepancia entre el estado esperado y el observado. En el cliente vSphere aparecen datastores con menos rutas de las previstas, dispositivos RDM que no responden o máquinas virtuales que se quedan atascadas. Los comandos esxcli storage core path list y esxcli storage nmp path list revelan caminos ausentes o en estado 'dead'. En el conmutador SAN, el WWPN del host puede no estar logueado o tener un login fantasma (ghost FLOGI). El array, por su lado, muestra el iniciador offline o la máscara de LUN no coincide. Ignorar estos indicios y lanzar el reset puede agravar la situación.
Flujo de decisión seguroEl runbook propone un flujo donde el reset aparece al final, tras recopilar evidencia, validar la trama y el array, confirmar redundancia y ejecutar un rescan dirigido. Los pasos son:
Cuándo es seguro y cuándo es peligrosoEl reset es apropiado cuando el evento de trama ha terminado, el array confirma que la visibilidad es correcta, el host mantiene redundancia de rutas para los dispositivos afectados y el rescan no ha funcionado. Es peligroso si el adaptador transporta la única ruta viva a un datastore, si ambos fabrics están degradados, si se está modificando la zonificación o el enmascaramiento, o si el host arranca desde SAN sobre esa ruta. También es crítico evitar resetear ambos adaptadores a la vez, ya que eso anula el propósito del multipath.
Consideraciones especiales para RDM y clústeres invitadosLos discos en modo RDM (Raw Device Mapping) merecen atención extra. Una máquina virtual que utiliza un RDM puede fallar tras un reinicio si el dispositivo subyacente no se vuelve a presentar correctamente. Antes de resetear el adaptador, identificar la VM, coordinarse con el propietario de la aplicación y evitar reinicios de invitados hasta confirmar que la visibilidad del dispositivo es correcta. En clústeres invitados (por ejemplo, SQL Server Always On), la pérdida momentánea de un disco puede generar timeouts y divisiones de quorum.
Errores comunesEl error más frecuente es resetear el adaptador basándose únicamente en un síntoma de interfaz gráfica, sin mapearlo al HBA físico, WWPN y fabric correcto. Otros fallos incluyen ejecutar el reset cuando la causa raíz es un problema de zona o máscara (que debe resolverse desde la SAN), tratar FCoE como si fuera FC nativo, o repetir el reset múltiples veces sin detenerse a analizar. El comando es simple; la coordinación es la parte difícil.
Integración con servicios de infraestructura modernaGestionar correctamente estos escenarios requiere no solo conocimiento técnico, sino también herramientas y procesos robustos. Empresas como Q2BSTUDIO ofrecen servicios cloud AWS y Azure que permiten externalizar capas de almacenamiento y recuperación ante desastres, reduciendo la dependencia de tramas FC on-premise. Además, sus soluciones de ciberseguridad y ia para empresas ayudan a monitorizar la salud de las rutas de almacenamiento mediante agentes IA que detectan anomalías antes de que se conviertan en incidentes. La inteligencia artificial aplicada a la gestión de infraestructuras permite identificar patrones de pathing defectuoso y sugerir acciones correctivas con mínima intervención humana. Por otro lado, el uso de Power BI como parte de los servicios inteligencia de negocio facilita la creación de dashboards que visualizan el estado de las rutas FC a lo largo del tiempo, ayudando a los equipos de operaciones a tomar decisiones informadas.
Plantilla de registro de incidentePara que el conocimiento no se pierda, es recomendable documentar cada reset con una plantilla que incluya: fecha, vCenter, dominio VCF, cluster, host, adaptador, tipo (FC/FCoE), puerto de conmutador, WWPN, targets afectados, datastores y RDMs, conteo de rutas esperado vs observado antes y después, validación de SAN y array, comando ejecutado, resultado y si fue necesario un plan de contingencia (por ejemplo, reinicio del host). Esta trazabilidad es especialmente útil cuando el reset funciona, porque puede ocultar una causa raíz que sigue latente.
ConclusiónUn reset de Fabric Login es una herramienta quirúrgica, no un martillo para todo tipo de problemas de almacenamiento. Cuando las rutas FC mienten, el objetivo no es limpiar la interfaz gráfica, sino restaurar una visibilidad de extremo a extremo fiable sin provocar una parada de plataforma. La secuencia segura es: delimitar el radio de explosión, verificar la salud de la trama y el array, demostrar redundancia, capturar evidencia, intentar un rescan dirigido, resetear un solo adaptador si está justificado y validar desde tres perspectivas (ESXi, conmutador y array). Con disciplina operativa y el apoyo de proveedores tecnológicos como Q2BSTUDIO, que implementan aplicaciones a medida para automatizar estos runbooks, las organizaciones pueden minimizar el tiempo de inactividad y mantener la continuidad del negocio.