ghost82

Sorry, my error, yes it's on .3. Currently your hdmi is on bus 4, connected to a pcie-to-pci-bridge, which doesn't sound correct to me. Without changing anything else, try this: <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh edit Libreelec or other application using the libvirt API. --> <domain type='kvm'> <name>Libreelec</name> <uuid>95170484-4711-898d-d1da-8da9fe928b9d</uuid> <metadata> <vmtemplate xmlns="unraid" name="Linux" icon="linux.png" os="linux"/> </metadata> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='8'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='10'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-7.1'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/95170484-4711-898d-d1da-8da9fe928b9d_VARS-pure-efi.fd</nvram> <boot dev='hd'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='2' threads='2'/> <cache mode='passthrough'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Libreelec/vdisk2.img'/> <target dev='hdc' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-to-pci-bridge'> <model name='pcie-pci-bridge'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0xb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x8'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x9'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0xa'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <interface type='bridge'> <mac address='52:54:00:d6:d9:4f'/> <source bridge='br0'/> <model type='virtio-net'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <audio id='1' type='none'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x1f' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x046d'/> <product id='0xc52b'/> </source> <address type='usb' bus='0' port='1'/> </hostdev> <memballoon model='none'/> </devices> </domain> Do not pass to the vm the serial bus controller, but keep it bound to vfio, as it is now. Let me know if something changes.

Post a diagnostics file so I can check the vm configuration. q35 machine type should be a better option. It could depend on the layout you set for the video and audio and how the driver interacts: in a bare metal machine you have the video at 00:02.0, so vga is on bus 0, slot 2, this is specific for built-in gpu, and audio is on 00:1f.5, so also the audio is built-in. If the target addresses of both video and audio are wrong in the vm, the driver could not work properly.

Search in the log for "boot vga" (there could be several entries): if you read 01:00.0 next to it you need vbios, otherwise not.

1. Feb 8 01:37:18 WoNas kernel: pci 0000:01:00.0: BAR 1: assigned to efifb You need video=efifb:off in your syslinux config. 2. Since your nvidia is marked as boot vga: Feb 8 01:37:18 WoNas kernel: pci 0000:01:00.0: vgaarb: setting as boot VGA device (overriding previous) you need a vbios to pass 3. multifunction for gpu: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <rom file='/PATH/TO/YOUR/VBIOS.rom'/> <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='0x01' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev>

I think no, we are speaking for intel with vmx and it should be equivalent to vt-x, so it doesn't include vt-d, needed for passthrough of devices.

Windows doesn't support natively xfs, you should be better to format the disk with a windows supported format, i.e. ntfs. XFS partitions can be accessed from windows with third party softwares, for example paradox, linux reader, etc.

I'm using virtio on a mac vm with an emulated controller bridged to an old 82574L Gigabit Network Connection (1 GbE), and I have 14+ Gbs/s, approaching 20 Gbs/s from host to guest: iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.2.2, port 49359 [ 5] local 192.168.2.1 port 5201 connected to 192.168.2.2 port 49360 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.66 GBytes 14.3 Gbits/sec [ 5] 1.00-2.00 sec 1.61 GBytes 13.8 Gbits/sec [ 5] 2.00-3.00 sec 1.68 GBytes 14.4 Gbits/sec [ 5] 3.00-4.00 sec 1.70 GBytes 14.6 Gbits/sec [ 5] 4.00-5.00 sec 1.71 GBytes 14.7 Gbits/sec [ 5] 5.00-6.00 sec 1.72 GBytes 14.8 Gbits/sec [ 5] 6.00-7.00 sec 1.71 GBytes 14.7 Gbits/sec [ 5] 7.00-8.00 sec 1.72 GBytes 14.8 Gbits/sec [ 5] 8.00-9.00 sec 1.72 GBytes 14.8 Gbits/sec [ 5] 9.00-10.00 sec 1.67 GBytes 14.4 Gbits/sec [ 5] 10.00-10.00 sec 2.35 MBytes 14.7 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 16.9 GBytes 14.5 Gbits/sec receiver ----------------------------------------------------------- Server listening on 5201 (test #2) ----------------------------------------------------------- iperf3 -c 192.168.2.2 Connecting to host 192.168.2.2, port 5201 [ 5] local 192.168.2.1 port 38408 connected to 192.168.2.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.31 GBytes 19.8 Gbits/sec 0 3.93 MBytes [ 5] 1.00-2.00 sec 2.08 GBytes 17.8 Gbits/sec 0 3.93 MBytes [ 5] 2.00-3.00 sec 2.07 GBytes 17.8 Gbits/sec 0 3.93 MBytes [ 5] 3.00-4.00 sec 2.04 GBytes 17.5 Gbits/sec 0 3.93 MBytes [ 5] 4.00-5.00 sec 2.20 GBytes 18.9 Gbits/sec 0 3.93 MBytes [ 5] 5.00-6.00 sec 2.28 GBytes 19.6 Gbits/sec 0 3.93 MBytes [ 5] 6.00-7.00 sec 2.28 GBytes 19.6 Gbits/sec 0 3.93 MBytes [ 5] 7.00-8.00 sec 2.29 GBytes 19.6 Gbits/sec 0 3.93 MBytes [ 5] 8.00-9.00 sec 2.31 GBytes 19.8 Gbits/sec 0 3.93 MBytes [ 5] 9.00-10.00 sec 2.28 GBytes 19.6 Gbits/sec 0 3.93 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 22.1 GBytes 19.0 Gbits/sec 0 sender [ 5] 0.00-10.00 sec 22.1 GBytes 19.0 Gbits/sec receiver iperf Done.

