timg11

Getting back to the slow write issue on my array Last large copy to the array: Logs analysis by AI: "Every one of those disks is topping out around 21.6 MB/s despite being large 28TB/24TB Exos-class drives rated for 250+ MB/s sequential. That gap is the real story — the physical disks aren't spinning at their limit, something is throttling how much work reaches them." I set md_sync_limit to 10. reconstruct_write was already set. During copying activity, array activity goes up to 75%, and CPU rises from its nominal of 10% to about 40% (The copy is from a Windows VM to a share on the array, so anything on the Windows VM uses lots of CPI Is there anything changed in Unraid 7.2.8 that would help in this area? Have any other techniques for improving array performance been identified?

In my Windows 11 VM running under Unraid 7.2.2, it is difficult or impossible to safely remove USB drives that are mounted in the VM. One of the host system's USB3 controllers (ASMedia) is passed through to the VM. It is a physical USB3 controller on a PCIe card. Devices that are directly and locally used by the Windows VM are connected there. In the Windows VM, the device Manager tree looks like this: The problem is the "Safely Remove Device" dialog in the tray looks like this: If I remove the ASMedia USB3.1 controller, it also removes devices unrelated to the USB hard drives and used by applications, and would affect system operation. The USB Mass Storage Device that holds the drives is a Sabrent 4-bay drive docking controller Attempting to disable this device in Device Manager results in a prompt to reboot. Has anyone found a clean way to shut down drives for replacement without shutting down the VM?

I run Unraid 7.2.0 on a Dell T440 server with two Gigabit Ethernet ports. They are bonded as bond0 using 802.1ad LAG. The two ports connect to a Cisco SG200-26 26-Port Gigabit Smart Switch, on ports GE25 and GE26. They are also configured as LAG. When I first built the system, I did an informal test copying large files from network hosts to the array. On the Dashboard Interface, I saw the Inbound go well above 1000 Mbps, so I thought Bonding was OK. Now I've run a more precise test with iperf. Running a single iperf test with the client on a system on the LAN to the Unraid Server running iperf server shows throughput of 950 Mbps. I expected running simultaneous iperf (from separate hosts on the LAN to two different iperf server ports on Unraid) would show a speed around 1900 Mbps due to LAG. What actually happens is each iperf test slows down to about 300 Mbps when run concurrently. Gemini suggested changing Unraid xmit_hash policy. It is currently layer2: root@T440:~# cat /sys/class/net/bond0/bonding/xmit_hash_policy layer2 0 The recommendation is ifconfig bond0 down echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy ifconfig bond0 up I have not done that because the only way I access Unraid is by the network, so I'd have to add a monitor and keyboard to retain connectivity. Is this the first thing to look at for poor network performance with Bonding and Lag?

I have an array of 4 Seagate IronWolf Pro drives in this Unraid 7.2.2 system. When copying large files from another system to the Array, I'm seeing about 50 - 55 MB/s write speed. The CPU is running 6-10%, and the network interface is running about 500 Mbps. The "theoretical" write rate of IronWolf Pro is about 200 MB/s. Is there something wrong or misconfigured, or is this all these drives can actually deliver in a real-world Unraid array? Here's the results of a copy process writing a group of 100 2 GB files to the array from another computer over the network. Everything else is idle on the Unraid system. The sending computer is not CPU limited or network limited. I'm curious why the read rate is about the same as the write rate? Is that expected? Diagnostics attached: t440-diagnostics-20260118-1201.zip

@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.

I've been running with the snapshots flattened, and down to a single .img file. However, Unraid still thinks that snapshots exist. You said to remove the .db files, but where do I find them to remove them?

I have a Windows 11 VM with image files located on /mnt/newcache/domains/Windows11. The VM primary (boot drive) vdisk image is 100G. When I was debugging, I was frustrated that when I stopped the VM to copy the .img file to my array, it was unexpectedly slow. It took about 1 hour to copy 100 GB from newcache to array (made of Seagate IronWolf Pro drives). 100,000 MB / 3600 seconds = 28 MB / s. This was on an unloaded system, <10% total CPU use during the copy. When the array is operating I can see individual disk rates of 200 MB / s on sustained transfer on the Unraid Main tab. I have not solved that issue yet. As an alternative, I explored keeping the backup images on the newcache drive. It is 1T in size, and only 150 GB was in use. With the VM stopped, I ran the commands: root@T440:/mnt/newcache/domains/Windows11# mkdir imgbackup root@T440:/mnt/newcache/domains/Windows11# cp vdisk1.img imgbackup/ This command completed in about 1 second! I thought it didn't work, but the copy of the file was there. I asked Gemini if this was something done internally by the DELLBOSS card, but it said it was a result of btrfs: The 1 second "copy" is not trickery from your Dell BOSS card, but a brilliant feature of the BTRFS (or XFS) file system Unraid uses for cache pools called Reflink (Reference Link). 1. The "Magic" of Reflink Copies When you use cp on the same NVMe pool, the file system doesn't actually move the 100GB of data bits. Instead, it creates a new "pointer" (metadata) that points to the exact same physical data blocks on the drive. Space Savings: Currently, that 100GB copy is taking up zero extra bytes on your NVMe. Instant Backup: It is 100% bit-perfect and safe. Copy-on-Write (CoW): If you start the original VM and it changes a single block of data, the file system will only then write that specific change to a new area of the drive. The backup in your working_img_0102 folder will remain unchanged, frozen at the moment you made the copy. Is this true? It seems to be, at least in terms of space, since I have created 4 "copies" of the 100G img file and the total space is only up to 268 G now. Is there any performance overhead leaving several versions of the image file reflinked like that on the drive? Should I move them off to the Array once the VM is stable? Presumably I could copy the backup copies to the array while the VM is running?

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.

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

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.

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?

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 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?

Here's how my "domains" folders look now: root@T440:/mnt/user/domains# cd Debian/ root@T440:/mnt/user/domains/Debian# ls -l total 9140352 drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/ -rw-r--r-- 1 root users 32212254720 Dec 29 17:18 vdisk1.img root@T440:/mnt/user/domains/Debian# cd ../Windows\ 11/ root@T440:/mnt/user/domains/Windows 11# ls -l total 38000332 -rw-r--r-- 1 root root 7148 Sep 1 16:47 2025-09-01--generate.running -rw-r--r-- 1 root root 6778 Jun 21 2025 S20250621140445.running -rw-r--r-- 1 root root 6960 Aug 24 13:27 S20250824132729.running -rw-r--r-- 1 root root 7349 Sep 27 12:32 S20250927123248.running -rw-r--r-- 1 root root 6778 Jun 21 2025 Windows--generate.running -rwxrwxrwx 1 root users 107374182400 Dec 29 17:19 vdisk1.img* root@T440:/mnt/user/domains/Windows 11# Which of these would be the "snapshot dB" file that causes the GUI to show the old snapshots?

@SimonF Thanks for your help. I performed the flatten process and now the Debian directory looks like this with a single image file: root@T440:/mnt/user/domains/Debian# ls -ltr total 11438560 drwxrwxrwx 1 root root 590 Dec 27 10:38 temp/ -rw-r--r-- 1 root users 32212254720 Dec 27 10:53 vdisk1.img root@T440:/mnt/user/domains/Debian# When I edited the vdisk back to vdisk1.img, it changed its setting from Manual to Automatic after I Updated. I am seeing the bug where the old snapshots still show in the GUI: Is there a manual fix for that, or should I just ignore it?