En muchas infraestructuras virtualizadas, la sensación de “lentitud” en una máquina virtual no siempre viene de una falta de CPU o RAM, sino de cómo se están gestionando los accesos a disco. En Proxmox VE, uno de los ajustes más malinterpretados —y a la vez más útiles cuando se aplica con criterio— es la emulación de SSD: una opción que hace que el sistema operativo invitado vea el disco virtual como si fuera una unidad de estado sólido.

La clave está en no caer en el titular fácil: activar “SSD emulation” no convierte un HDD en NVMe. Lo que hace es exponer al invitado características del “tipo de medio” (flash vs rotacional) y, con ello, permitir que el sistema operativo tome decisiones más adecuadas de planificación y mantenimiento (por ejemplo, sobre TRIM/discard, colas de E/S o ciertas rutinas de housekeeping). En entornos mixtos —almacenamiento con SSD y HDD coexistiendo, o backends robustos con capas de thin provisioning— este “pequeño flag” puede marcar la diferencia entre una VM que se siente torpe y otra que responde con mayor consistencia.

Qué es la emulación de SSD y por qué importa (sin promesas mágicas)

En términos prácticos, Proxmox puede presentar un disco virtual como “no rotacional” ante el sistema operativo invitado. Esa señal influye en decisiones del propio SO (por ejemplo, cómo agrupa escrituras pequeñas o cómo gestiona operaciones de mantenimiento). De ahí que se hable de “mejor rendimiento percibido”: se optimiza el comportamiento del stack, no la física del soporte.

Este ajuste cobra relevancia por dos motivos:

1. Sistemas operativos modernos cambian su comportamiento cuando detectan SSD (por ejemplo, políticas de mantenimiento, optimizaciones de escritura o reclamación de bloques).
2. TRIM/discard (cuando procede) permite reclamar espacio en escenarios de thin provisioning y ayuda a mantener el rendimiento en SSDs, al reducir trabajo interno innecesario.

El triángulo que conviene entender: SSD emulation, TRIM y discard

Aquí es donde la mayoría de guías se quedan a medias: mezclan TRIM y discard como si fueran lo mismo.

• TRIM es el mecanismo por el que el invitado (el sistema operativo de la VM) marca bloques como “ya no usados” en su sistema de ficheros.
• Discard es la forma en la que el hipervisor/backend recibe y procesa esas peticiones para que el almacenamiento subyacente pueda reutilizar esos bloques (o, si hay thin provisioning, liberar espacio real).

En Linux, por ejemplo, una verificación típica es comprobar soporte de discard y ejecutar reclamación con herramientas como lsblk (para ver capacidades) y fstrim (para emitir TRIM manualmente o por tarea programada). Es un punto importante porque activar discard sin que el backend lo soporte bien puede no aportar nada (o incluso añadir carga de E/S en ciertos casos).

Lo que Proxmox permite (y lo que limita): controladora y opciones “gris”

No todas las combinaciones de bus/controladora exponen las mismas capacidades. En Proxmox es habitual encontrarse con que la opción de SSD emulation aparece deshabilitada dependiendo del tipo de dispositivo virtual elegido. En discusiones de la propia comunidad se señala, por ejemplo, que con VirtIO Block puede no estar disponible, y que para ciertas funciones conviene usar VirtIO SCSI, especialmente en modo virtio-scsi-single cuando se busca aislar colas y habilitar opciones relacionadas con el camino de I/O.

Dicho de forma operativa: si el objetivo es “hacerlo bien” para workloads sensibles a latencia (bases de datos, colas, microservicios con muchas escrituras pequeñas), suele tener sentido revisar bus/controladora antes de tocar flags.

Configuración recomendada: una ruta prudente y reversible

En un medio de producción, el enfoque sensato suele ser incremental: cambiar una cosa, medir, verificar y documentar.

1) Elegir bus/controladora adecuados

• Para rendimiento y compatibilidad, VirtIO SCSI suele ser una opción habitual en Proxmox.
• Si se quiere habilitar opciones avanzadas (como IOThreads, según configuración), se suele recomendar virtio-scsi-single para evitar cuellos compartidos entre discos.

2) Activar “SSD emulation” (ssd=1)

Esto hace que el invitado trate el dispositivo como flash (a nivel lógico). Es especialmente útil cuando:

• El backend es SSD/NVMe real.
• Se busca que el invitado aplique políticas más adecuadas para flash.
• Se quiere acompañar de TRIM/discard cuando procede.

3) Activar “Discard” (discard=on) solo si el backend lo justifica

Suele ser especialmente relevante en:

• Thin provisioning, donde liberar bloques puede liberar espacio real.
• SSDs, para ayudar a mantener rendimiento sostenido.

