Proxmox “qemu-img: Could not create”: permisos, rutas y soluciones de sistema de archivos que realmente funcionan

Qué significa realmente el error (y qué no)

Cuando Proxmox crea un disco de VM, normalmente invoca qemu-img (para imágenes basadas en archivo como qcow2/raw), o solicita a las herramientas de almacenamiento crear un dispositivo de bloque (zvol de ZFS, volumen lógico de LVM, RBD de Ceph). Si ese paso de creación falla, a menudo verás:

• “qemu-img: Could not create …”
• “Permission denied” (explícito, si tienes suerte)
• “No such file or directory” (problema de ruta o montaje)
• “Read-only file system” (sistema de archivos o export NFS montado en ro)
• “No space left on device” (bloques de datos, bloques de metadatos, inodos, metadatos de thin pool, o cuota)

Esto normalmente no es:

• No es un “bug aleatorio de Proxmox.” Esto casi siempre es determinista.
• No se arregla reiniciando pvedaemon “porque sí.” Reiniciar puede hacerte sentir productivo, eso sí.
• No se soluciona con chmod 777 en todo (a menos que tu objetivo sea crear incidentes futuros).

La mentalidad práctica: trátalo como una falla de escritura en almacenamiento. Tu trabajo es responder tres preguntas:

1. ¿Dónde está Proxmox intentando crear el disco?
2. ¿Quién lo escribe (proceso/usuario/mapeo UID), y ¿tiene derechos?
3. ¿Cuál es el estado del backing store (montado, escribible, sano, con espacio, soporta características)?

Una cita útil en operaciones: “Hope is not a strategy.” — General Gordon R. Sullivan. Cuando qemu-img falla, la esperanza es especialmente cara.

Broma #1: El almacenamiento es el único departamento donde “No puedo crear un archivo” se considera un mensaje de error detallado.

Guía rápida de diagnóstico (verifica primero/segundo/tercero)

Primero: confirma el almacenamiento objetivo y la ruta/dispositivo exacto

Desde el registro de tareas de Proxmox, encuentra el ID de almacenamiento y la ruta que intentó crear. Si usas storage tipo directory verás algo como /mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2. Si es ZFS/LVM, verás un zvol o nombre de LV.

Segundo: valida el montaje y la capacidad de escritura en un minuto

La mayoría de fallos “Could not create” son un montaje faltante, un punto de montaje que en realidad es el directorio vacío subyacente, o un sistema de archivos que se ha puesto en solo lectura por errores. Puedes detectar los tres rápidamente con findmnt, mount y una pequeña prueba de escritura.

Tercero: valida el espacio de la forma correcta (datos, inodos, metadatos thin, cuotas)

“Disco lleno” no es una sola cosa. Es: bloques, inodos, cuota ZFS/refquota, metadatos de LVM-thin, cuotas de proyecto, cuotas de NFS. Revisa los contadores relevantes para el tipo de almacenamiento.

Cuarto: verifica permisos e identidad (UID/GID, root_squash, ACLs)

En sistemas de archivos locales, Proxmox típicamente escribe como root (vía pvedaemon/pveproxy invocando herramientas). En NFS/CIFS puede ponerse extraño: root se convierte en nobody, la herencia de ACL hace algo “útil”, o SMB te mapea a un usuario distinto. Cuando huela a permisos, verifica con namei, stat y una prueba de escritura desde el host.

Quinto: revisa la configuración del plugin de almacenamiento y tipos de contenido

Tipos de contenido mal configurados (por ejemplo, “VZDump backup only” pero intentas almacenar imágenes), ruta equivocada, nombre de pool incorrecto, o configuración de storage obsoleta en un nodo del clúster, todo eso aparecerá como fallos de creación.

Hechos interesantes y contexto (por qué esto sigue pasando)

