En muchas infraestructuras virtualizadas, la sensación de “lentitud” en una máquina virtual no siempre proviene de una falta de CPU o RAM, sino de cómo se gestionan los accesos al 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 evitar malentendidos: activar “emulación SSD” no convierte un HDD en NVMe. Lo que hace es exponer al invitado características del “tipo de medio”, como si fuera flash en lugar de rotacional, permitiendo que el sistema operativo tome decisiones más acertadas en planificación y mantenimiento (por ejemplo, sobre TRIM/discard, colas de E/S o rutinas de housekeeping). En entornos mixtos —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 parece torpe y otra que responde con mayor consistencia.
Qué es la emulación SSD y por qué importa (sin promesas mágicas)
En la práctica, Proxmox puede presentar un disco virtual como “no rotacional” ante el sistema operativo invitado. Esa señal influye en decisiones del propio SO (como la forma en que agrupa escrituras pequeñas o gestiona tareas de mantenimiento). Por ello se habla de “mejor rendimiento percibido”: se optimiza el comportamiento del stack, no la física del hardware.
Este ajuste es relevante por dos motivos:
- Sistemas operativos modernos cambian su comportamiento al detectar SSD (por ejemplo, políticas de mantenimiento, optimizaciones de escritura o reclamación de bloques).
- TRIM/discard (cuando aplica) permite liberar 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 muchas guías se quedan a medias: mezclan TRIM y discard como si fueran lo mismo.
- TRIM es el mecanismo por el cual el invitado (el sistema operativo de la VM) marca bloques como “ya no usados” en su sistema de archivos.
- Discard es la forma en que el hipervisor/backend recibe y procesa esas peticiones para que el almacenamiento subyacente pueda reutilizar esos bloques (o, en casos de thin provisioning, liberar espacio realmente).
En Linux, por ejemplo, es típico verificar soporte de discard y ejecutar reclamación con herramientas como lsblk (para ver capacidades) y fstrim (para emitir TRIM manualmente o mediante tareas programadas). Es importante porque activar discard sin soporte adecuado en el backend puede no aportar nada (incluso generar carga adicional en ciertos casos).
Lo que Proxmox permite (y lo que limita): controladoras y opciones “gris”
No todas las combinaciones de bus/controladora ofrecen las mismas capacidades. En Proxmox, es común encontrar que la opción de emulación SSD aparece deshabilitada dependiendo del tipo de dispositivo virtual seleccionado. En la comunidad se señala, por ejemplo, que con VirtIO Block puede no estar disponible, y que para funciones avanzadas es recomendable usar VirtIO SCSI, especialmente en modo virtio-scsi-single, para aislar colas y habilitar opciones de I/O more granular.
Operativamente, si buscamos rendimiento en workloads sensibles a latencia (como bases de datos, colas o microservicios con muchas escrituras pequeñas), suele ser recomendable revisar primero el bus/controladora antes de modificar flags.
Configuración recomendada: una ruta prudente y reversible
En entornos de producción, lo más sensato es adoptar un enfoque incremental: implementar cambios uno a uno, medir resultados, verificar y documentar.
1) Elegir bus/controladora adecuados
- Para rendimiento y compatibilidad, VirtIO SCSI es una opción habitual en Proxmox.
- Para activar funciones avanzadas como IOThreads, se recomienda usar virtio-scsi-single para evitar cuellos de botella compartidos.
2) Activar “SSD emulation” (ssd=1)
Esto hace que el invitado trate el disco como flash (a nivel lógico). Es útil especialmente cuando:
- El backend es SSD o NVMe real.
- Se busca que el sistema operativo aplique políticas más optimizadas para flash.
- Se desea gestionar TRIM/discard cuando sea compatible.
3) Activar “Discard” (discard=on) solo si el backend lo soporta bien
Es relevante en casos como:
- Thin provisioning, donde liberar bloques también libera espacio físico.
- SSD, para mantener el rendimiento de manera sostenida.
4) IOThreads: separar la E/S para reducir contención
En práctica, IOThreads permite que múltiples procesos de E/S operen en paralelo sin congestionar un solo hilo/cola. Existen análisis y documentación que muestran mejoras en ciertos escenarios y profundidades de cola, aunque el impacto varía según la carga de trabajo (no es una solución mágica universal).
5) Modos de caché: rendimiento vs riesgo
Este aspecto requiere cuidado, pues implica un trade-off claro:
- Writeback puede reducir la latencia percibida, pero aumenta el riesgo ante cortes de energía si no se toman medidas (UPS, protección de almacenamiento, etc.). La mayoría de las discusiones técnicas advierten que las opciones más rápidas no siempre son las más seguras si el hardware no protege las escrituras en vuelo.
- Writethrough / sin caché / sincrónico directo priorizan la integridad, a costa de rendimiento.
En backend como ZFS, también puede advertirse sobre posibles dobles cachés (host + guest) si se combinan algunas opciones sin un diseño cuidado del camino de escritura.
Tabla rápida: qué activar según cada caso de uso
| Escenario típico | SSD emulation | Discard/TRIM | IOThreads | Cache recomendado (orientativo) |
|---|---|---|---|---|
| VM en SSD/NVMe, cargas generales | Sí | Sí (si el backend soporta) | Opcional | Conservador por defecto |
| Bases de datos con muchas escrituras pequeñas | Sí | Sí (si el backend lo soporta bien) | Sí | Valorar con cautela y pruebas |
| Backend HDD (rotacional) con objetivo de “consistencia” | Opcional | Normalmente no crítico | Opcional | Conservador |
| Thin provisioning y recuperación de espacio | Sí | Sí | Opcional | Según backend |
| ZFS enfocado en integridad | Sí (si aporta al guest) | Depende de versión/política | Opcional | Evitar dobles cachés sin justificación |
Nota editorial: La tabla es una guía de decisión. En producción, el criterio final son el backend, la UPS, las políticas de recuperación y pruebas con carga real.
Verificación: cómo comprobar que TRIM/discard funciona
Tras aplicar cambios, el enfoque profesional consiste en verificar “de extremo a extremo”:
- Desde el invitado (Linux): comprobar soporte de discard y ejecutar
fstrimpara confirmar si los bloques se liberan. - En general: asegurarse de que el sistema detecta el dispositivo como SSD (según herramientas del SO) y que la configuración persiste tras reinicios o migraciones.
En Windows, la validación pasa por verificar que la unidad aparece como SSD en los informes del sistema y que las funciones de optimización (que no confundir con desfragmentación) están activas.
Riesgos y matices importantes que conviene documentar
- No todos los backends implementan discard de la misma forma: habilitarlo “por costumbre” no siempre trae beneficios.
- Cambiar parámetros de disco en VMs existentes debe hacerse con ventana de mantenimiento, respaldo y plan de rollback.
- Passthrough (asignación directa de disco) puede ser la opción adecuada cuando se requiere exposición nativa y latencia mínima, pero reduce la flexibilidad (ejemplo, migración) y requiere disciplina operativa.
- El rendimiento “percibido” se mejora mediante señalización y gestión, no por cambios en el soporte físico.
Preguntas frecuentes
¿Qué hace exactamente “emulación SSD” en Proxmox y por qué puede acelerar una VM?
Hace que el sistema operativo invitado gestione el disco virtual como una unidad SSD, lo cual puede mejorar la planificación de I/O y mantenimiento del sistema, además de facilitar el uso de TRIM/discard cuando el backend lo soporta.
¿Cuándo merece la pena activar discard/TRIM en Proxmox para liberar espacio?
Especialmente útil en almacenamiento thin-provisioned o cuando se desea que el backend reutilice bloques liberados por el sistema de archivos. Es recomendable verificar soporte en el backend y en el invitado primero.
¿Cuál es la mejor controladora para usar SSD emulation e IOThreads en Proxmox?
En entornos que exigen rendimiento y funciones avanzadas, VirtIO SCSI (y en algunos casos virtio-scsi-single) es habitual, por compatibilidad y control del camino de E/S, frente a configuraciones con opciones limitadas.
¿Es seguro activar cache writeback para máximo rendimiento en Proxmox?
Depende del entorno: protección eléctrica (UPS), garantías del almacenamiento y tolerancia al riesgo. Puede mejorar el rendimiento, pero existen debates que advierten contra pérdidas ante cortes si el sistema no está preparado adecuadamente.