I migrated a Windows system running on a Core2 CPU to a Windows 11 VM on my T440 with Intel Gold 6134 8 Core (3.20Ghz). 3 of the 8 cores are dedicated to the Windows VM, and 16G of the total 64G of RAM are dedicated to Windows.

I interacted with the old system using TightVNC and I interact with the new system using TightVNC, so that much is constant. (Not the VM's VNC (which has problems with mouse), but a separate server)
However, the Windows VM performance under UnRaid is terrible. Typing in a terminal gets behind. Everything is sluggish. I would estimate it is running 20% as fast as the old system. Most functions of the old server have been migrated to a Debian VM or Docker containers under Unraid, but there are some Windows-only programs. It is not a heavy CPU load at all, but the slowness of the UI makes it painful to use.

Is there any white paper or guidance on performance tuning VMs? What techniques for benchmarking can identify performance issues?

Edited December 30, 2025Dec 30 by timg11

AI makes this suggestion. Can any expert confirm if it is correct?

1. Storage – Biggest Likely Culprit

• Your vdisk is at /mnt/user/domains/Windows 11/vdisk1.img.

• /mnt/user/ paths go through Unraid's FUSE/shfs layer, adding overhead—even if the files are on cache. This often causes VM sluggishness (high disk latency, slow responsiveness).

• Fix: Move to a direct cache path for better IO:

  • Stop the VM.

  • Create a dedicated folder (e.g., via terminal: mkdir -p /mnt/cache/domains).

  • Move the img file: mv /mnt/user/domains/Windows\ 11/vdisk1.img /mnt/cache/domains/.

  • Edit VM > Primary vDisk Location: Change to Manual and set /mnt/cache/domains/vdisk1.img.

  • Ensure your "domains" share is set to Use cache: Prefer or Only (Settings > Shares).

• Bonus: Enable SSD and Discard: Unmap (Trim) (already on in your screenshot—good for SSD cache).

I was unable to find a "Use cache:" setting under Settings / Shares.

CPU use on the VM does not seem unusually high:

Edited December 30, 2025Dec 30 by timg11

58 minutes ago, timg11 said:

AI makes this suggestion. Can any expert confirm if it is correct?

1. Storage – Biggest Likely Culprit

• Your vdisk is at /mnt/user/domains/Windows 11/vdisk1.img.

• /mnt/user/ paths go through Unraid's FUSE/shfs layer, adding overhead—even if the files are on cache. This often causes VM sluggishness (high disk latency, slow responsiveness).

• Fix: Move to a direct cache path for better IO:

  • Stop the VM.

  • Create a dedicated folder (e.g., via terminal: mkdir -p /mnt/cache/domains).

  • Move the img file: mv /mnt/user/domains/Windows\ 11/vdisk1.img /mnt/cache/domains/.

  • Edit VM > Primary vDisk Location: Change to Manual and set /mnt/cache/domains/vdisk1.img.

  • Ensure your "domains" share is set to Use cache: Prefer or Only (Settings > Shares).

• Bonus: Enable SSD and Discard: Unmap (Trim) (already on in your screenshot—good for SSD cache).

I was unable to find a "Use cache:" setting under Settings / Shares.

CPU use on the VM does not seem unusually high:

I would load the virtio storage drivers into the W11 VM and then change from Sata to virtio.

On 12/30/2025 at 3:18 PM, SimonF said:

I would load the virtio storage drivers into the W11 VM and then change from Sata to virtio.

Maybe that's an easy process for you, but it has been a nightmare for me. The basic issue is the VM now uses SATA for the boot drive. It can't be changed without updating the drivers, which can't be changed without the VM running - catch 22.
The process I tried (suggested by Gemini) was to create a 1G small vdisk2, and set it to VirtIO. That was supposed to cause Windows to load the needed VirtIO driver for vdisk2, then I could stop and change the boot vdisk1 to VirtIO and it would use the driver for vdisk1 and it would be happy. Not at all!
I've been through two full days of BSOD, boot device inaccessible, SYSTEM THREAD EXCEPTION NOT HANDLED, SYSTEM THREAD EXCEPTION, PAGE_FAULT_IN_NONPAGED_AREA, Windows Automatic Repair, booting off the ISO, diskpart, bcdedit, and on and on. Sometimes I could get the VM to boot, but the desktop would freeze after less than a minute.

I was trying to use Gemini, but had to keep reigning it in as it always want to keep pressing on in the same direction, rather than step back for a broader look. Gemini was always making excuses for each new failure, which made me think the QEMU / Windows combination is like a house of cards or a 100m high Jenga tower.

After two days spent, I finally set aside the failed image, restored a backup vdisk1.img (fortunately saved off before trying VirtIO), and put the XML back to the way it was. Surprisingly, I still had BSODs, and learned from Gemini that there is another "State" file - the NVRAM images in /etc/libvirt/qemu/nvram/. It keeps hardware details and had no doubt become a mess during all the trials, failed boots, force stops, and BSODs. I had to find the one for the Windows VM and delete it.

Finally I can run the VM again, but of course it is still slow. Is there any other resource, white paper, thread, or other place I can go for guidance on the correct way to approach updating a WIndows VM to use VirtIO for its boot drive?

This used to work but does seem to work correctly now for changes on W11.

Option is to create a 2nd small virtio disk. Boot the VM this will allow you to correctly install the virtio drivers to be available at boot from the virtio cd.

Once installed you can shutdown the VM, change the primary to virtio and it should now boot.

You can remove the temp drive.

6 hours ago, SimonF said:

Option is to create a 2nd small virtio disk. Boot the VM this will allow you to correctly install the virtio drivers to be available at boot from the virtio cd.

Once installed you can shutdown the VM, change the primary to virtio and it should now boot.

That is exactly what I did. Stop VM, add 2nd vdisk as VirtIO. Start VM, load drivers. I saw the RedHat VirtIO serial driver was installed for the 2nd disk, with no errors in Device Manager. I then stopped the VM, changed the boot disk vdisk1 to VirtIO and restarted. The noVNC console was black for over 5 minutes. No spinning circle, no Unraid Logo, nothing. Unraid said VM was running. I tried Force Stop, waited a couple minutes, then restarted VM. BSOD - PAGEFAULT IN NONPAGED AREA. I forced stop, and tried to reset the VM configuration for vdisk1 back to SATA. Restarting gave BSOD SYSTEM THREAD EXCEPTION NOT HANDLED. It went downhill from there.

On 12/30/2025 at 3:19 PM, timg11 said:

I was unable to find a "Use cache:" setting under Settings / Shares.

There is no Settings - Shares. There is Settings - Global Share Settings.

Use cache settings are per user share. Assuming your vdisks is in fact in domains share, you would look there. Instead of a direct cache path, better if domains is an exclusive share.

All of these things are about whether or not your vdisk is on the array.

We would have a better idea about your user share setup if you...

Attach Diagnostics ZIP to your NEXT post in this thread.

On 1/2/2026 at 10:26 PM, timg11 said:

It can't be changed without updating the drivers, which can't be changed without the VM running - catch 22.

The trick is to use msconfig to set windows to boot in safe mode. Shutdown, change disk mode, boot in safe mode once, it'll switch to the new driver, and set it back to normal boot.

4 hours ago, trurl said:

Use cache settings are per user share. Assuming your vdisks is in fact in domains share, you would look there. Instead of a direct cache path, better if domains is an exclusive share.

I believe my image files are on a cache drive

There appears to be two ways to access the same place.

root@T440:/mnt/user/domains/Windows11# ls -l

total 36480328

drwxrwxrwx 1 root root 264 Jan 1 17:54 badimage/

drwxrwxrwx 1 root root 20 Jan 1 18:06 badimage2/

-rwxrwxrwx 1 root users 107374182400 Jan 4 16:11 vdisk1.img*

-rwxrwxrwx 1 nobody users 1073741824 Dec 31 16:21 vdisk2.img*

drwxrwxrwx 1 root root 184 Jan 2 10:18 working_img_0102/

drwxrwxrwx 1 root root 184 Jan 2 13:16 working_img_2026-01-02_13_10_44/

root@T440:/mnt/user/domains/Windows11# cd /mnt/newcache/domains/Windows11/

root@T440:/mnt/newcache/domains/Windows11# ls -l

total 36480772

drwxrwxrwx 1 root root 264 Jan 1 17:54 badimage/

drwxrwxrwx 1 root root 20 Jan 1 18:06 badimage2/

-rwxrwxrwx 1 root users 107374182400 Jan 4 16:12 vdisk1.img*

-rwxrwxrwx 1 nobody users 1073741824 Dec 31 16:21 vdisk2.img*

drwxrwxrwx 1 root root 184 Jan 2 10:18 working_img_0102/

drwxrwxrwx 1 root root 184 Jan 2 13:16 working_img_2026-01-02_13_10_44/

root@T440:/mnt/newcache/domains/Windows11#

I was under the impression that the /mnt/newcache/domains/Windows11 was the best choice for the VM's vdisk, since it would not have the overhead of the FUSE filesystem that paths through /mnt/user incur. I could be wrong - please educate me.

t440-diagnostics-20260104-1618.zip

3 hours ago, Kilrah said:

The trick is to use msconfig to set windows to boot in safe mode. Shutdown, change disk mode, boot in safe mode once, it'll switch to the new driver, and set it back to normal boot.

That sounds like a great idea! I had not heard that suggestion before, but it makes sense. I will try it the next time I'm feeling adventurous and have time for debugging.

appdata, domains, system have all files on newcache. If you set them to Primary:newcache; Secondary:none, you can make them exclusive.

2 minutes ago, trurl said:

VMs bypass fuse because at VM start it replaces the file names with the direct disk mapping.

@trurl here are the user share settings for domains:

and my global share settings:

It looks like I'd need to Permit Exclusive Shares, and then set that in the domains share settings.

Making that change would apparently require shutting down everything, VMs, Dockers, and the Array.

And the benefit is better VM performance? Is there any downside?

I think I set up the "mover" thinking it would be easy to back up the VMs to the Array, but it turned out that copying a VM .img from newcache to array is incredibly slow. I don't want to leave the VMs shut down that long. But using the magic of btrfs, I can shut down a VM, copy its image file to a folder on newcache (which takes about a second), restart the VM, and let Unraid perform the leisurely copy of the .img file copy to the Array. Once copied to the Arrary, I can then delete the copy from newcache.

3 minutes ago, timg11 said:

better VM performance?

As @SimonF informed us

On 1/4/2026 at 5:46 PM, SimonF said:

VMs bypass fuse because at VM start it replaces the file names with the direct disk mapping.

So it doesn't matter.

4 minutes ago, timg11 said:

set up the "mover" thinking it would be easy to back up the VMs to the Array

mover doesn't do backups

Even though fuse is bypassed, there is no good reason to move domains, so Primary:Newcache; Secondary:none

You should make sure none of domains is on the array.