• Hecho 1: qemu-img es anterior a Proxmox y se usa ampliamente en stacks de virtualización. Proxmox suele ser solo el mensajero.
• Hecho 2: El storage “Directory” de Proxmox es engañosamente simple: es solo una ruta de sistema de archivos, lo que significa que los montajes y permisos son tu problema por diseño.
• Hecho 3: root_squash en NFS existe específicamente para evitar que root remoto sea root en el servidor. También es una de las tres principales razones por las que falla la creación de discos VM en NFS.
• Hecho 4: LVM-thin puede quedarse sin metadatos mientras aún tiene mucho espacio de datos. El error que ves suele mentir sobre qué está lleno.
• Hecho 5: ZFS puede fallar en las creaciones por cuotas, conflictos de reserva, o un pool que está técnicamente online pero sin espacio asignable debido a fragmentación y elecciones de recordsize.
• Hecho 6: Ext4 y XFS se comportan distinto cuando están “llenos”: el agotamiento de inodos es más común en ext4 con cargas de muchos archivos pequeños; XFS puede golpear límites de cuota de proyecto de formas sorprendentes.
• Hecho 7: AppArmor puede bloquear operaciones de QEMU aun cuando los permisos Unix parecen correctos, especialmente con puntos de montaje personalizados no cubiertos por los perfiles.
• Hecho 8: Un montaje faltante puede ser invisible si el directorio del punto de montaje existe. Escribirás en el sistema de archivos local y solo lo notarás cuando se llene. Esto ha causado incidentes reales en compañías respetables.

Diagnóstico orientado a tareas: comandos, salidas, decisiones

A continuación hay tareas prácticas. Cada una incluye el comando, un esbozo realista de la salida y la decisión que tomas. Ejecútalas desde el host de Proxmox que está fallando, no desde tu portátil, ni desde “el otro nodo que funciona”.

Task 1: Lee el log de tareas de Proxmox para conocer el objetivo real

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve1:0000A1B2:0001C3D4:676D1A2B:qmcreate:101:root@pam:
error: unable to create VM 101 - qemu-img: Could not create '/mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2': Permission denied

Qué significa: La ruta que falla es explícita. Eso es oro. Si el mensaje no muestra la ruta, mira el log de tarea completo en la GUI o en /var/log/pve/tasks.

Decisión: Copia la ruta exacta/ID de almacenamiento. Todo lo demás depende de eso.

Task 2: Confirma la definición de almacenamiento que Proxmox está usando

cr0x@server:~$ pvesm status
Name     Type     Status     Total      Used      Available  %
local    dir      active     98.00GB    12.10GB    80.90GB   12.35%
fastssd  dir      active     1.80TB     1.22TB     0.58TB    67.78%
zfspool  zfspool  active     3.50TB     2.10TB     1.40TB    60.00%

Qué significa: Proxmox cree que fastssd está activo. Eso no garantiza que esté montado correctamente o que sea escribible.

Decisión: Sigue con el diagnóstico. “Active” es necesario, no suficiente.

Task 3: Verifica que el montaje sea real (no un directorio vacío)

cr0x@server:~$ findmnt -T /mnt/pve/fastssd
TARGET           SOURCE        FSTYPE OPTIONS
/mnt/pve/fastssd /dev/sdb1     ext4   rw,relatime,errors=remount-ro

Qué significa: Bien: es un montaje real desde /dev/sdb1. Si esta salida está vacía, estás escribiendo en un directorio normal del sistema raíz.

Decisión: Si no está montado, arregla fstab/systemd mount y vuelve a montar antes de cualquier otra cosa.

Task 4: Comprueba si se silenció y quedó en solo lectura

cr0x@server:~$ mount | grep -E '/mnt/pve/fastssd| / '
/dev/sdb1 on /mnt/pve/fastssd type ext4 (ro,relatime,errors=remount-ro)
/dev/mapper/pve-root on / type ext4 (rw,relatime,errors=remount-ro)

Qué significa: El almacenamiento está montado ro. Proxmox fallará al crear cualquier cosa, y el error puede aparecer como “Permission denied” o “Read-only file system” según la ruta de código.

Decisión: Deja de intentar crear discos. Investiga la causa del error en el FS, ejecuta fsck (si es ext4), o arregla el problema subyacente, luego vuelve a montar en modo rw.

Task 5: Haz una prueba mínima de escritura desde el host (la única verdad)

cr0x@server:~$ touch /mnt/pve/fastssd/.pve-write-test && echo OK
touch: cannot touch '/mnt/pve/fastssd/.pve-write-test': Read-only file system

Qué significa: Esto no es un problema de permisos de Proxmox. Es “el sistema de archivos no es escribible”.

Decisión: Arregla el estado del montaje/FS primero. Los permisos son irrelevantes hasta que las escrituras funcionen.

Task 6: Comprueba espacio e inodos (sí, ambos)

cr0x@server:~$ df -h /mnt/pve/fastssd
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.8T     0 100% /mnt/pve/fastssd

cr0x@server:~$ df -i /mnt/pve/fastssd
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb1      122M     1.1M    121M    1% /mnt/pve/fastssd

