Problema

En entornos de virtualización basados en QEMU/Proxmox, los backups de máquinas Windows suelen depender de la integración de Volume Shadow Copy Service (VSS). Cuando el agente de QEMU solicita un fs‑freeze para crear una instantánea consistente, Windows a veces responde con “Access denied to IVssWriterCallback”. El síntoma típico es que la tarea de backup se aborta, los logs de Proxmox Backup Server (PBS) muestran errores de VSS y, en el propio Windows, el comando vssadmin list writers indica que los escritores están en estado Failed.

Este comportamiento no es exclusivo de una versión concreta de Windows; se ha observado en Server 2016, Server 2019 y en versiones Core sin interfaz gráfica. El problema se vuelve crítico cuando la única alternativa conocida es abrir dcomcnfg y modificar manualmente los permisos DCOM para el usuario del agente, una operación tediosa y propensa a errores, sobre todo en despliegues automatizados.

Causa

El origen del error está en la interacción entre el QEMU Guest Agent (QGA) y el sub‑sistema COM de Windows. Cuando QGA intenta iniciar una sesión COM para llamar a IVssWriterCallback, la llamada se ejecuta bajo la cuenta del proceso qemu-ga.exe. En versiones anteriores de virtio-win (anteriores a 0.1.302) el agente no inicializa correctamente la seguridad COM, lo que lleva a que el servidor DCOM rechace la petición por falta de autorización.

Factores que agravan la situación:

  1. Drivers VirtIO desactualizados – los paquetes virtio-win incluyen el QGA y los controladores de disco. Si el paquete está en una versión antigua, la inicialización COM es incompleta.
  2. Política de seguridad DCOM personalizada – entornos que aplican GPO restrictivas pueden bloquear la creación de objetos COM para cuentas de servicio.
  3. Instalaciones “Server Core” – la ausencia de UI impide usar dcomcnfg de forma cómoda, lo que lleva a buscar soluciones de línea de comandos poco documentadas.
  4. Versiones de QEMU sin parche de inicialización – el código de QGA que llama a CoInitializeSecurity se movió al proceso principal en parches recientes; versiones previas pueden quedar atrapadas en hilos secundarios sin los permisos adecuados.

En la práctica, la combinación de un driver antiguo y una política DCOM restrictiva produce el mensaje Access denied que interrumpe el freeze.

Solución

La forma más fiable de eliminar la necesidad de tocar DCOM es actualizar el paquete virtio-win a la versión 0.1.302 o superior y asegurarse de que el QGA se ejecuta con la última lógica de inicialización COM. El proceso se divide en tres pasos:

  1. Descargar e instalar la última ISO de virtio‑win

    • Obtén la ISO oficial desde el repositorio de Fedora (o el mirror de tu distribución).
    • Monta la ISO en la VM y copia los controladores de disco y el ejecutable qemu-ga.exe a la carpeta C:\Windows\System32\.
    • Reemplaza los archivos existentes y reinicia la máquina.

  2. Actualizar el agente QEMU en el host Proxmox

    • En el nodo Proxmox, verifica la versión de QEMU con pveversion -v.
    • Si la versión es anterior a la que incluye el parche de CoInitializeSecurity, actualiza el paquete pve-qemu-kvm mediante apt-get update && apt-get install pve-qemu-kvm.
    • Reinicia el servicio pvedaemon o el nodo completo para cargar la nueva versión.

  3. Validar la configuración del agente

    • Asegúrate de que el servicio QEMU Guest Agent está configurado para iniciarse automáticamente: 
      sc query qemu-ga
sc config qemu-ga start= auto
net start qemu-ga
    • Verifica que el agente responde a comandos de estado con qm guest cmd <VMID> ping.

Con estos pasos, el agente ya inicializa COM con los permisos correctos y el llamado a IVssWriterCallback se completa sin errores. En la mayoría de los entornos, esto elimina por completo la necesidad de modificar DCOM manualmente.

Alternativa temporal

Si, por alguna razón, no puedes actualizar virtio-win inmediatamente, puedes aplicar un ajuste puntual en DCOM:

dcomcnfg
# Navega a Component Services → Computers → My Computer → DCOM Config
# Busca "QEMU Guest Agent" (o el CLSID correspondiente) y abre Propiedades
# En la pestaña Seguridad, agrega el usuario del servicio (por ejemplo, Local Service) con permisos de “Local Launch” y “Local Activation”.

Este método funciona, pero es frágil: cualquier cambio de política o actualización del agente puede revertir los permisos.

Cuándo aplicar esta solución

Aplicable cuando:

  • Los logs de PBS indican fallos de VSS o fs‑freeze y el mensaje de error menciona IVssWriterCallback o Access denied.
  • La VM ejecuta Windows Server (cualquier edición) bajo QEMU/Proxmox y el QGA está instalado.
  • No deseas gestionar permisos DCOM manualmente, especialmente en despliegues Core o en clusters automatizados.

No aplicable si:

  • La VM no utiliza QGA (por ejemplo, se confía en snapshots externos sin VSS).
  • El backup se realiza con herramientas que no requieren VSS (copias a nivel de bloque sin freeze).
  • La infraestructura de host está bloqueada en versiones muy antiguas de Proxmox que no pueden actualizar QEMU.

Código

# 1. Descargar la última ISO de virtio-win
wget -O /tmp/virtio-win.iso https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win-0.1.302.iso

# 2. Montar la ISO en la VM (ejemplo con qemu-img y virt-manager)
virsh attach-disk <VMID> /tmp/virtio-win.iso vdb --type cdrom --mode readonly

# 3. Dentro de Windows, copiar los drivers y QGA
# (puedes usar PowerShell remoting o copiar manualmente)
# 4. Reiniciar la VM
virsh reboot <VMID>

# 5. En el host Proxmox, actualizar QEMU
apt-get update && apt-get install -y pve-qemu-kvm

# 6. Reiniciar servicios de Proxmox
systemctl restart pvedaemon pveproxy

Verificación

  1. Comprobar el estado de los escritores VSS

    vssadmin list writers

    Todos deben aparecer como Stable y sin errores.

  2. Ejecutar un backup de prueba desde PBS

    • Inicia una tarea de backup manual y observa que el paso VSS snapshot finaliza sin mensajes de error.
    • En los logs de PBS (/var/log/pbs/pbs.log) busca la cadena VSS snapshot completed.

  3. Revisar el log del agente QGA

    journalctl -u qemu-ga -f

    No debe haber entradas que indiquen CoInitializeSecurity o Access denied.

  4. Validar que el servicio QGA está activo

    sc query qemu-ga

    El estado debe ser RUNNING.

Si los cuatro puntos son positivos, la solución está confirmada.

Notas adicionales

  • En entornos con alta rotación de VMs, automatiza la descarga y el despliegue de la ISO de virtio-win mediante scripts de provisioning (Ansible, Packer).
  • Mantén una política de actualización regular de los paquetes de Proxmox; los parches de QEMU suelen incluir mejoras de seguridad y de integración COM.
  • Cuando trabajes con Windows Server Core, usa PowerShell Remoting (Enter-PSSession) para copiar los archivos de la ISO y registrar el servicio QGA, evitando la necesidad de una consola gráfica.
  • Si después de la actualización sigues viendo fallos de VSS, revisa los eventos de Windows en Event Viewer → Applications and Services Logs → Microsoft → Windows → VSS. Los códigos de error pueden indicar problemas de espacio en disco o de permisos de archivo que no están relacionados con DCOM.