testdasi

YMMV then.

Short answer is no. Long answer is sort of. Very few devices support SR-IOV that I know of. Very certainly no graphics card that I have seen. If it does support it then you can theoretically just manually split it out from the command line and use it for the VM. Keyword is "theoretically" cuz I haven't seen any proof that it works.

So I got curious and did some more testing with the "unexpected GSO type" bug. Changing VM to 5.0 (Q35 or i440fx) fixes the issue when there are a small number of dockers with static IP on the same bridge as the VM (e.g. br0 custom network). In my particular server, "small number" is about 2-3 dockers. In my tests (with reboot in between), the error happened after the 3rd or 4th dockers with static IP were started (not sure why sometimes 3rd, sometimes 4th). The error seems to depend strictly on number of dockers and not number of VM. I started 5 VM with 2 static IP dockers and no error but 1 VM + 5 dockers guaranteed error. So conclusion: If you only have a few dockers with static IP, try changing machine type to 5.0 first. That may fix it without the need of any further tweaks. If you have many dockers with static IP (i.e. (1) doesn't fix it for you) then: If you have multiple NIC's then connect another NIC (different from the one on the VM bridge), don't give it IP (important to not have IP, otherwise chances are your VM access to the shares will be done through the router i.e. limited to gigabit), add it to a different bridge (e.g. br1) and use it instead of br0 for your docker static IP. If you only have a single NIC then you will have to change your VM network to virtio-net. I think VLAN also fixes it but I have had no need for that so have no interest to test. And I think the errors are harmless, other than flooding syslog. When I started with 6.9.0, I didn't realise there were errors until my syslog filled up and there was no other issue at all. @Koenig: see above.

It looks like switching to 5.0 fixes it for some and not for others (it was suggested somewhere earlier in the topic). The officially guaranteed method is to switch to virtio-net (or set up VLAN or use separate NICs for docker and VM). LT said next release will allow user to pick between virtio vs virtio-net, which I think is better than defaulting to virtio-net in beta25 since there are other ways to guarantee no errors.

You can try using the User Scripts plugin. It has option to schedule script at array stop. 2.2GB db is not big. My db is 23GB and I don't have that busy db errors so perhaps something else is going on?

Extra param added stuff to after docker run command. Post arguments added stuff to the very end of the command (e.g. to pass parameters to the docker or to run a command from within the docker). You can think of it as the former is host-level parameters and the latter is guest-level parameters.

Apologies for that. --cpu-shares is docker specific. Given dockers are like apps, there are very few scenarios which would require giving a docker higher priority than non-docker processes.

It looks like you changed your machine type from Q35 to i440fx? Changing machine type cannot be done through the GUI. The only way is to create a brand new template. This applies to ALL Unraid versions so downgrading won't fix it. Why do you want to change machine type to begin with? That is rarely if ever required (if anything, "modern" Windows VM should be using Q35 and not the super outdated i440fx) And please attach diagnostics for any queries. (Tools -> Diagnostics -> attach the full zip file to your next post).

That is typical symptom of wrong share Cache settings. Provide details. For large data transfer, it is almost always better to turn on reconstruct write aka turbo write instead of relying on cache. Is the graphics card the only card in the system i.e. does Unraid also boot with that card? Have you isolated your VM cores? Those are the 2 main reasons causing demonic sound even after msi_utils fix. There are plenty of things that all sorts of mature paying software don't support. Try a set of powerline network adapter if you don't want to run wired (it will use your house main wiring for data, YMMV depending on how your house is wired and distance). Don't understand your problem here. Plex docker (e.g. LSIO one) has separate mappings for Movie, TV, Music etc. Even "merging in Windows" is a matter of creating a folder and mklink -D to the various network share. You totally underestimated the effort required to open your server securely to the Internet. If your ISP allows WAN access then try Nextcloud + LetsEncrypt. If your ISP doesn't allow WAN access then the next best thing is Google Drive. With regards to your VM keyboard issue, the process is: shutdown the VM, wait for it to fully shutdown, edit VM, untick + tick, save, start VM. Next time you try, make sure to take screenshots of every step + any error. Buying off-the-shelf NAS without proper research can be worse. Don't blame lack of research on money.

If you updated from 6.8.3 then go to Tools -> Update OS. You should see Unraid OS (previous) which should have 6.8.3 in the version column. Note that there are things not backward compatible e.g. 1MiB alignment, multiple pools etc. Read the beta release notes for more details.

Niceness is in the "do it if you know what you are doing" category. You seem to be focusing on a single thing (niceness) without considering any other option. Read the post Squid quoted. --cpu-shares is a better option to ensure a docker gets the biggest share of the processing. The default value (if --cpu-shares is not set) is 1024. So for your mumble docker, you want something larger like --cpu-shares=10240.

Start with attaching your Diagnostics (Tools -> Diagnostics -> attach zip file in your next post). Preferably while you are doing some transfer via the network bridge (i.e. without any passed-through NIC). There's little to diagnose without diagnostics. Also state what's your expected performance. What speed is "terrible"? Have you done any iperf test?

Try this. Settings -> VM -> change "VFIO allow unsafe interrupts" to Yes. Apply and reboot.

Onboard AMD audio probably won't work so your best bet is probably to try fixing Nvidia audio. If Windows see the Nvidia Audio but no sound output then your issue is likely with your end device e.g. your monitor or connection. Try HDMI.

See below (you and the other OP have similar hardware so same tips)

Short answer is no. Even 6.9.0-beta25 only has kernel 5.7.

Firstly, you have the Unraid Nvidia plugin, presumably because you run the Nvidia build. There is only 1 graphics card in your system so I don't see any reason to do that (it can cause complication with passthrough). So I would suggest to first revert back to the stock build (the plugin allows you to do that) as the first thing to do. Next, note that one of the tweaks below will cause you to lose Unraid console and boot GUI i.e. you will only be able to interact with Unraid GUI / console through the network. Make sure you understand the implication before proceeding. Now that you understood the implication: Boot Unraid in legacy mode (Main -> Flash, scroll to the bottom to check your "Server boot mode", if it's not "Legacy" then untick Permit UEFI boot mode, save, reboot and check again). Start a new template with the same settings but pick Q35 machine type and NO vbios rom. Do NOT autostart. Just save. Now edit the newly created template in xml mode. With vendor id, use exactly 12 characters e.g. 'a0123456789b' (i.e. not 'whatever'). Using 'none' may not work in some cases so I would suggest to use 12 characters instead. Under <features> or above </features> add this. <kvm> <hidden state='on'/> </kvm> <ioapic driver='kvm'/> (note the "or" above) Do the multifunction edits which you seem to have bedded down. Test your VM to see if it fixes things. If it's ok then obviously no need to do the other steps below. If it doesn't, try adding the vbios, to see if it works. If vbios also doesn't work then remove it from the template before proceeding. You will see a pattern with this. Always test with and without vbios because wrong rom file is worse than no rom file. Main -> Flash -> scroll to the Syslinux Configuration section. Add this after the 2 "append" below "label unRAID OS" and "label unRAID OS GUI Mode". video=efifb:off vfio-pci.ids=10de:21c4,10de:1aeb,10de:1aec,10de:1aed So your syslinux will look something like this . ... label unRAID OS ... append video=efifb:off vfio-pci.ids=10de:21c4,10de:1aeb,10de:1aec,10de:1aed pcie_acs_override=downstream,multifunction vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot ... label unRAID OS GUI Mode ... append video=efifb:off vfio-pci.ids=10de:21c4,10de:1aeb,10de:1aec,10de:1aed pcie_acs_override=downstream,multifunction vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot,/bzroot-gui ... Then save, reboot. You should see nothing after "Loading bzroot... OK". In other words, after this step, you will only be able to interact with Unraid GUI / console through the network i.e. using another device with a browser e.g. a laptop / tablet / phone etc. Test your VM again. Again with and without vbios rom. If it still doesn't work then you will need to borrow another graphics card to boot Unraid with this new card (i.e. NOT the 1660) in order to dump your own vbios rom file of the 1660. That's the only way to guarantee that you have the right vbios rom. Then test it again with this new vbios rom. Also test whether your VM would work if Unraid boots with your borrowed graphics card. If that's the case, you probably have no choice but to buy a cheap low-end graphics card for Unraid to boot with in order for your VM to work with the 1660. e.g. the GT710 is a popular choice that goes for around £30/$30. That's about all that I could help.