Qué significa: Los bloques están llenos, los inodos están bien. Si los bloques estuvieran bien pero los inodos al 100%, verías fallos de creación similares.

Decisión: Libera espacio o amplía el sistema de archivos. No “intentes de nuevo” sin más. No mejorará.

Task 7: Confirma la propiedad del directorio y permisos de recorrido en la ruta completa

cr0x@server:~$ namei -l /mnt/pve/fastssd/images/101
f: /mnt/pve/fastssd/images/101
drwxr-xr-x root root /
drwxr-xr-x root root mnt
drwxr-xr-x root root pve
drwxr-x--- root root fastssd
drwxr-xr-x root root images
drwx------ 100000 100000 101

Qué significa: El directorio de la VM es propiedad de UID 100000, común cuando es un montaje compartido creado por otro sistema o cuando hay mapeos de espacio de nombres de usuario. También observa que fastssd es drwxr-x---; solo root y el grupo root pueden atravesarlo.

Decisión: Si Proxmox escribe como root, root puede atravesarlo; pero si algún componente pierde privilegios o usa IDs mapeadas, puede que necesites corregir la propiedad/ACLs. Si esto es NFS con root_squash, root no será root.

Task 8: Reproduce como “root” e interpreta correctamente errores de permiso

cr0x@server:~$ sudo -i
root@server:~# touch /mnt/pve/fastssd/images/101/.root-test
touch: cannot touch '/mnt/pve/fastssd/images/101/.root-test': Permission denied

Qué significa: Si incluso root local no puede escribir, entonces o:

• es un sistema de archivos remoto que mapea root a nobody (NFS root_squash),
• las ACLs deniegan escritura,
• existen atributos inmutables,
• o el sistema de archivos está montado con opciones restrictivas.

Decisión: Para NFS/CIFS, inspecciona las opciones de export/mount. Para FS local, revisa ACLs y atributos.

Task 9: Inspecciona ACLs y flags inmutables cuando los permisos “parecen correctos”

cr0x@server:~$ getfacl -p /mnt/pve/fastssd/images/101 | sed -n '1,25p'
# file: /mnt/pve/fastssd/images/101
# owner: 100000
# group: 100000
user::rwx
group::---
other::---

cr0x@server:~$ lsattr -d /mnt/pve/fastssd/images/101
-------------------P-- /mnt/pve/fastssd/images/101

Qué significa: Las ACLs aquí niegan completamente a grupo/otros. Eso está bien si el escritor coincide con el propietario. Pero si NFS aplasta root a nobody, no coincidirá. Los atributos parecen normales (sin la bandera i inmutable).

Decisión: Alinea la propiedad con la identidad efectiva del escritor, o ajusta las opciones de export y el comportamiento de montaje.

Task 10: Revisa opciones de montaje NFS y síntomas de root squashing

cr0x@server:~$ findmnt -T /mnt/pve/nfs-store -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET            SOURCE                    FSTYPE OPTIONS
/mnt/pve/nfs-store 10.0.20.10:/exports/pve nfs4   rw,relatime,vers=4.1,sec=sys,clientaddr=10.0.20.21

cr0x@server:~$ sudo -i
root@server:~# touch /mnt/pve/nfs-store/.nfs-root-test
touch: cannot touch '/mnt/pve/nfs-store/.nfs-root-test': Permission denied

root@server:~# stat -c '%u %g %n' /mnt/pve/nfs-store
65534 65534 /mnt/pve/nfs-store

Qué significa: UID/GID 65534 es el clásico mapeo “nobody/nogroup”. Esto sugiere fuertemente root_squash o mapeo anónimo en el servidor NFS.

Decisión: Arregla las exportaciones NFS: ajusta la propiedad en el servidor para que coincida con el UID mapeado, o modifica cuidadosamente las opciones de exportación para que Proxmox pueda escribir.

Task 11: Revisa la salud de LVM-thin (datos vs metadatos)

cr0x@server:~$ lvs -a -o +devices,lv_size,data_percent,metadata_percent,lv_attr vg0
  LV               VG  Attr       LSize   Data%  Meta%  Devices
  thinpool         vg0 twi-aotz--  900.00g  72.10  99.85 /dev/sdc3(0)
  thinpool_tmeta   vg0 ewi-aotz--    8.00g                 /dev/sdc3(230400)
  thinpool_tdata   vg0 ewi-aotz--  900.00g                 /dev/sdc3(4096)

