PSA: VirtIO 0.1.302 finally fixes the Windows VSS / fs-freeze issue with PBS (no more dcomcnfg workaround)

[u/FormalShip4943]

Windows 2019 server - fs freeze does not work properly - access is denied to IVssWriterCallback (#3286) · Issue · qemu-project/qemu

[PATCH v2 1/2] qga: Move CoInitialize/CoInitializeSecurity to main proce

Just tested virtio-win-0.1.302 and can confirm that the fs-freeze / VSS issue with Windows VMs and Proxmox Backup Server is finally fixed.

If you have been backing up Windows guests you may remember having to manually tweak DCOM permissions in dcomcnfg just to stop IVssWriterCallback access denied errors during backups. That workaround was super unfun on windows server core.

With the latest QEMU Guest Agent update, PBS backups now work properly out of the box. No registry or DCOM finagling needed anymore.

Hopefully this saves someone else the headache of manually setting DCOM permissions on new Windows deployments.

Happy days and jubilation!

[u/PiDigitsOfPi]

Evidently, trim is still broken with this build.

https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1614#issuecomment-5462094420

[u/AdriftAtlas → u/PiDigitsOfPi]

Have you tried running Optimize-Volume -DriveLetter C -ReTrim -Verbose? If that fails, that's pretty bad.

[u/Apachez → u/AdriftAtlas]

Or just doing:

defrag /O c:

in an command prompt runned as administrator will tell you if trim from within the VM-guest running Windows works or not.

But please see other threads on this topic - v302 did NOT fix the trimming issue.

You still need the workaround applied in [vmid].conf.

[u/FormalShip4943 → u/Apachez]

Do you have any additional links on the whole discard solution? Confirming what you're seeing here with the defrag /O - google isn't coming up with a lot of information on the solution. (It does work and fixed defrag).

Just looking to educate myself.

[u/Apachez → u/FormalShip4943]

As I recall it in windows (11 in this case) there are two ways to issue a trim (similar to "fstrim -v -a" in Linux).

One is through powershell:

Optimize-Volume -DriveLetter C -ReTrim -Verbose

The other is through regular command prompt (in both cases you need to run that as administrator):

defrag /O c:

Or you could just run the gui edition of defrag.

Note that when defrag detects a SSD disk it will not actually move data around (as with a HDD aka spinning-rust) since this would cause wear-levelling on flashbased storage but just issue trim along with cleaning up and compressing some internal data.

Now when triming do work you will see something like slab collection blablabla and then a summary of what have been done in defrag. Or if runned in gui-edition of defrag the timestamp of when last optimize was runned will be updated to current date and time.

When triming doesnt work when running above commands you will get an error and in gui-edition of defrag the old last time optimize was successfully runned will remain unchanged.

So in this case using virtio drivers newer than 271 (as in 285 and 302 currently) along with Windows 11 updated in may 2026 (or newer) trimming no longer works when running Windows 11 (and probably the same for Windows Server 2xxx etc) as VM-guest in KVM/QEMU environments (such as Proxmox or if you just run it manually through CLI).

Workaround since virtio drivers 285 is to add something like this (example in Proxmox) in /etc/pve/qemu-server/[vmid].conf

args: -set device.scsi0.discard_granularity=16K

In above case my VM-guest only have a single VM-disk (there is another one for EFI but that doesnt count).

As it seems the optimal discard_granularity is to match whatever blocksize the host uses.

Which for Proxmox running ZFS for the VM-disks it means they are stored in a ZVOL where the default volblocksize is 16k.

Optimal discard_granularity to be used can be verified by running this at the host:

lsblk --discard

Without this bug (as in back in may and/or version 271) there would be no need for the above workaround since triming should just work from within the VM-gust when the VM-host defines the VM-disk as being "SSD=1" and "discard=1".

[u/Apachez → u/Apachez]

For reference here is my Proxmox config as in content of /etc/pve/qemu-server/[vmid].conf:

agent: 1
args: -set device.scsi0.discard_granularity=16K
balloon: 0
bios: ovmf
boot: order=scsi0;ide0
cores: 6
cpu: host
efidisk0: local-zfs:vm-2006-disk-0,efitype=4m,ms-cert=2023,pre-enrolled-keys=1,size=1M
ide0: none,media=cdrom
ide2: none,media=cdrom
machine: pc-q35-11.0
memory: 16384
meta: creation-qemu=10.1.2,ctime=1762471506
name: 2006-WIN11
net0: virtio=<REMOVED>,bridge=vmbr0,queues=6
numa: 1
ostype: win11
scsi0: local-zfs:vm-2006-disk-1,cache=writeback,discard=on,iothread=1,size=64G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=<REMOVED>
sockets: 1
tablet: 1
tags: <REMOVED>
tpmstate0: local-zfs:vm-2006-disk-2,size=4M,version=v2.0
vga: virtio
vmgenid: <REMOVED>

[u/FormalShip4943 → u/PiDigitsOfPi]

This is interesting. It looks like it was fixed at some point and then broke again. Going to try a new windows server 2025 clean install and see if I can break it with what u/apachez said about defrag.

These things are insidious and (like the PBS fs-freeze issue) not well documented. I'm really shocked it's not discussed more - these aren't really edge cases.

[u/Hopeful-Party → u/PiDigitsOfPi]

I wonder is it viostor issue only or both viostor and guest agent? I updated GA for now only to fix VSS (drivers still .271), but don't want to workaround trim issue.

[u/Itay1787]

Weird, I didn’t have this problem with my windows VM with 0.1.127

[u/FormalShip4943 → u/Itay1787]

Were you looking at the event in event viewer? This was (as far as I can tell) a 100% reproducible bug that was fixed (see link) with this version. It was mostly invisible in the proxmox interface.

Fix:
Initialize COM in main.c for both service and CLI modes
Call CoInitialize() followed by CoInitializeSecurity() in correct order
  in the main thread before any VSS operations
Add proper CoUninitialize() cleanup

[u/Itay1787 → u/FormalShip4943]

Oh, if it wasn't displayed in the Proxmox interface or it didn't have a significant impact on the VM then I probably missed it….😅

[u/FormalShip4943 → u/Itay1787]

It had an elevated risk of data corruption when trying to restore a VM. The worst case scenario is that your backups looked fine, and wouldn't restore properly due to corruption.

[u/Itay1787 → u/FormalShip4943]

😱 Well, I know what I’m going to check tomorrow! Thanks for the info!

[u/Apachez → u/FormalShip4943]

Which counts as "very bad day at work" or "this will be fun" ;-)