RRiparazioneServer.com
Solicitar presupuesto

Qué hacemos

Reparación de hardware Mantenimiento de servidores Recuperación de datos Ampliación & upgrade

Por fabricante

Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer Altos

Intervención & diferenciadores

Datacenter Lombardía Aruba Ponte San Pietro Más allá del soporte del vendor

Contacto directo

📞 02 95 17 550 💬 WhatsApp · +39 378 301 3120
Solicitar presupuesto → Servidor parado · Emergencia
Mantenimiento · capa OS

Estabilidad del SO: alinear drivers, kernel y firmware sobre un único eje.

Cuelgues aparentemente aleatorios, kernel panic intermitentes, hypervisor que matan VM sin causa aparente: a menudo el síntoma está relacionado con el hardware, pero la causa raíz está en el desajuste entre firmware del fabricante, drivers del sistema operativo, configuración del power management y carga de trabajo real. El diagnóstico sistémico es nuestro oficio, antes de sustituir hardware.

Planifica un health check
Síntomas típicos

Patrones de inestabilidad recurrentes.

  • BSOD de Windows recurrentes con un stop code estable (p. ej. DPC_WATCHDOG_VIOLATION, SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) — a menudo un driver de red o de storage no alineado con el firmware.
  • Kernel panic en Linux con un stack trace que apunta siempre al mismo driver — hace falta actualizar el driver in-tree o pasar al driver del fabricante.
  • PSOD en ESXi (Purple Screen of Death) con referencia a drivers de red, storage o RAID — verificación de la matriz de compatibilidad VMware-fabricante.
  • VM killed by hypervisor sin fallo del nodo: a menudo un power management agresivo que pone la CPU/caché en deep sleep durante la latencia de I/O.
Qué hacemos

Diagnóstico antes de tocar el hardware.

  • Alineación firmware ↔ driver: matriz de compatibilidad del fabricante, controladora RAID, NIC, HBA, BMC.
  • Configuración del power management: en BIOS (C-states, P-states, Turbo) y en el sistema operativo. En servidores transaccionales hace falta una power policy "performance"; en servidores en idle puede convenir lo contrario.
  • Verificación de certificaciones: VMware HCL, Microsoft WHQL, Red Hat HCL para las combinaciones que el cliente está usando.
  • Análisis del crash dump (Windows) o del kernel log (Linux) para identificar el componente exacto que falla.
FAQ

Las preguntas que más nos hacen.

En servidores con problemas de software, ¿trabajáis vosotros o hace falta AssistenzaServer.eu?

Depende de la causa raíz. Si el diagnóstico indica que el síntoma está relacionado con el hardware (driver del fabricante no alineado, firmware por actualizar, power management de BIOS) lo hacemos nosotros: es la zona de frontera hardware/software que nos compete de forma natural. Si la causa es puramente de sistemas (configuración aplicativa, parches del SO, networking software, seguridad) la referencia es el sitio gemelo AssistenzaServer.eu.

¿Actualizar los drivers lo resuelve siempre?

No, en algunos casos los drivers más recientes tienen bugs — sobre todo en hardware EOL, donde la matriz del fabricante deja de probar las combinaciones más antiguas. En estos sistemas, la versión estable certificada suele ser una versión N-1 o N-2 respecto a la última. Verificamos la matriz del fabricante caso por caso.

Crash dump de Windows o kernel log de Linux: ¿los pedís siempre?

Sí, son el documento más importante para el diagnóstico. En Windows: minidump en C:\Windows\Minidump (configurado por defecto). En Linux: /var/log/kern.log, journalctl -k, y los eventuales crash kdump en /var/crash. En ESXi: vmkernel.log, bundle vm-support. Sin estos documentos, el diagnóstico es más lento y menos preciso.