Qué significa: Los datos están al 72%, los metadatos casi llenos. La creación fallará aunque “espacio” parezca disponible a simple vista.

Decisión: Extiende los metadatos del thinpool (y considera monitorización). No sigas reintentando crear VMs; solo llenarás los logs.

Task 12: Revisa salud del pool ZFS y restricciones de cuota

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint
NAME              USED  AVAIL  REFER  MOUNTPOINT
rpool             120G   80G    96K   /rpool
rpool/data        110G   80G    96K   /rpool/data
rpool/data/vm-101-disk-0  50G  0B     50G   -

cr0x@server:~$ zfs get -H -o property,value quota,refquota rpool/data
quota    none
refquota none

Qué significa: El zvol específico muestra 0B disponibles porque es un volumen y esta visualización puede confundir. La señal más importante es la disponibilidad del pool/dataset y las cuotas/reservas. Si AVAIL es baja o existen cuotas, la creación de zvol puede fallar.

Decisión: Si el pool está sano pero AVAIL es bajo o existen cuotas, libera espacio o ajusta cuota/refquota/reservation. También verifica ashift y fragmentación si frecuentemente trabajas al límite.

Task 13: Verifica tipos de contenido configurados en Proxmox (un fallo que parece de permisos)

cr0x@server:~$ grep -A4 -n '^dir: fastssd' /etc/pve/storage.cfg
12:dir: fastssd
13:        path /mnt/pve/fastssd
14:        content vztmpl,backup
15:        prune-backups keep-last=3

Qué significa: Este storage está configurado solo para plantillas y backups, no para imágenes de VM. Crear un disco allí fallará, a veces con mensajes confusos según el flujo.

Decisión: Añade images al tipo de contenido (y quizás iso) si este almacenamiento está destinado a discos de VM.

Task 14: Valida que la ruta de almacenamiento exista en este nodo (drift en el clúster)

cr0x@server:~$ ls -ld /mnt/pve/fastssd
ls: cannot access '/mnt/pve/fastssd': No such file or directory

cr0x@server:~$ pvecm status | sed -n '1,20p'
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Qué significa: En un clúster, /etc/pve/storage.cfg se comparte, pero los montajes no aparecen mágicamente en todos los nodos. Un nodo puede tener el storage configurado pero no presente realmente.

Decisión: Crea/monta la ruta de forma consistente en los nodos, o limita el storage a los nodos que realmente lo tienen.

Task 15: Comprueba AppArmor bloqueando QEMU en puntos de montaje poco comunes

cr0x@server:~$ dmesg | tail -n 20
[12345.678901] audit: type=1400 audit(1735212345.123:456): apparmor="DENIED" operation="open" profile="libvirt-2d7c3a1e-..." name="/mnt/pve/fastssd/images/101/vm-101-disk-0.qcow2" pid=3210 comm="qemu-img" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0

cr0x@server:~$ aa-status | sed -n '1,20p'
apparmor module is loaded.
45 profiles are loaded.

Qué significa: Los permisos Unix pueden ser perfectos y aun así recibirás “permission denied” si AppArmor bloquea el acceso. La línea de dmesg es la prueba definitiva.

Decisión: Ajusta el perfil correspondiente o asegúrate de usar rutas de almacenamiento esperadas. “Desactivar AppArmor” es un instrumento contundente; úsalo solo como diagnóstico corto, no como solución permanente.

Task 16: Verifica que montajes CIFS/SMB no estén mintiendo sobre permisos

cr0x@server:~$ findmnt -T /mnt/pve/smb-store -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET             SOURCE                       FSTYPE OPTIONS
/mnt/pve/smb-store  //nas01/proxmox             cifs   rw,relatime,vers=3.0,uid=0,gid=0,dir_mode=0755,file_mode=0644,nounix

cr0x@server:~$ sudo -i
root@server:~# touch /mnt/pve/smb-store/.smb-test && echo OK
touch: cannot touch '/mnt/pve/smb-store/.smb-test': Permission denied

Qué significa: CIFS puede presentar permisos que localmente parecen permisivos pero que el servidor rechaza. Lo que importa es la ACL del lado del servidor o el mapeo de usuario.

Decisión: Arregla permisos y credenciales del recurso compartido; considera NFS para imágenes de VM si quieres menos sorpresas semánticas.

Peculiaridades por tipo de almacenamiento: Directory, ZFS, LVM-thin, NFS, CIFS