Are you using virtio or virtio-net for the emulated controller? I don't remember which is faster, I think I remember it's virtio, try to switch to it and retest. Unraid default virtio-net, if I remember well, should be because of some issues with vms and dokers, if you use them.

I think the issue is in the vdisk, somehow corrupted. If I were you I would backup the vdisk image to store an original copy of it and then create a new vm with that vdisk and the gparted iso: you will boot from the gparted live iso and you could check disk and partitions of vdisk and maybe you could repair it.

ahah no need to send anything!I'm happy you got it working. Just do a good action to another person and maybe the world will be better

Not of much help unfortunately, we already know that the vm should work without the passed through gpu..Try to proceed with other steps, but I think you will stop at step 6.. I have a doubt that it could be the vbios..if this is the case you need to find a way to dump it from your gpu..

It seems all is ok now. Can you try the following and report back: 1. Let the syslinux config as it is 2. modify your vm to not pass through the gpu (video and audio), replace it with vnc: check if it boots 3. boot the vm and connect with novnc (directly in unraid) (from your laptop) 4. enable remote desktop inside the vm or install any other vnc server inside windows 5. disable vnc in your vm and passthrough the gpu, check multifunction for gpu is applied 6. start the vm and try to connect to the vm ip from your laptop, so you are connecting directly to the vm 7. if it boots check device manager to see if the gpu is there 8. if it's there, download nvidia drivers and install them

Do not boot the gui mode, but unraid os, as said gpu is isolated from unraid and it cannot be used by the host (unraid), but it will be reserved for the vm. If you look at what you modified in the syslinux config you can see that you modified the "unraid os", not the "unraid os gui mode", so the efifb:off is applied when you boot "unraid os" (command line). Boot unraid os, then connect from the laptop on the lan, then start the vm. Your screenshot shows a kernel panic, system wasn't able to find root partition, this may depend on the unraid usb, try to boot again.

You should be able to do it just by following this video: https://www.youtube.com/watch?v=QaB9HhpbDAI Start from minute 8, 27th second Just type from unraid terminal: ls /dev/disk/by-id to identify your nvme disk (spaceinvadersone uses a sata disk with prefix "ata-", yours will probably be "nvme-")

Because it's in use by the host, as said. There are different scenarios: 1. by phisically attaching the nvme to a dedicated controller you are able to isolate it, no other disks in use by the host are connected to this controller --> bind this controller to vfio and use it in a vm; this will pass through both the controller and the disk (and everything that it's attached to this controller, if not in use by the host) (preferred solution) 2. you are not able to isolate the nvme, the nvme is attached to a controller with something else in use by the host --> pass the disk with by-id, this will create an emulated controller and use the nvme disk (2nd choice) 3. you are not able to isolate the nvme, the nvme is attached to a controller with something else in use by the host --> create a vdisk on the nvme, this will create an emulated controller and use the vdisk on the nvme disk (3rd choice)

