ghost82

I'm not sure about this, but if internal headers are on the mobo, they should be attached to a usb 2 controller, which doesn't show, that's why I'm assuming no usb 2 is present there. I think it's a user error. He wants to passthrough rgb things to vm so that he can control natively the lights. He could, if he has enough ports on other controllers move all the devices to asmedia/renesas. Linked topic: https://forums.unraid.net/topic/123348-cant-passthrough-usb-devices-always-together/

btw he's actually using a 3.0 controller, intel, not a 2.0. His mb doesn't have usb 2 controllers. IOMMU group 15: [8086:a2af] 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller IOMMU group 34: [1912:0015] 04:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) IOMMU group 35: [1912:0015] 05:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) IOMMU group 36: [1912:0015] 06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) IOMMU group 37: [1912:0015] 07:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02) IOMMU group 38: [1b21:2142] 08:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller IOMMU group 40: [1b21:2142] 0a:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller IOMMU group 42: [1b21:2142] 0c:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller Working: intel. Not working: I think the asmedia one.

As written in your other post, make sure the usb controller you are attaching your unraid pendrive is not bound to vfio. Or it can simply be not compatible (asmedia), so try the renesas. https://forums.unraid.net/topic/49270-unraid-web-gui-not-working-when-using-flash-drive-in-usb-31-port/

I'm quite lost...next step I would perform is analyze logs of the bootloader. To do this you need to mount the bootloader image, access config.plist file and enable logging to file. Once it bootloops, force stop the vm, mount again the bootloader image and download the txt log file generated, and hopefully you could see where and why it bootloops. If you are not able to do this, share with me in pm your zipped monterey opencore img file, I'll made all the needed changes, send it back to you, so you could replace the image.

What the logs say when there's no video output?diagnostics?

Hi, sorry but your description says nothing, it could be 1000 different things. Attach diagnostics file after you passthrough the gpu and maybe there will be something useful to read there to solve the issue.

ok, now that you have mapped all your usb ports, you know that if you are passing through usb controller X to a vm, the vm will have access to all the usb ports belonging to usb controller X. However now the issue here is different, since you are reporting that unraid usb works if plugged into the Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller, and doesn't work elsewhere. A couple of notes: you don't have any usb 2.0 controller: the intel one, where you have your unraid usb pendrive, is a 3.0 controller. you have other usb controllers: asmedia, 3.1 controllers, and reneseas, 3.0 controllers. I never had issues in plugging my pendrive in 2.0 or 3.0 controllers, but limetech suggests to use a 2.0 port for more compatibility. Did you try for unraid both an usb port belonging to renesas and asmedia? PS: before binding to vfio again the controllers, first try unraid in one of those usb controllers: you can't plug your unraid usb to a usb controller that is bound to vfio, because as written before, it is isolated from the host (unraid), so it wont be able to boot. Or it can simply be not compatible, so try the renesas. https://forums.unraid.net/topic/49270-unraid-web-gui-not-working-when-using-flash-drive-in-usb-31-port/

I cannot see anything unusual in the monterey xml, it's strange that it bootloops. Opencore img is ok, the vm boots into opencore. Target disk should be ok, it's correctly defined in the xml. Installation disk: we don't know if it's ok or not, may be corrupted?However it's correctly displayed in opencore as Base system. Something wrong is happening after booting the base system, after some checks it should start to download the image installer, so maybe that for whatever reason virtio network is failing. Change the model type and also the bus and slot of the network card, so replace the network block with this: <interface type='bridge'> <mac address='52:54:00:3d:ae:25'/> <source bridge='br0'/> <model type='e1000-82545em'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface>

the main disk contains an apple efi partition by default, with apple bootloader which qemu is not able to boot, that's why we use alternative bootloaders opencore/clover. Mojave-opencore.img is there, ok, but is it specified in the vm xml?

Then try to run directly the .efi in the dvd image: once in uefi shell type: FS0: cd efi\boot bootx64.efi press enter for each line. If the installer doesn't start there's something wrong with the installation media.

As a server or a client? As a client to connect to windows, app store has microsoft remote desktop app (to connect to windows rdp). As a server, just enable in system preferences -> sharing -> remote management and then use any vnc client to connect to the mac (standard port 5900).

As far as I know there should be no issue in booting monterey. Can you share your diagnostics file? Possibly with both the big sur (working) and monterey (not working) vm configured.

This is not explained in details and what it has to do with macinabox At the same time and each vm with its gpu? Yes, as far as I know only if the monitor supports 'picture in picture' or some monitor split function and obviously has at least 4 video inputs. With third party applications, like synergy (paid app), it's also possible to share mouse/keyboard in all the vms. It will be something like this: https://www.youtube.com/watch?v=D9u1vX-pvLs however in that video he's connecting 4 different pcs, in this case you will connect 4 different gpus installed in one server, each passed through to a vm. Or...if you run your primary vm with gpu passed through on the monitor and then you connect to the other 3 vms with some sort of remote desktop, then you can arrange the remote desktop windows as you want in the monitor. So, specify what you want to achieve clearly, in a new discussion.