Directory storage (respaldado por ruta): lo más simple y por eso lo más fácil de mal montar

El storage por directorio es literalmente “escribe archivos aquí.” Eso significa que qemu-img crea archivos qcow2/raw bajo path/images/<vmid>. Las fallas vienen de:

• Punto de montaje faltante; el punto existe como directorio vacío
• Sistema de archivos en solo lectura tras errores
• No queda espacio / agotamiento de inodos
• Desajuste de permisos/ACL en el directorio VMID o en sus padres
• AppArmor niega acceso a puntos de montaje no estándar

Opinión práctica: para directory storage, usa un punto de montaje dedicado bajo /mnt/pve/<storageid> y asegúrate de montarlo por systemd, no “que alguien lo monte después del arranque.” Los humanos no son procesos de arranque confiables.

ZFS zvol storage: rápido, consistente y alérgico a malas prácticas de capacidad

Los discos VM respaldados por ZFS suelen ser zvols. Las fallas de creación aparecen cuando:

• El pool tiene poco espacio disponible (ZFS necesita espacio “para respirar”; trabajar al 95% invita a latencias extrañas)
• Cuotas/refquotas/reservas del dataset impiden nuevos volúmenes
• El pool está degradado o suspendido (los errores de I/O se propagan de forma extraña)
• Conflictos de nombres (un zvol obsoleto existe de una creación previa fallida)

Consejo práctico: trata los pools ZFS como sistemas vivos. Monitoriza espacio, haz scrubs regularmente y no los uses como “otro disco ext4”.

LVM-thin: cuando los metadatos son tu disco real

LVM-thin está bien, hasta que no. La falla “Could not create” es clásica cuando la metadata del thin pool está llena. Los datos pueden estar al 40% y la metadata al 100%, y obtendrás fallos duros.

También vigila:

• Thin pool en modo solo lectura por errores
• Espacio libre del VG insuficiente para extender metadata
• Interacción de discard/TRIM con el almacenamiento subyacente

No “optimices” haciendo la metadata muy pequeña. Es como comprar un almacén y construir un archivador de un cajón para el inventario. Funciona hasta que guardas más de tres cosas.

NFS: teatro de permisos, con root_squash como estrella

NFS es común para almacenamiento compartido en Proxmox y también una fuente constante de “Permission denied.” Root squashing, desajustes de ACL o exportaciones montadas en un nodo pero no en otro son los más importantes.

Si usas NFS para imágenes de VM, asegúrate de que:

• La exportación esté diseñada para ello (baja latencia, comportamiento de sincronización correcto)
• El mapeo UID/GID sea deliberado y documentado
• Las opciones de montaje sean consistentes en todos los nodos

CIFS/SMB: aceptable para ISO y backups; imágenes de VM son una apuesta

Puedes hacer que SMB funcione, pero las semánticas difieren. Bloqueos, oplocks, mapeo de permisos y “parece escribible pero no lo es” son características habituales. Si debes usarlo, prueba qemu-img create bajo carga, no solo un touch.

Modelo de permisos en Proxmox: quién escribe qué y dónde

Cuando haces clic en botones en la UI, la petición pasa por los daemons de Proxmox que corren como root. El paso de creación del disco suele ejecutarse como root en el host. Eso significa:

• En sistemas de archivos locales, los permisos Unix normalmente no son el problema a menos que los hayas endurecido agresivamente o hayas usado ACLs.
• En NFS, root puede no ser root en el servidor. root_squash convierte “root” en un UID anónimo, que entonces no puede crear archivos en directorios propiedad de usuarios reales.
• En CIFS, root puede mapearse a un usuario del share que quizá no tenga permiso de escritura.
• En entornos clusterizados, la configuración se comparte pero los montajes no. El nodo A puede escribir; el nodo B no; la GUI se ve igual hasta que deja de funcionar.

Una regla práctica: siempre prueba escrituras desde el host en el directorio exacto que usa Proxmox. Si touch falla, qemu-img fallará. Si touch funciona pero qemu-img falla, ahora estás en territorio de “AppArmor / tipo de contenido / soporte de características / detalles del plugin”.

Broma #2: “Permission denied” es la forma que tiene el sistema de decir: “He oído tu petición y elijo la violencia”.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “No such file or directory” para una ruta bajo /mnt/pve/…

Causa raíz: El punto de montaje no existe en este nodo, o el almacenamiento no está montado, o el árbol de directorios (images/<vmid>) no se creó por fallos previos.