xml is ok, make sure that it wont change the gpu part you highlighted after making modifications. As you can see in your logs: Feb 4 10:44:34 Akashic-Records kernel: pci 0000:06:00.0: BAR 1: assigned to efifb ... ... Feb 4 10:59:41 Akashic-Records kernel: vfio-pci 0000:06:00.0: BAR 1: can't reserve [mem 0xd0000000-0xdfffffff 64bit pref] you need to modify your syslinux config (main > flash > syslinux configuration) and add in the append line video=efifb:off, like in this picture taken from the web: Note that since this gpu is marked as boot gpu the screen on boot will seem frozen, because the gpu will attach to vfio, but unraid will boot, so connect to unraid from another device on the lan. Reboot the server. It seems also that you are using a wrong vbios. From what I found the vbios you attached is for a 3060 Ti, device/vendor id 10de:2489, subsystem 1043:8829. From your lspci your device is 10de:2489, subsystem 1043:884f. It is always better to dump the vbios directly from YOUR gpu, in extreme cases you could download a vbios from techpowerup: this will prevent you from using a wrong vbios, as it seems the case. So, dump the vbios from your gpu and use it (check if hex editing is needed, i.e. if dumped from windows with gpu-z), or if you have no alternatives and it doesn't work with your vbios try the attached one (already hex edited). 241689.rom

https://github.com/SpaceinvaderOne/Macinabox/blob/master/xml/Macinabox BigSur.xml#L132-L142

Hi, it's described here: So, you created a raw disk and formatted fat32. Then you mount this disk somewhere, like: mount /path/to/vdisk.img /path/to/mount/ And you copy all the files into it, like: cp /path/to/file.ext /path/to/mount/ And finally you can unmount the vdisk: umount /path/to/mount/ When you add the vdisk to the vm use a virtual sata controller for maximum compatibility.

Basically copy xml in a text file, copy vdisk.img, copy the ovmf_vars.fd. Create a new empty vm and do not start it. Replace the new xml code with the one from the xml backup. Check the paths in the code of the xml for the vdisk.img and for the ovmf_vars.fd and change them pointing to that of your backup files. If the vm fails to start because of the uuid, meaning it's duplicated, delete the uuid line in the xml, libvirt will automatically create a new one.

there are 2 fd file, one is the ovmf bios, which can be created new, they all are the same. The other is the var fd which contains the efi variables, you can use the backup (by pointing in the xml to the backup vars fd file) if you want to backup the efi variables or you can use a new one, in this case it's like as you do a nvram reset.