4) IOThreads: separar el I/O para reducir contención

En la práctica, IOThreads buscan que el procesamiento de E/S no se ahogue en un único hilo/cola cuando el patrón de acceso es paralelo. Hay análisis técnicos y documentación de proveedores que muestran mejoras en ciertos escenarios y profundidades de cola, aunque el impacto real depende del workload (no es una varita mágica universal).

5) Cache modes: rendimiento vs riesgo

Este punto requiere especial disciplina, porque aquí sí hay un “trade-off” claro.

• Writeback suele mejorar latencia percibida, pero puede aumentar riesgo ante cortes eléctricos si no hay garantías (UPS, almacenamiento con protección adecuada, etc.). En comparativas y debates técnicos se insiste en que las opciones “más rápidas” no siempre son las más seguras, especialmente si el hardware no protege escrituras en vuelo.
• Writethrough / no cache / direct sync tienden a priorizar consistencia, a costa de rendimiento.

Además, en backends como ZFS se suele advertir sobre posibles dobles cachés (host + guest) si se combinan ciertas opciones sin un diseño claro del camino de escritura.

Tabla rápida: qué activar según el caso de uso

Escenario típico	SSD emulation	Discard/TRIM	IOThreads	Cache recomendado (orientativo)
VM en SSD/NVMe, workloads generales	Sí	Sí (si procede)	Opcional	Conservador por defecto
Bases de datos con muchas escrituras pequeñas	Sí	Sí (si backend lo soporta bien)	Sí	Valorar con cautela y pruebas
Backend HDD (rotacional) y objetivo “consistencia”	Opcional	Normalmente no crítico	Opcional	Conservador
Thin provisioning y necesidad de recuperar espacio	Sí	Sí	Opcional	Según backend
ZFS con diseño centrado en integridad	Sí (si aporta al guest)	Depende de versión/política	Opcional	Evitar dobles cachés sin justificar

Nota editorial: la tabla es una guía de decisión. En producción, el criterio manda: backend, UPS, políticas de recuperación, y pruebas con carga real.

Verificación: cómo saber si TRIM/discard está funcionando

Una vez aplicados cambios, el enfoque profesional es verificar “end to end”:

• En el invitado (Linux): comprobar capacidades de discard y ejecutar fstrim para ver si se reclaman bloques.
• En general: confirmar que el invitado detecta el dispositivo como SSD (según herramientas del propio SO) y que la configuración persiste tras reinicios/migraciones.

En Windows, la validación suele pasar por comprobar que el sistema identifica la unidad como SSD y que las optimizaciones correspondientes están activas (sin confundir “desfragmentación” con “optimización” en SSD, que es otro debate frecuente).

Riesgos y matices que conviene dejar por escrito

1. No todos los backends implementan discard igual: habilitarlo “por costumbre” no siempre aporta beneficios.
2. Cambiar parámetros de disco en VMs existentes debe hacerse con ventana de mantenimiento, backup y plan de rollback.
3. Passthrough (asignación directa de disco) puede ser la opción adecuada cuando se necesita exposición nativa y latencia mínima, pero reduce flexibilidad (por ejemplo, migración) y exige más disciplina operativa.
4. El rendimiento “percibido” mejora por señalización y gestión, no porque el soporte físico cambie.

Preguntas frecuentes

¿Qué hace exactamente “SSD emulation” en Proxmox y por qué puede acelerar una VM?
Hace que el sistema operativo invitado trate el disco virtual como una unidad no rotacional (tipo SSD). Ese cambio puede mejorar la forma en que el invitado planifica I/O y mantenimiento, y facilita usar TRIM/discard cuando el backend lo soporta.

¿Cuándo conviene activar discard/TRIM en Proxmox para recuperar espacio real?
Suele ser especialmente útil con almacenamiento thin-provisioned o cuando se quiere que el backend pueda reutilizar bloques liberados por el sistema de ficheros. Antes de activarlo, conviene confirmar soporte real en el backend y verificar con herramientas del invitado.

¿Qué controladora es mejor para usar SSD emulation e IOThreads en Proxmox?
En entornos donde se busca rendimiento y opciones avanzadas, VirtIO SCSI (y en algunos diseños, virtio-scsi-single) suele ser la elección habitual por compatibilidad y control del camino de I/O, frente a configuraciones donde ciertas opciones aparecen limitadas.

¿Activar writeback cache es “seguro” si se busca máximo rendimiento en Proxmox?
Depende del diseño: protección eléctrica (UPS), garantías del almacenamiento y tolerancia al riesgo. Puede mejorar rendimiento, pero hay debates técnicos que advierten sobre riesgos de pérdida ante cortes si el sistema no está preparado.