Solución: Crea el directorio del punto de montaje, asegura que el sistema de archivos se monte al arranque y verifica con findmnt -T. Luego reintenta la creación.

2) Síntoma: Proxmox muestra storage “active”, pero la creación falla al instante

Causa raíz: Las comprobaciones de estado del storage pueden ser superficiales; un montaje obsoleto o un directorio subyacente pueden seguir apareciendo “active”.

Solución: Valida que el montaje sea real y escribible: findmnt + prueba touch en la ruta exacta.

3) Síntoma: “Permission denied” en NFS, incluso como root

Causa raíz: root_squash de NFS o mapeo anónimo de UID; los permisos de export no permiten que el UID mapeado escriba.

Solución: Alinea la propiedad en el servidor con el UID/GID mapeado, o ajusta las opciones de exportación y el modelo de seguridad. Verifica con stat mostrando UID/GID y una prueba de escritura.

4) Síntoma: “Read-only file system” de repente en ext4 local

Causa raíz: ext4 se remonta en solo lectura tras detectar errores en el sistema de archivos (a menudo por problemas de disco o apagado inseguro).

Solución: Revisa logs, programa downtime, ejecuta fsck en el dispositivo de bloque, arregla problemas hardware subyacentes y vuelve a montar en modo rw.

5) Síntoma: Mucho “espacio libre”, pero no se puede crear en LVM-thin

Causa raíz: Metadatos del thin pool llenos, o thin pool en estado de error.

Solución: Revisa lvs en metadata_percent. Extiende metadata y considera habilitar monitorización/autoextend.

6) Síntoma: La creación falla en un nodo del clúster pero funciona en otro

Causa raíz: Montaje o credenciales difieren por nodo; la configuración de storage se comparte pero los montajes y secretos pueden no hacerlo.

Solución: Estandariza montajes y opciones en los nodos. Para NFS/CIFS, asegura unidades de montaje y archivos de credenciales idénticos.

7) Síntoma: “Permission denied”, pero los permisos Unix parecen correctos

Causa raíz: Denegación de AppArmor, SELinux (menos común en Proxmox por defecto), o ACLs.

Solución: Inspecciona dmesg por denegaciones de AppArmor; ajusta el perfil o la ruta de almacenamiento. Revisa getfacl.

8) Síntoma: Falla solo para qcow2, raw funciona (o viceversa)

Causa raíz: Características del sistema de archivos u opciones de montaje interfieren (por ejemplo, CIFS “nobrl”/comportamiento de locking), o expectativas de la cadena de herramientas.

Solución: Prefiere raw en dispositivos de bloque (zvol/LV). Para shares en red, prueba bajo carga real; replantea la elección de almacenamiento para imágenes de VM.

9) Síntoma: “Could not create” al seleccionar un storage marcado como “backup-only”

Causa raíz: Los tipos de contenido del storage no incluyen images.

Solución: Actualiza /etc/pve/storage.cfg para incluir images en ese storage (o selecciona el storage correcto).

10) Síntoma: “No space left on device” pero df muestra espacio

Causa raíz: Inodos agotados, cuota alcanzada, cuota de proyecto, metadatos thin llenos, o cuota/refquota/reserva de ZFS.

Solución: Revisa el contador relevante para el tipo de almacenamiento: df -i, cuota ZFS, metadatos LVM, herramientas de cuota.

Tres micro-historias corporativas (cómo falla esto en la vida real)

Micro-historia 1: La suposición equivocada (storage “active” ≠ storage montado)

El entorno parecía ordenado: un pequeño clúster Proxmox, un storage directory “fastssd” y un puñado de nuevas VMs necesarias antes del almuerzo. El ingeniero vio fastssd marcado como “active” en la UI y asumió que estaba montado y sano. Suposición razonable. Incorrecta.

Un nodo se había reiniciado la noche anterior tras una actualización del kernel. La unidad de montaje no volvió porque dependía de una ruta de dispositivo que cambió. El punto de montaje seguía existiendo como directorio, así que todo parecía normal. Proxmox intentó crear imágenes bajo /mnt/pve/fastssd—que ahora era solo un directorio en el sistema raíz.

La creación falló con qemu-img: Could not create de forma intermitente mientras el sistema raíz se llenaba. Mientras tanto, otros servicios empezaron a fallar en formas no relacionadas: las actualizaciones de paquetes murieron, los logs no se podían volcar y de repente el canal de incidentes tenía tres “causas raíz” propuestas.

