bastl

Wow. I didn't expected that answer. 3 out of 5 USB controllers separated, onboard audio, all networking devices in it's own groups. That looks really really promising. Thanks for the info.

@jwoolen The numbers are so close together that you kinda can ignore the differences. A slight difference in temperature can already reduce the performance of the drive. A single run won't produce genuine results. You have to make sure the start temperature of the drive is always the same, nothing else in the backround hits the drive, drivers are the same and cooling is always the same. There are to many factors you have to count in. Other question are the IOMMU groupings with ACS patch?

Doesn't happened for me on 6.8.0 and started yesterday with the upgrade to 6.8.1. I think we had that issue somewhere in an 6.6 or 6.7 builds. Can't remember if it was a RC or stable, but it got fixed really quick.

@J05u Make sure you edit the correct line in the XML! You can easily passing the wrong device to the VM which can cause the whole server to freeze. Maybe try to setup a new VM as Q35 for testing purpose. It's safer this way I think. Maybe posting some error logs and the XML and some more infos might be useful for people to help you.

If you don't install your own driver it will use windows default drivers. Some AMD users reported issues with newer drivers like you did. There are a couple things you can do. First of all check your xml from your VM and adjust the following example from my xml with a Nvidia card, yours might look slightly different: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x43' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/Backup/vbios/Strix1080ti/AsusStrix1080TI_dump_edit.rom'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x43' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> First part is the GPU second part is the HDMI audio of the card. As you can see in my example, Unraid on default puts them both on different buses in the VM. Adjust the audio device so it sits on the same bus and set a different function for it. For my example I have to change the following for the audio device <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> to <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> So the bus "0x04" matches the GPU device and add +1 to the function of the GPU. For some people that fixed the driver issues with AMD. For other users they had to setup their VMs as Q35 machine type. I guess you use the default i440fx machine type. Might be worth a try.

@PeteAsking If you use the snapshot feature it will create a .snap file which collects the changes of the VM during the main vdisk is copied and these changes will be committed to the base vdisk file after the copy process is done. So if there is no error during the process, you only have 1 vdisk file.

Maybe change the banner also to a red one with a hint on it. Edit: Maybe don't change anything on the server for legal reasons.

Prefer keeps them on the cache as long as the limit isn't reached.

Or simply click on the yellow folder icon in web view to see the folders on the cache drive 😉

On default only the user fileshares are moved. Shares for VMs for example stay on the cache device for performance reasons. Do you use VMs or played around with them?

@cleibig Passthrough can be an issue but performance wise I think the fact that the chipset is wired via PCIe 4.0 x8 you won't have any issues. Using that slot for a cache drive would be preferred and the other 2 slots you might be able to passthrough without big issues of grouped devices. The big question is how the BIOS presents the devices to Unraid.

What you described is often an issue on newer AMD cards. They have a reset issue. If a VM uses the card and shuts down or restarts, the card can't be reset correctly and ends in an unrecoverable state. Only solution is to restart the whole server in this case. On Nvidia cards this is a rare case. Mostly happenes if not all devices of the card are passed through. Always handover the HDMI audio portion of the card as well as USB devices if they exist. Check the logs if the VM won't start anymore and post them. Try what happen if you restart the server in that case. Will the VM boot up again? Wrong VBIOS can also be an issue. Make sure you use the exact model and revision for your card or dump it yourself, remove the header like SpaceInvader described in his video. Always have a display connected to your card or a HDMI dummy plug so the card thinks a display is attached. Some cards won't initialise without a display. For each VM you can access the logs for the last boots. Simply click your VM where you have a sub menu for start/stop/vnc etc. and there is a log entry. You can find the logs also in the full diagnostics ( tools >>> diagnostics )

As some users mentioned before this particular container usually got multiple updates per day, but now I don't see any updates anymore. I think early december I updated it last time.

@markymark I can tell you, why you choose the "Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller" one over "ASM1042A USB 3.0 Host Controller" 3.1 > 3.0 😂

If you try to passthrough this onboard USB 3.1 controller, you might have similar issues. As you can see, there is another device grouped with the controller. If the VM detects it correctly and you plug in a usb flash drive, it should show it as you know it from windows. The controller itself should show up in your system devices as a controller, not as a drive.