ghost82

Try to increase the ram in the vm. Try with 2 gb, then if it doesn't work and you can, to 4 gb. I think 2 gb should not fail.

It seems it doesn't support uefi and it's too old, for me it's a no go. Apple os uses a lot of gpu acceleration, more than any other os, so as you found, no gpu means laggy and near unusable system.

Unfortunatly it seems Battleye is checking several things, and unfortunately some of these checks cannot be bypassed with a simple xml edit. One has to build qemu from source (and maybe also ovmf), after changing some parts of the source code, and edit xml manually to change hdd names, usb names, cpuid, system bios data, motherboard manufacturer and timing checks, no other virtual devices, and also some windows registry keys. Not simple at all, banning vms in this way is simply bullshit...such closed minds, why not understanding that vms are the future...they're saying that 90% of vms are used for cheating...if they have these statistics why not build an anti cheat that checks for regular vm use... Having said that, even if you bypass all the checks and you are not getting banned you are breaking their tos.

Re create the issue and then attach diagnostics without rebooting

OVMF from edk2 repository, version stable 202302: https://github.com/tianocore/edk2/ OVMF_EDK2_202302_Stable.zip

Just to add an additional info, if you download from the home assistant website: https://www.home-assistant.io/installation/alternative to download the qcow2 file (KVM/Proxmox) you will download a compressed .xz file. Remember to all to extract the qcow2 image from this archive before using it as a disk in a kvm vm.

A reset of the nvram (clean ovmf vars file) should fix it and/or you should be able to add a new boot entry from the ovmf bios. Start the vm and press esc untill you go into the ovmf bios windows; if you boot in the uefi shell just type 'exit' without quotes and press enter to access ovmf bios settings. Then, follow this to add a new boot option or boot directly to the correct partition: https://pve.proxmox.com/wiki/OVMF/UEFI_Boot_Entries

ooooh I see now...you downloaded the arch64 architecture which is unsupported, you need to download the x86_x64 version!

Yes you are right, the nic settings should show in the vm settings gui. I read a similar issue and that user was able to make it show by resetting the unraid network configuration; he deleted the config and created a new one.

Yes topology is now correct for i440fx, as you can see you have the nic on bus 0, slot 3 and function 0. I think the issue here was a wrong target address. For windows unraid defaults to i440fx but I would think twice before using it (I'm not saying it doesn't work), but q35 is more compatible with passed through pcie devices.

try to boot from the uefi shell: type: FS0: and press enter Then list directories and files with dir command (the uefi shell is like a command prompt) and navigate (with the cd command) somewhere since you will find an .efi file to boot. No idea what is the file in your case, as an example for microsfot it's in: FS0:\EFI\Microsoft\Boot\bootmgfw.efi To manually boot, just type name.efi and the boot should proceed.

change disk type to sata instead of virtio?

I remember I read that the issue can come for the audio part of the gpu. try to remove this block in the xml: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev> in other words remove the passthrough of the audio with source address: <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> and see if it crashes. Another test, for shoutdown/boot (not for reboots): you can try to manually remove the gpu (video and audio) and rescan for it, and then start the vm. You can try this and see if it works without crashing. 1. start the vm, it should output video 2. shutdown the vm 3. open a terminal in unraid and give the following commands, press 'enter' after each line: echo "1" | tee -a /sys/bus/pci/devices/0000\:03\:00.0/remove echo "1" | tee -a /sys/bus/pci/devices/0000\:03\:00.1/remove sleep 1 echo -n mem > /sys/power/state sleep 1 echo "1" | tee -a /sys/bus/pci/rescan 4. start the vm

Unfortunately I think not for your case: unraid should have the patch included, but this patch, the gnif reset vendor patch, does not include the 6000 series

Being an old nvidia you could have error 43 in the vm and no video output. Nvidia in the past did not allow consumer gpus to be passed through and used in a vm: there could be workaround to add to the xml just to mask that the gpu is running in a vm and make the drivers to work. Newer drivers don't have this issue, since nvdia is allowing gpu passthrough now.

All I can say is that from what I saw your configuration is correct and unfortunately the errors recall the so called 'amd reset bug', which the 6000 series shouldn't have..but some reports show that some of them could have it, it's not clear if it depends on the gpu or the bios or whatever, so trying a nvidia is the right way to go, just to see if it depends on the gpu itself.

Did you try to mount and map the partition in the 2 vms as a smb share? For my steam games I load them from a smb drive and they work quite well.

I doubt you had unsupported vt-d: vt-d is needed for vfio, so it had to be available.. anyway just proceed the same way as described in the above posts.

In your last diagnostics you defined a i440fx machine type vm. Unless you changed it to q35, you cannot have in the target vm bus 1, so either you changed the machine type or the host automatically changed the target address to be on bus 0 (machine type i440fx has only bus 0!). i440fx: only bus 0, choose first available slot, each address must be unique q35: bus 0 for built-in devices, choose first available slot, bus>0 for not built-in devices (bus X means it's attached usually to pcie-root-port or pcie-to-pci-bridge defined in xml, with index X), each address must be unique

I heard of some possible issues with the 6000 series and some specific brands. When you say it crashes, does it crash the whole hotst or you are not able to run only the vm? Check in bios: 1. resizable bar: disabled 2. decode above 4g: disabled if this doesn't work I have no more ideas.

Yes now select both 13 and 14. ok course otherwise you wont be able to passthrough anything.

yes. By split I mean having the two amd pci bridges not in the same iommu group of the vga and audio. Now 2 amd pci bridges together with vga and audio are in iommu group 1. Check if with acs override you can have vga and audio in one or 2 different iommu groups, other than the iommu group of the pci bridges. Then attach to vfio only vga and audio and not the bridges.

Try the followings: 1. enable acs override --> both (meaning downstream,multifunction); restart the server, check if you are able to split the current iommu group 1, try to split the amd pci bridges from vga and audio; do not attach to vfio pci bridges at 01:00.0 and 02:00.0, only video and audio of the gpu 2. change in your vm xml the gpu part from this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <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='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> to this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev>

there's nothing wrong in here, describe your issue and post full diagnostics

yes correct