meep

Thanks for the pointers. As noted, I did try both iMacPro1,1 and MacPro 7,1 LiLu & WEG are both the very latest versions I'll try that specific version of clover and iMacPro one more time and then give up and just do a fresh install. As I say, this VM has been serving me well for some time, but who knows what idiosyncrasies have crept in. Thanks for all your work and effort in this thread, by the way, I've found it more than useful!

So I'm having a torrid time attempting to get HEVC enabled on my RX570 in Mojave VM. Hopefully someone here can offer some insights. I have a long-standing Mojave VM booting from a physical SSD. EFI partition is on the SSD as well, so only one disk configured in VM XML. Clover v. 4xxx is installed in EFI. RX570 is passed through and is working with Metal support and H.265 reported in VidProc. HEVC remains resolutely disabled in VidProc despite my best attempts. I've configured my SMBIOS to be a wide variety of systems from MacPro 1,1 through 7,1 and iMacPro 1,1, all to no avail. There are a few points of note; I cannot get Clover to load Lilu/WEG from the /other folder. I must install to /library/extensions using HackInTool for it to show as loaded in ioRegistry. (I have checked that load kexts is set to 'yes' in clover configurator) Despite WEG being loaded, my GPU remains stubbornly attached to parent S28@5 in ioRegistry. I understand this should be GFX0 - but I cannot make this happen I've tried updating to Clover 5xxxx but this just hangs at 'scanning devices'. (I understand that newer versions are more trouble than they are worth - I just thought an update might load kexts from 'other'. The VM is running very smoothly and is very stable. i'd just like to have it as close to bare metal as possible and HEVC is that elusive functionality I'm chasing. I want to make one last attempt at this before I go through a full fresh install. Any tips appreciated.

There's ways around that

Yes, this is correct. A few notes and caveats... If the controllers are the same (make & model), they will likely have the same id. In this case, you only need to add that id once, and both will be passeed through and available. You'll need to do a little detective work to figure out which is which. Here's an example from my own VM config. setup where you'll see 2x PCIe adapters (Fresco) and 2x motherboard controllers (Zeppelin) available for pass through. (other stuff also passed through). I only set the id once for each type; However, if you are passing through motherboard controllers, be sure theres not a 3rd lurking somewhere, or it will get passed through as well. If your unraid USB happens to be plugged in there, your system will fail to boot. Also, the controllers need to be in their own IOMMU groups, and not have any other devices in those groups with them. Here's a section of my System Devices report where you can see the Frescos and one of the Zeppelins (the other is much further down, but also in its own group);

I haven't conducted quite enough testing to validly raise a bug. I just tried following the instructions, played about with including or excluding quotes a syyou suggested and found the device always came through to the OS. I'd need to do a bit more structured testing to justify a bug report. May do so net weekend, time permitting. I understand from a post from unRaid in the 2020 wish list thread that we can expect to see this dealt with in UI this year. That would be amazing.

I too tried this recently, and it didn't work (6.8.0) vfio-pci-ids do work, but not in cases where user wants to pass through, say, one of 2 on-board USB controllers which have the same ID. The new BIND method would be perfect for this as it uses addresses, rather than IDs.

Interesting to read of someone going the other way! (sonos -> LMS) One interesting thing you can do is, if you have a multi-channel audio card, you can set up multiple virtual squeezebox clients on a singe machine / VM and manage your zones that way. It depends, of course, on your topology. if you have centralised amplification with speaker wire runs to zones, this can work out really well. I have some (very old) posts on the topic you might find interesting; https://mediaserver8.blogspot.com/2012/04/whole-house-audio-step-1.html https://mediaserver8.blogspot.com/2014/04/whole-house-audio-step-2.html The second, in particular, deals with the headless 'SqueezeSlave' software. The is the cleanest, most efficient way I've found to run LMS multi-zone.

That doesn't sound right. I have a similar set up, but my eth1 tab shows the interface bonded, not 'not configured' Do you have eth1 added to the bonding members field (under eth0)?

