En entornos Proxmox VE, el “rendimiento” de una máquina virtual rara vez depende de un único factor. Con frecuencia es el resultado de pequeñas decisiones en la pila de almacenamiento: el tipo de controlador virtual, cómo se presenta el disco al sistema operativo invitado, si se permite el descarte de bloques (TRIM/UNMAP) y si se habilitan hilos de E/S dedicados para evitar cuellos de botella.
Entre esos ajustes, SSD Emulation (marcar el disco virtual como “SSD” para el invitado) suele generar dudas porque se presta a malentendidos. No convierte un HDD en NVMe por arte de magia. Lo que hace, en esencia, es modificar la “señal” que recibe el sistema operativo invitado sobre el tipo de medio, para que adopte políticas más adecuadas (planificación de E/S, mantenimiento interno y, en algunos casos, comportamiento de optimización en Windows).
La clave, para administradores de sistemas, es entender qué ajustes son “seguros por defecto”, cuáles dependen del backend (ZFS, LVM-thin, Ceph, NFS/iSCSI) y cómo verificar que la cadena TRIM/UNMAP funciona de extremo a extremo.
Qué es realmente SSD Emulation y por qué se usa en Proxmox
Proxmox permite activar el flag ssd=1 por disco. Con ello, el invitado “ve” el dispositivo como no rotacional, lo que puede influir en cómo el sistema operativo trata el volumen (por ejemplo, decisiones de scheduler, mantenimiento y optimizaciones). En la práctica, su utilidad es más evidente en algunos invitados Windows, que ajustan tareas de “Optimizar unidades” en función de si detectan SSD o HDD.
Lo importante es el matiz operativo:
- SSD Emulation no añade IOPS físicas si el backend es lento.
- Sí puede mejorar la “respuesta percibida” al evitar comportamientos pensados para discos mecánicos.
- Se vuelve más relevante cuando se acompaña de discard/TRIM y de una configuración VirtIO-SCSI adecuada.
TRIM, discard y thin provisioning: el trío que sí puede devolver espacio y rendimiento
En almacenamiento moderno, TRIM/UNMAP es el mecanismo que permite indicar qué bloques ya no se usan. En Linux, por ejemplo, fstrim descarta bloques libres de un sistema de ficheros montado, algo útil para SSD y también para almacenamiento aprovisionado de forma fina (thin provisioning). En SCSI, el concepto suele materializarse como UNMAP.
En el mundo virtualizado, hay tres piezas:
- El invitado debe ser capaz de emitir TRIM/UNMAP (o ejecutar
fstrim). - El hipervisor debe permitirlo (en Proxmox,
discard=onen el disco). - El backend debe soportar la liberación real de bloques (thin LVM, ZFS con soporte de trim, Ceph/RBD con capacidades equivalentes, etc.).
Si falla cualquiera de esas piezas, el “TRIM” puede quedarse en un gesto simbólico (sin recuperación real de espacio, o sin beneficios sostenidos).
Controlador de disco y cola de E/S: por qué VirtIO-SCSI suele ser el punto de partida
Para cargas modernas, Proxmox suele recomendar VirtIO por su menor overhead. Pero, a nivel de tunning, hay un detalle que marca diferencia: la opción de IO Thread por disco.
En Proxmox, la selección de VirtIO SCSI single (en lugar de otras variantes) facilita habilitar IO threads para el disco. Esto puede ayudar en escenarios donde el hilo principal de QEMU se convierte en cuello de botella, especialmente con I/O concurrente (bases de datos, colas, microservicios con muchas escrituras pequeñas).
También conviene recordar una nota relevante para evitar configuraciones “a medias”: en la documentación de Proxmox se menciona que SSD emulation no está soportada en discos VirtIO Block (virtio-blk), lo que de facto empuja a muchos administradores a estandarizar con VirtIO-SCSI cuando quieren combinar ssd=1 + discard + iothread.
Ajustes recomendados para administradores: una receta prudente y verificable
1) Habilitar SSD Emulation y discard en el disco
La forma más limpia es hacerlo desde la UI (Hardware → Disco → Editar) o desde CLI. En CLI, la idea es añadir parámetros al “disk spec” de la VM.
Ejemplo orientativo (el formato exacto depende del bus y del storage):
# Ejemplo: activar SSD emulation y discard en un disco SCSI
qm set <VMID> --scsi0 <storage>:vm-<VMID>-disk-0,ssd=1,discard=on
Lenguaje del código: HTML, XML (xml)2) Activar IO thread por disco (cuando aplique)
Si el perfil de carga es paralelo (varias colas, muchas operaciones pequeñas), iothread=1 suele ser el siguiente paso lógico:
qm set <VMID> --scsi0 <storage>:vm-<VMID>-disk-0,ssd=1,discard=on,iothread=1
Lenguaje del código: HTML, XML (xml)Y, si se busca coherencia, conviene revisar que el controlador SCSI de la VM sea el adecuado (por ejemplo, VirtIO-SCSI single):
qm set <VMID> --scsihw virtio-scsi-single
Lenguaje del código: HTML, XML (xml)3) Elegir un cache mode sensato
Aquí no hay una respuesta universal: depende de la protección ante cortes de energía (UPS, controladora con caché protegida, etc.) y del backend. Aun así, muchos administradores usan como base cache=none para evitar doble caché y apoyarse en flush/ordering correctos, y sólo pasan a writeback cuando tienen garantías operativas.
Ejemplo:
qm set <VMID> --scsi0 <storage>:vm-<VMID>-disk-0,ssd=1,discard=on,iothread=1,cache=none
Lenguaje del código: HTML, XML (xml)4) Ajustar AIO en hosts Linux modernos
Proxmox expone opciones como aio=native, aio=threads y aio=io_uring (si el stack lo soporta). Para administradores, lo relevante es que AIO puede cambiar el perfil de latencia y CPU, por lo que debe medirse con el workload real.
Tabla rápida: qué activar según el caso de uso
| Escenario de VM | Ajustes recomendados | Comentario operativo |
|---|---|---|
| Windows con tareas de “Optimizar unidades” mal detectadas | ssd=1 | Ayuda a que el invitado aplique políticas coherentes con SSD. |
| Linux con discos thin (LVM-thin, etc.) y crecimiento de consumo | discard=on + fstrim programado | Puede recuperar espacio real si el backend soporta “hole punching/unmap”. |
| VM con muchas escrituras pequeñas y concurrencia | virtio-scsi-single + iothread=1 | Reduce contención en el hilo principal de QEMU en ciertos perfiles. |
| Backend HDD y latencia alta | ssd=1 (opcional) + tuning conservador | Mejora “señal”, pero no crea rendimiento físico: medir expectativas. |
Verificación: cómo comprobar que TRIM/UNMAP “pasa” de verdad
Para administradores, la verificación es obligatoria, especialmente en producción:
En Linux invitado
- Comprobar si el dispositivo expone descarte:
lsblk --discard
- Ejecutar TRIM manual y observar salida:
fstrim -av
Si fstrim devuelve bytes descartados y el dispositivo muestra valores no nulos en columnas de discard, la probabilidad de que la cadena esté bien configurada sube de forma significativa (aunque el backend puede tener particularidades).
En Windows invitado
- Revisar que el disco se trate como SSD cuando corresponde y que la programación de “Optimizar” aplique TRIM en lugar de desfragmentación en perfiles inadecuados (algo que SSD Emulation puede ayudar a normalizar).
Riesgos y buenas prácticas en Proxmox: lo que suele evitar sustos
- Cambios en discos virtuales en producción: incluso ajustes “menores” como
discard=ono cambios de controlador deberían hacerse con ventana de mantenimiento o, como mínimo, con snapshot/backup verificado. - Backend primero, tuning después: si el almacenamiento físico es el cuello de botella, SSD Emulation será cosmética. Antes de tocar flags, conviene medir (iostat/fio) y entender latencias base.
- Evitar “optimización por acumulación”: activar
ssd=1,discard=on,iothread=1,writeback,io_uringde golpe dificulta atribuir mejoras o regresiones. Mejor aplicar por fases y medir.
Conclusión
SSD Emulation en Proxmox VE es una herramienta de administración útil cuando se entiende como lo que es: un mecanismo de señalización al invitado, no un sustituto de hardware. Su valor real suele aparecer cuando se combina con una arquitectura coherente: VirtIO-SCSI, discard/TRIM correctamente encadenado y IO threads en cargas concurrentes. Para equipos de sistemas, la diferencia no está en “activar el check”, sino en validar el end-to-end y mantener una disciplina de cambios medibles y reversibles.