Just guessing, could be because you had your old template on 4.1/4.2 etc.? Creating a new template would immediately bring it to 5.0. Networking default to virtio-net adapter with beta25. That has performance limitation. Try editing the xml and change virtio-net to virtio. I was told the next 6.9.0 version will have the option to pick virtio or virtio-net.

It would be a good idea to attach diagnostics Tools -> Diagnostics -> attach full zip file in your next post. Your wireless keyboard probably went into power-saving mode which is a common feature with wireless stuff. Your situation with wired keyboard could have been fixed simply by editing your VM and untick the USB device corresponding to the wired keyboard. No need to nuke your VM. If you still have the vdisk of the old VM around, try it (so no need to reinstall Windows). If you don't have the old vdisk then install windows with the wired keyboard, make sure everything boots fine, shut the VM down, edit template to untick the wired keyboard + tick the wireless keyboard, save and start VM again. Your frustration probably stemmed from not asking questions (I'm guessing from your 1 post). Next time you have problems, it's a good idea to ask on here since chances are someone will be able to help. With regards to USB controller, it may not be necessary to buy a PCIe card. Some motherboards have onboard USB controllers that can be passed through. And finally, go watch Unraid tutorials on the SpaceInvader One channel on Youtube.

6.9.0-beta25 is available if the bug is critical for you. I run it on my prod server with no issue.

There are 2 limits. 750 GB / day transfer limit API limit I can't remember the exact number anymore but Google measures how many API call is done every minute and if you exceed it, you will be locked out. I think your ISP probably can only limit your overall transfer and not API call. Using mergerfs (or unionfs) + Team drive allows you to quickly switch to a user if one is locked out (or have multiple users, each for a certain purpose). API call is actually quite hard to exceed (with subtitle app being the common exception) so you may not care but keep that in mind.

That's normal shfs overhead. The shares will never reach above about 400-500MB/s. The only way to bypass it is to either use disk share or create custom SMB config to target /mnt/cache/[share] directly.

You might want to write longer description of what you are seeing, with punctuation please. What do you mean by "I shared the caches speeds are 400/989" and "cache speeds are 400/400" and "write to the cache directly speeds are go"? What speed is "go"? Also what RAID mode are the 5 SSD's?

Could be this bug?

Your crashing and disabled drive has nothing to with those commands. What do you mean "unraid service"? What exactly crashed? With regards to the disk, it would be a good idea to attach Diagnostics (Tools -> Diagnostics -> attach zip file to your next post) so someone can have a look at your disk SMART. A disk can drop offline with no actual damage to the disk itself (e.g. cable problem) but it doesn't mean the write intended to the disk is complete. Hence a write error hence disk is disabled.