La solución fue dolorosamente simple: corregir la unidad de montaje para usar un identificador estable, montar el sistema de archivos y limpiar las imágenes parciales escritas en el lugar equivocado. La mejora real fue procedimental: tras ese incidente, hicieron que “findmnt -T la ruta objetivo” fuera parte de cada triage de storage. Evitó una repetición en semanas—porque la misma falla volvió a intentar ocurrir.

Micro-historia 2: La optimización que salió mal (metadata thin diminuta)

Otro equipo quería más espacio utilizable en su pool LVM-thin. Leyeron lo justo para estar peligrosos y decidieron que la metadata era “overhead”. Así que reconstruyeron el thin pool con un volumen de metadata más pequeño. El primer día todo parecía genial: más gigabytes disponibles, menos “desperdicio”, puntos extra en la reunión de infraestructura.

Meses después, el equipo de plataforma empezó a ver fallos esporádicos al aprovisionar VMs. No era consistente. No era predecible. Y el error era el usualmente insultantemente vago “qemu-img could not create” al crear discos en el thin pool.

El uso de datos estaba bien. El pool no estaba lleno. Pero la metadata sí. Snapshots, clones y churn la habían consumido. Cuando la metadata llega al límite, el aprovisionamiento thin deja de ser thin y se vuelve frágil. Los sistemas no se degradaron gradualmente; simplemente dejaron de crear nuevos volúmenes.

Lo arreglaron extendiendo la metadata y activando monitorización. Pero la lección real fue cultural: optimizar por una métrica visible (espacio de datos libre) ignorando la metadata es un clásico “victoria en la hoja de cálculo, pérdida en producción.” Después estandarizaron tamaños de pool y alertaron sobre metadata_percent. No fue emocionante, pero fue estable.

Micro-historia 3: La práctica aburrida que salvó el día (pruebas de escritura y montajes uniformes)

Un entorno empresarial tenía una regla que sonaba casi infantil: cada nodo debía pasar una “smoke test” de almacenamiento estándar después del reinicio. Comprobaba que cada punto de montaje de Proxmox existiera, estuviera montado y fuera escribible. Incluso creaba y eliminaba un pequeño archivo en el directorio exacto que usa Proxmox.

Durante un mantenimiento rutinario, se actualizó un servidor NFS. Una exportación volvió con una política modificada: root ahora era squashado donde antes no lo era. Desde la perspectiva de seguridad, el cambio era defendible. Operativamente, significaba que Proxmox ya no podía crear discos VM en esa exportación.

La prueba de humo post-reinicio falló inmediatamente en varios nodos, antes de que nadie intentara crear una VM. El equipo no descubrió el problema durante un flujo visible para clientes. Lo descubrieron en una comprobación controlada, luego arreglaron el mapeo de propiedad de la exportación y lo documentaron.

Sin drama. Sin alertas nocturnas. Sin “funcionaba ayer.” Solo una comprobación aburrida que evitó un incidente emocionante. En producción, lo aburrido es el producto premium.

Listas de verificación / plan paso a paso (haz esto, no magia)

Paso a paso: cuando encuentres “qemu-img: Could not create”

1. Captura la ruta/dispositivo exacto que falla desde el log de tareas de Proxmox. No la parafrasees.
2. Identifica el tipo de almacenamiento: Directory, ZFS, LVM-thin, NFS, CIFS, Ceph. Usa pvesm status y /etc/pve/storage.cfg.
3. Saneamiento de montaje (directory/NFS/CIFS):
   • findmnt -T <path> debe mostrar una fuente y fstype esperados.
   • mount debe mostrarlo como rw (a menos que sea intencionalmente ro).
4. Prueba de escritura en el directorio exacto:
   • touch y luego eliminar. Si falla, detente y arregla eso primero.
5. Sanidad de capacidad:
   • Directory: df -h y df -i
   • LVM-thin: lvs data_percent + metadata_percent
   • ZFS: zfs list y zfs get quota,refquota,reservation
6. Sanidad de permisos:
   • namei -l en la ruta completa
   • getfacl si hay ACLs
   • En NFS, confirma mapeo de UID con stat
7. Sanidad de capas de seguridad:
   • dmesg para denegaciones de AppArmor
   • aa-status para confirmar perfiles activos
8. Sanidad de configuración de Proxmox:
   • Tipos de contenido del storage incluyen images
   • El storage está habilitado en el nodo que crea la VM