OK, have it working. Many thanks! One thing I missed after updating the server details was that I needed to login via the docker UI. I'd stopped and started unraid-API a few times as I wasn't getting the response to the MQTT request. Once I logged in, I was golden. I'll have a play over the weekend to see what I can do with this.

Actually, thinking about it, the non-standard port is likely the issue? If your docker is attempting to make calls to port 80, it won't work for me. As indicated, sometimes it's necessary to run UnRaid on an alternative port. Would you need to expose a variable for unRaid UI host port in the docker config?

Hi unraid UI is served over http PlugIn list attached, nothing too unusual, I believe. My unraidAPi network is configured as per screenshot in original post: Bridget, privileges off. Maybe the following would have an impact? 1. My MQTT docker is configured as host; (I'm not sure why it's set like this, I think it's the only way I could Node-Red to talk to it because.... 2. My unRaid UI is running on a non-standard port (I needed to map port 80 directly to port 80 in a NodeRed docker as my Alexa LAN discovery node insists it is configurerd so)

I'm sure there's a whole section of Virtualization theory that deals with this, but I'm struggling for the right terminology, so thought i'd ask here. I have 16 cores (32 thread) in my system. I'm running 3-4 VMs, multiple dockers and, of course, unRaid itself. One of my VMs happens to have generally higher usage than others: the 2x cores / 4x threads are usually ~70% usage each when I check in dashboard. (This is due to a number of home automation workloads within the VM). I have no problem with that. The query I have is, should I be, from time to time, switching the physical CPUs I'm using for this VM? Is there any chance that running 2 of 16 (or 4 of 32) cores on my CPU at a constantly higher load than the others will cause my CPU to fail sooner than it might otherwise? I'm thinking of rotating types on a car to induce more even wear and extend life a little. Is there a CPU equivalent? /naivety

@Eksster USB Controller pass through is absolutely the way to go. Not only does it minimise pfaffing around in VM configs, its much (much!) more reliable. For example, I have a set of HK Soundsticks that I use with my OSX VM. Passing them through via unRaid is hit and miss. If they work at all, the audio breaks up so as to be unusable. However, when I pass through a USB adapter to the VM, and plug devices in there. the speakers work perfectly Take care with USB pass through to OSX. Not all adapters are supported natively. You might find some don't work as OSX doesn't have the drivers or support the chipset. This can be especially problematic with motherboard controllers. (for reference, I've found these to be 100% compatible). Another point to note - passing through motherboard controllers is a great way to get dedicated ports for VMs. Take care though! Remember that your unRaid USB is plugged into one of those ports. And sometimes, the controllers share IOMMU groups with your network card. If you pass through a MB controller in either of the above cases, you will find that either your system won't boot (can't find usb) or you won't be able to access the UI or shares remotely (as network is unavailable). If you are passing through USB MB controllers, ensure that you have another system on hand that you can plug your unRaid USB stick into and manually edit the config files, or better sill restore them from a previous backup, in case things get messed up and you cannot boot. Speaking from experience!!! On running out of PCIe slots, the MB pass-through will help. The Bifurcation approach we previously discussed will help. Or you can find USB adapters with multiple controllers on board. There was a Sonnet model that had 4x controllers and 4x ports, which would have permitted support for USB passthrough for up to 4x VMs on a single card. Unfortunately, it's been discontinued, and I cannot find out definitively if the replacement model works as well.

Thanks. My docker log is filled with multiple instances of the following (ip obfuscated by me); The secure keys for mqtt may have not been generated, you need to make 1 authenticated request via the API first for this to work Get Dashboard Details for ip: 192.168.n.n Failed with status code: undefined Request failed with status code 404 Get Docker Details for ip: 192.168.n.n Failed with status code: undefined Request failed with status code 404 Get VM Details for ip: 192.168.n.n Failed with status code: undefined Request failed with status code 404 Get Main Details for ip: 192.168.n.n Failed with status code: undefined Request failed with status code 404 This repeats over and over. There are no timestamps.

Makes sense I can also clarify it's an issue when attempting to access VM log files, as well as the originally reported system log file accessed via the menu bar.