Cuando empecé a usar Proxmox VE de forma seria en el homelab, aceptaba casi siempre las configuraciones por defecto de las máquinas virtuales. Si la VM arrancaba y el rendimiento parecía “suficientemente bueno” seguía adelante sin darle demasiadas vueltas...
Con el tiempo, descubrí algo importante: muchas de las opciones por defecto no son necesariamente las mejores para rendimiento, eficiencia o escalabilidad.
Lo interesante es que la mayoría de mejoras vienen simplemente de:
- cambiar un desplegable,
- activar una casilla,
- o elegir un controlador diferente.
Y aun así, el impacto puede ser enorme.
En este artículo voy a explicar las configuraciones de disco que utilizo actualmente en prácticamente todas mis VMs de Proxmox y por qué merece la pena cambiarlas.
¿Por qué importan tanto las configuraciones de disco?
Cuando hablamos de virtualización, existe una capa intermedia entre:
- el sistema operativo invitado,
- el hipervisor,
- y el almacenamiento físico.
Cada decisión que tomamos en esa cadena afecta directamente a:
- la latencia
- el throughput
- el consumo de CPU
- la eficiencia del almacenamiento
- la estabilidad general
Esto se vuelve especialmente importante cuando trabajamos con:
- NVMe
- ZFS
- Ceph
- SSD empresariales
- redes de 10 GbE
- Kubernetes
- Docker
- Bases de datos
Muchas veces el cuello de botella no está realmente en el hardware, sino en cómo está configurada la VM.
1. Usar discos SCSI con VirtIO SCSI Single
Este es probablemente el cambio más importante que hago en cualquier VM nueva.
Especialmente si vienes de VMware, Hyper-V o VirtualBox, es común terminar con configuraciones heredadas como:
- IDE
- SATA
- VirtIO Block
Actualmente mi configuración estándar es:
- Bus del disco:
SCSI - Controladora SCSI:
VirtIO SCSI Single
¿Por qué no VirtIO Block?
Hace años mucha gente recomendaba VirtIO Block como la opción más rápida. Sin embargo, VirtIO SCSI ha madurado muchísimo y hoy ofrece:
- mejor escalabilidad
- mejor manejo de IO paralelo
- compatibilidad superior
- soporte para más funcionalidades avanzadas
- mejor integración con IOThread
VirtIO SCSI vs VirtIO SCSI Single
Aquí hay una diferencia que muchos pasan por alto.
VirtIO SCSI
Usa una controladora compartida para varios discos virtuales.
VirtIO SCSI Single
Crea una controladora dedicada para cada disco.
Esto reduce contención y mejora el paralelismo del IO.
Se nota especialmente en:
- bases de datos
- nodos Kubernetes
- hosts Docker
- VMs con varios discos
- workloads con mucho IO concurrente
2. Activar IOThread
Una vez utilizas VirtIO SCSI Single, aparece otra opción fundamental: IOThread.
Esta configuración permite que las operaciones de disco se ejecuten en un hilo dedicado independiente del hilo principal de QEMU.
En términos simples:
- el procesamiento del almacenamiento deja de bloquear otras tareas de la VM.
¿Qué ventajas tiene?
Con hardware moderno, especialmente NVMe y Ceph, el almacenamiento físico ya no suele ser el cuello de botella.
Por eso la sobrecarga del hipervisor se vuelve mucho más visible.
Activar IOThread ayuda a:
- mejorar la respuesta de la VM
- reducir latencias
- mejorar el rendimiento bajo carga
- manejar mejor IO paralelo
- reducir bloqueos internos
Hoy en día lo activo prácticamente siempre.
3. Activar Discard/TRIM
Esta es otra configuración crítica que mucha gente ignora.
Discard permite que el sistema operativo invitado informe al almacenamiento de qué bloques ya no se utilizan.
En otras palabras:
- cuando borras datos dentro de la VM,
- el backend realmente recupera ese espacio.
Sin esto, el almacenamiento sigue creyendo que esos bloques continúan ocupados.
¿Por qué es importante?
Especialmente en:
- thin provisioning
- Ceph
- LVM-Thin
- ZFS
- SSDs
- SANs
- NAS empresariales
Las ventajas son enormes:
- recuperación automática de espacio,
- mejor eficiencia
- menos desperdicio
- mejor comportamiento de SSD
- menor crecimiento innecesario de volúmenes
Requisitos importantes
Para que funcione correctamente:
- El backend debe soportar TRIM/UNMAP.
- Proxmox debe tener
Discardactivado. - El sistema operativo invitado debe soportarlo también.
En Linux normalmente funciona de forma transparente.
En Windows conviene verificar que TRIM esté habilitado.
4. Usar io_uring como motor Async IO
En Proxmox puedes elegir el motor de IO asíncrono:
- Native
- Threads
- io_uring
Actualmente io_uring es la mejor opción para kernels Linux modernos.
¿Qué es io_uring?
Es una interfaz moderna de IO asíncrono introducida en Linux para:
- reducir overhead
- mejorar throughput
- bajar latencia
- aprovechar mejor hardware NVMe
¿Dónde se nota?
Especialmente en:
- SSD/NVMe rápidos
- clusters Ceph
- entornos densos
- muchas VMs simultáneas
- cargas paralelas
La buena noticia es que en versiones modernas de Proxmox ya suele venir configurado por defecto.
Y sinceramente, normalmente funciona muy bien.
5. Elegir correctamente la caché del disco
La configuración de caché es una de las más malinterpretadas en Proxmox.
Las opciones más comunes suelen ser:
- No cache
- Write through
- Write back
- Direct sync
Mi configuración habitual actualmente es: No cache
¿Por qué uso No cache?
En infraestructuras modernas con:
- NVMe
- ZFS
- Ceph
- SSD rápidos
- almacenamiento distribuido
- sistemas con cachés inteligentes
No cache suele ofrecer:
- comportamiento más predecible
- menor riesgo de corrupción
- mejor integración con el backend
- menos doble caché
- mejor estabilidad
¿Qué problema tiene Write Back?
Write back es muy rápido porque usa RAM del host como buffer.
Pero también introduce riesgos:
- pérdida de energía
- kernel panic
- cuelgue del host
- apagados abruptos
Si el host cae antes de escribir los datos al disco, puede existir corrupción.
¿Cuándo sí usar Write Back?
Hay escenarios donde todavía tiene sentido.
Especialmente:
- discos mecánicos lentos
- NAS modestos
- hardware antiguo
- cargas pequeñas y bursty
Por ejemplo:
- pequeños servidores Linux
- hosts Docker ligeros
- logs
- instalaciones de paquetes
- pequeños servidores web
¿Dónde NO suele ser buena idea?
No suele ser ideal para:
- backups grandes
- bases de datos pesadas
- Plex transcoding
- rsync masivos
- grandes copias de archivos
Mi configuración estándar actual en Proxmox
Estas son las opciones que utilizo hoy en la mayoría de mis máquinas virtuales:
| Configuración | Valor recomendado | Motivo |
|---|---|---|
| Bus del disco | SCSI | Mejor rendimiento y compatibilidad moderna |
| Controladora SCSI | VirtIO SCSI Single | Mejor IO paralelo y compatibilidad con IOThread |
| IOThread | Activado | Menor contención y mejor respuesta |
| Discard/TRIM | Activado | Recuperación eficiente de espacio |
| Async IO | io_uring | Menor overhead y mejor rendimiento |
| Caché | No cache | Mayor estabilidad y comportamiento predecible |
¿Estas configuraciones sirven para todo?
No necesariamente.
Hay workloads específicos que pueden requerir tuning diferente:
- bases de datos críticas
- appliances virtuales
- VMs legacy
- almacenamiento HDD
- sistemas extremadamente pequeños
- aplicaciones con patrones de IO muy concretos
Pero para:
- homelab
- Kubernetes
- Docker
- servidores Linux
- Windows Server
- aplicaciones modernas
- virtualización general
Estas configuraciones suelen ofrecer resultados excelentes.
Conclusión
Proxmox ofrece muchísima flexibilidad, pero muchas veces dejamos configuraciones por defecto simplemente porque “funcionan”.
Sin embargo, pequeños cambios como:
- usar VirtIO SCSI Single
- activar IOThread
- habilitar Discard
- usar io_uring
- elegir correctamente la caché
pueden marcar una diferencia enorme en:
- rendimiento
- estabilidad
- eficiencia
- consumo de almacenamiento
Especialmente hoy, donde cada vez más gente ejecuta:
- clusters Kubernetes
- Ceph
- Docker
- IA local
- almacenamiento distribuido
- decenas de VMs simultáneas
Si has migrado desde VMware o tienes VMs antiguas, merece muchísimo la pena revisar estas configuraciones. Muchas veces el problema no está en el hardware. Está simplemente en cómo está configurada la máquina virtual.