9. Reintentar una vez después de arreglar la causa raíz. Si falla otra vez, captura logs y escala de forma metódica. No hagas click-spam.

Checklist operacional: prevenir repeticiones

• Montajes definidos con identificadores estables (UUIDs o /dev/disk/by-id), no rutas volátiles /dev/sdX.
• Unidades systemd de montaje o entradas en fstab probadas tras reinicio.
• Alertas sobre: eventos de remonte en solo lectura, poco espacio, agotamiento de inodos, metadatos LVM-thin, capacidad del pool ZFS.
• Opciones de montaje consistentes entre nodos del clúster para almacenamiento compartido.
• Una pequeña prueba de humo post-reinicio (montaje + write + delete) para cada ruta de almacenamiento de Proxmox.
• Políticas de export NFS documentadas: root_squash, anonuid/anongid, modelo de propiedad.

Preguntas frecuentes

1) ¿Por qué Proxmox dice “qemu-img could not create” cuando el problema real son permisos NFS?

Porque qemu-img es la herramienta que intenta crear el archivo. NFS rechaza la escritura y qemu-img informa el fallo. Siempre correlaciona con las opciones de montaje y el mapeo de UID.

2) El storage aparece “active” en Proxmox—¿no significa eso que está montado y escribible?

No. Normalmente significa que el plugin de storage de Proxmox ve la ruta o el backend responde. Un punto de montaje faltante puede seguir “existiendo” y engañar a comprobaciones superficiales.

3) ¿Cuál es la forma más rápida de detectar un montaje faltante versus un problema de permisos?

findmnt -T <path> más un touch <path>/.test. Si findmnt está vacío, es un problema de montaje. Si touch falla, lee el error exacto.

4) ¿Por qué root puede recibir “Permission denied” en NFS?

Porque en el servidor, root puede mapearse a un UID anónimo (root_squash). Ese UID puede no ser el propietario del directorio y puede no tener permiso de escritura.

5) ¿Puedo arreglar esto con chmod 777 en la ruta de almacenamiento?

A veces “funciona”, y eso es exactamente lo peligroso: oculta problemas de identidad/mapeo y amplía el radio de impacto. Arregla la propiedad, las ACLs o la política de exportación en su lugar.

6) ¿Y si el error ocurre solo en un nodo del clúster?

Asume montajes o credenciales específicas del nodo. Valida la misma ruta de almacenamiento en ese nodo con findmnt y pruebas de escritura. La configuración del clúster se comparte; los montajes no.

7) ¿Cómo detecto si es metadata de LVM-thin y no espacio en disco?

Revisa lvs y mira metadata_percent. Si está cerca del 100%, ahí está el problema.

8) ¿Cuándo debo sospechar de AppArmor?

Cuando los permisos y las pruebas de escritura funcionan, pero qemu-img sigue fallando—o cuando dmesg muestra líneas AppArmor “DENIED” que referencian la ruta del disco.

9) ¿Es buena idea usar CIFS/SMB para discos de VM?

PUEDE funcionar, pero es menos predecible que NFS para imágenes de VM debido a semánticas de permisos y locking. Muchos equipos usan SMB para ISOs/backups y mantienen discos VM en bloque o NFS.

10) ¿Cuál es la forma más limpia de evitar “escrituras faltantes que van al sistema raíz”?

Usa automounts de systemd o unidades de montaje estrictas y considera hacer el punto de montaje no escribible hasta que esté montado. Al menos, alerta sobre crecimiento inesperado en el filesystem raíz.

Conclusión: pasos siguientes que evitan la repetición

El error “qemu-img: Could not create” no es misterioso. Es repetitivo. Eso es buena noticia: los problemas repetitivos se corrigen con soluciones estandarizadas.

Haz esto a continuación, en orden:

1. Toma una ruta que haya fallado desde el log de tareas y verifícala con findmnt y una prueba de escritura.
2. Revisa la capacidad de forma correcta según tu tipo de almacenamiento (bloques, inodos, metadata thin, cuotas ZFS).
3. Arregla identidad y permisos con intención: mapeo root_squash en NFS, ACLs de CIFS, ACLs locales y perfiles de AppArmor.
4. Implementa las medidas aburridas de prevención: pruebas de humo post-reinicio y alertas sobre remonte en solo lectura y agotamiento de metadata.

Una vez hecho eso, la próxima vez que Proxmox lance “Could not create”, invertirás cinco minutos en diagnosticarlo en lugar de una hora negociando con tus propias suposiciones.