There is no efi partition detected, who knows what happened or what you did. If the issue is only the missing efi partition containing the bootloader, try to add a second vdisk in the vm pointing to a bootloader image and boot from it. https://github.com/SpaceinvaderOne/Macinabox/tree/master/custom_opencore

Hi, you have several usb controllers, 8 in total, without counting that of the gpus. 7 of these are bound to vfio, so if you plug a device into a usb port belonging to these usb controllers they wont be seen by unraid, but they will be passed directly to the application using that usb controller (a vm for example). This is not clear. A usb controller communicates physically with some usb ports, so obviously you can't assign a port belonging to usb controller A to usb controller B. That's because you are plugging your devices into ports belonging to the same usb controller. Since other usb controllers are bound to vfio, if you plug devices into usb ports belonging to these usb controllers, un raid will not seen them (This controller is bound to vfio, connected USB devices are not visible.). To map your usb ports (i.e. to see what usb ports belong to which usb controller), unbind from vfio all usb controller, reboot the server, then plug a pendrive in each port and see in system devices where it attaches. I'm not sure what you want to achieve, maybe you can describe in details

and did you press a key on the keyboard when prompted for "press any key to boot from cd/dvd"? If you are not fast enough and you are redirected to the uefi shell, just type exit in the uefi shell, then you will be redirected to ovmf bios, select continue, then when prompted to press a key to boot from cd/dvd, press a key on your keyboard.

It could be specific to virtio-net driver (and maybe virtio) and ubuntu 20/outdated qemu. Either update unraid to the latest 6.10 RC, or change the network type, (virtio or e1000-82545em)

either you didn't press a key when prompted or your keyboard doesn't work in the vm. Does the keyboard work in the uefi shell?

Since you have a dos partition table I think it was a legacy bios installation and not uefi, which requires gpt. Moreover the 3 partitions reflect that of a legacy bios installation, system, windows, recovery. Simply use seabios to boot that disk, instead of ovmf.

Hi, report the outputs of these commands: fdisk -l "/mnt/cache/domains/Windows 10/vdisk1.img" and qemu-img info "/mnt/cache/domains/Windows 10/vdisk1.img"

Usually boot preferences are saved in the ovmf vars file (assuming you're using ovmf). In the ovmf bios you define and save the boot order preference. If for whatever reason it doesn't work, add the boot order line to your passed through nvme controller, something like: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x82' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x08' slot='0x00' function='0x0'/> <boot order='1'/> </hostdev> Obviously source (82:00.0) and target (08:00.0) addresses are different (most probably) in your case.

In general, yes, but success or not may depend on the mobo bios. Try to isolate the igpu and its audio part, bind to vfio at boot; then assign it to the vm (both the video and audio parts); you may need to use acs override patch in unraid to split iommu groups so to have igpu video and audio in their own iommu groups without any other devices. If you still get a black screen further debugging is needed, most of the time it's because unraid is booted in uefi and the primary card (igpu) is attached to efifb in unraid. Simply disable efifb (video=efifb:off) in your syslinux configuration (search the forum, there are a lot of posts about it). You may need to add to the vm xml also the vbios of the igpu. You can, but success or not depends if your mobo as a bios setting to set the primary card; with an additional discrete card, if you have the option in bios, set the discrete card as primary instead of the igpu. Then the above remains valid (bind to vfio the igpu). It's the kernel that seems to attach the gpu to efifb or vesafb (depending if you're booting unraid in uefi or legacy bios mode). Replied above to disable efifb.

Just for info, now unraid 6.10RC7 includes libvirt 8.2.0, so this applies from this version: <qemu:override> <qemu:device alias='YOURALIASHERE'> <qemu:frontend> <qemu:property name='x-msix-relocation' type='string' value='bar2'/> </qemu:frontend> </qemu:device> </qemu:override>

Nevermind, it was a placebo effect, it seemed it didn't crash for several reboots, then it crashed again. Thanks to an app to analyze the memory dumps (WhoCrashed) I was able to identify the culprit: it's a driver power failure of my mellanox infiniband card. It's a very old card, worked well in windows 7, survived windows 10, but it seems it has issue in windows 11. Luckily I don't use it very much and I can disable the card and unloading the driver (ibbus.sys) before rebooting/shutting down.

Hello it seems related to nvme(s) and its/their power savings. Try to disable at all the nvme power saving with nvme_core.default_ps_max_latency_us=0 as a kernel parameter. Modify your syslinux and add it to the append line (for unraid Os without gui): append nvme_core.default_ps_max_latency_us=0 initrd=/bzroot