mmm I don't know, can you paste the full backtrace? Once you reboot a window should popup, click on show details and paste all here, it should be something like this: panic(cpu 0 caller 0xffffff8006262e0a): Kernel trap at 0xffffff7f8998c7ce, type 14=page fault, registers: CR0: 0x000000008001003b, CR2: 0x0000000000000000, CR3: 0x000000001badf000, CR4: 0x00000000003626e0 RAX: 0x0000000000000000, RBX: 0xffffff9124ef5000, RCX: 0xffffff8006aa30a0, RDX: 0x0000000000000000 RSP: 0xffffff9124e7bd10, RBP: 0xffffff9124e7bd20, RSI: 0xffffff802d320240, RDI: 0xffffff9124ef5000 R8: 0x0000000000000000, R9: 0x0000000000000004, R10: 0x0000000000000051, R11: 0xffffff8028537000 R12: 0x0000000000000000, R13: 0x0000000000000000, R14: 0xffffff9124ef5000, R15: 0xffffff802e5a2000 RFL: 0x0000000000010282, RIP: 0xffffff7f8998c7ce, CS: 0x0000000000000008, SS: 0x0000000000000010 Fault CR2: 0x0000000000000000, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 1 Backtrace (CPU 0), Frame : Return Address 0xffffff9124e7b770 : 0xffffff8006139a3b 0xffffff9124e7b7c0 : 0xffffff8006270fe5 0xffffff9124e7b800 : 0xffffff8006262a5e 0xffffff9124e7b850 : 0xffffff80060e0a40 0xffffff9124e7b870 : 0xffffff8006139127 0xffffff9124e7b970 : 0xffffff800613950b 0xffffff9124e7b9c0 : 0xffffff80068d17f9 0xffffff9124e7ba30 : 0xffffff8006262e0a 0xffffff9124e7bbb0 : 0xffffff8006262b08 0xffffff9124e7bc00 : 0xffffff80060e0a40 0xffffff9124e7bc20 : 0xffffff7f8998c7ce 0xffffff9124e7bd20 : 0xffffff7f8998c916 0xffffff9124e7bd40 : 0xffffff7f89980531 0xffffff9124e7bd60 : 0xffffff7f8998044f 0xffffff9124e7bd80 : 0xffffff7f8995e45d 0xffffff9124e7bdb0 : 0xffffff7f8995c92b 0xffffff9124e7bde0 : 0xffffff800681a336 0xffffff9124e7be40 : 0xffffff8006819ee1 0xffffff9124e7bef0 : 0xffffff800681922e 0xffffff9124e7bf50 : 0xffffff800681b9cd 0xffffff9124e7bfa0 : 0xffffff80060e013e Kernel Extensions in backtrace: com.apple.driver.AppleIntelSKLGraphics(14.0.2)[11074779-5CB6-3C9C-98F4-7F745CDCFDE0]@0xffffff7f89951000->0xffffff7f89a43fff dependency: com.apple.iokit.IOPCIFamily(2.9)[AA7C7A4F-9F5D-3533-9E78-177C3B6A72BF]@0xffffff7f86ea2000 dependency: com.apple.iokit.IOSurface(269.6)[39DC4195-B168-3895-ACD5-E731581855F8]@0xffffff7f877e7000 dependency: com.apple.iokit.IOGraphicsFamily(568)[247C211E-C250-351C-BCE2-4DB9D3003E10]@0xffffff7f8935f000 dependency: com.apple.iokit.IOAcceleratorFamily2(438.2.7)[72B8A0B5-E12C-3764-9187-0AC0E93416F9]@0xffffff7f893b0000 BSD process name corresponding to current thread: kernel_task Boot args: dart=0 nv_disable=1 -v Mac OS version: 19B88 Kernel version: Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 Kernel UUID: 7503CD47-851F-321E-8747-50DB4299165F Kernel slide: 0x0000000005e00000 Kernel text base: 0xffffff8006000000 __HIB text base: 0xffffff8005f00000 System model name: iMac17,1 (Mac-B809C3757DA9BB8D) System shutdown begun: NO Panic diags file available: YES (0x0) System uptime in nanoseconds: 173374690057 last loaded kext at 79505135625: >!AGraphicsDevicePolicy 4.5.9 (addr 0xffffff7f89c03000, size 86016) last unloaded kext at 62534305083: >!A!ILpssGspi 3.0.60 (addr 0xffffff7f8847b000, size 45056) loaded kexts: com.insanelymac.RealtekRTL8111 2.3.0d7 com.rehabman.driver.USBInjectAll 0.7.1 org.netkas.driver.FakeSMC 1800 >!AGraphicsDevicePolicy 4.5.9 @AGDCPluginDisplayMetrics 4.5.9 >!AHV 1 |IOUserEthernet 1.0.1 |IO!BSerialManager 7.0.1f1 >!AUpstreamUserClient 3.6.8 >!AMCCSControl 1.13 >AGPM 111.2.5 >X86PlatformShim 1.0.0 >!APlatformEnabler 2.7.0d0 >pmtelemetry 1 >!AHDAHardwareConfigDriver 283.14 >!A!ISKLGraphics 14.0.2 @Dont_Steal_Mac_OS_X 7.0.0 >!AHDA 283.14 >!A!IPCHPMC 2.0.1 >ACPI_SMC_PlatformPlugin 1.0.0 >!A!ISKLGraphicsFramebuffer 14.0.2 >!AFIVRDriver 4.1.0 >!A!ISlowAdaptiveClocking 4.0.0 @filesystems.autofs 3.0 @filesystems.ntfs 3.14.3 @fileutil 20.036.15 @filesystems.apfs 1412.41.1 >!AVirtIO 1.0 @filesystems.hfs.kext 522.0.9 @!AFSCompression.!AFSCompressionTypeDataless 1.0.0d1 @BootCache 40 @!AFSCompression.!AFSCompressionTypeZlib 1.0.0 >!AAHCIPort 341.0.2 @private.KextAudit 1.0 >!ARTC 2.0 >!AACPIButtons 6.1 >!AHPET 1.8 >!ASMBIOS 2.1 >!AAPIC 1.7 $!AImage4 1 @nke.applicationfirewall 303 $TMSafetyNet 8 @!ASystemPolicy 2.0.0 |EndpointSecurity 1 >!AGraphicsControl 4.5.9 |IOAVB!F 800.17 >!ASSE 1.0 |IO!B!F 7.0.1f1 |IO!BPacketLogger 7.0.1f1 >!ASMBus!C 1.0.18d1 |IOSMBus!F 1.1 >DspFuncLib 283.14 @kext.OSvKernDSPLib 529 |IONDRVSupport 568 >IOPlatformPluginLegacy 1.0.0 @!AGPUWrangler 4.5.9 >!AHDA!C 283.14 |IOHDA!F 283.14 |IOAudio!F 300.2 >!A!ILpssGspi 3.0.60 >usb.IOUSBHostHIDDevice 1.2 >!ASMBusPCI 1.0.14d1 @!AGraphicsDeviceControl 4.5.9 |IOAccelerator!F2 438.2.7 |IOGraphics!F 568 >X86PlatformPlugin 1.0.0 >IOPlatformPlugin!F 6.0.0d8 |IOSlowAdaptiveClocking!F 1.0.0 @plugin.IOgPTPPlugin 810.1 |IOEthernetAVB!C 1.1.0 |IOSkywalk!F 1 @kext.triggers 1.0 |IOAHCIBlock!S 316.40.3 @vecLib.kext 1.2.0 >usb.networking 5.0.0 >usb.!UHostCompositeDevice 1.2 >usb.!UHub 1.2 |IOSerial!F 11 |IOSurface 269.6 @filesystems.hfs.encodings.kext 1 |IOAHCI!F 290.0.1 >usb.!UXHCIPCI 1.2 >usb.!UXHCI 1.2 >usb.!UHostPacketFilter 1.0 |IOUSB!F 900.4.2 >!AEFINVRAM 2.1 >!AEFIRuntime 2.1 |IOHID!F 2.0.0 $quarantine 4 $sandbox 300.0 @kext.!AMatch 1.0.0d1 >DiskImages 493.0.0 >!AFDEKeyStore 28.30 >!AEffaceable!S 1.0 >!AKeyStore 2 >!UTDM 489.41.1 |IOSCSIBlockCommandsDevice 422.0.2 >!ACredentialManager 1.0 >KernelRelayHost 1 >!ASEPManager 1.0.1 >IOSlaveProcessor 1 |IOUSBMass!SDriver 157.40.7 |IOSCSIArchitectureModel!F 422.0.2 |IO!S!F 2.1 |IOUSBHost!F 1.2 >!UHostMergeProperties 1.2 >usb.!UCommon 1.0 >!ABusPower!C 1.0 |CoreAnalytics!F 1 >!AMobileFileIntegrity 1.0.5 @kext.CoreTrust 1 |IOTimeSync!F 810.1 |IONetworking!F 3.4 |IOReport!F 47 >!AACPIPlatform 6.1 >!ASMC 3.1.9 >watchdog 1 |IOPCI!F 2.9 |IOACPI!F 1.4 @kec.pthread 1 @kec.corecrypto 1.0 @kec.Libm 1

When you booted again there should be some more data on that window, you should be able to see what crashed.

it's different if you use a virtual or vfio gpu, amount of ram is different; they both work with virtual but I think you were at limit..

No, that's not how initial memory works; you couldn't run both vms with gpus because the amount of reserved ram was 32+32 (at boot systems use max memory, then you need a balloon driver in the guest and manually assign memory to the host or something else to do it automatically if you want dynamic memory), system log should had reported out of system memory. By decreasing to 16 you are able to run both vms (16+16 or 16+32). Take into account that unraid needs some ram too.

so is it solved? perfect I didn't notice the comma, which as you understood must not be there