ghost82

Change network from virtio (or virtio-net) to e1000-82545em. Change disks from virtio to sata.

Seems like the gpu is not properly isolated and as soon you restart or shoutdown the vm the host is using it without releasing it properly on the next vm boot.

Resize command of qemu-img doesn't work on vmdk files; you need to convert vmdk to qcow2 or raw with qemu-img convert command, then resize it.

he is speaking about the kernel of the linux virtual machine, not that of unraid. I think he simply updated the kernel of the virtual machine: centos should use yum command, so, 'sudo yum -y update' should update the system, including the kernel.

Yes, unraid terminal (mount is a linux command) Not sure I understood..the vdisk has to be saved somewhere that could be accessed by the host (unraid) with read/write permissions. To see if your share folder "works" try to access it with the cd command in the unraid terminal (cd /path/to/the/share) and try to create a file (touch test.txt). If it doesn't work, choose another folder or fix what it doesn't work.

Make sure you have big sur 11.4 at least, previous versions don't have the drivers for navi 21.

You probably didn't set your gpu as a multifunction device; whatevergreen kext needs the audio part to be on function 1, same slot and same bus as the video part of the gpu, as in the real hardware.

You need to download the right qcow2 file, you are using aarch64 qcow2, which is for arm, but you are using x64 qemu.

Don't bother to it, cpu-z fault.

change from this: <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/HomeAssistant/haos_ova-10.3.qcow2'/> to this: <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/HomeAssistant/haos_ova-10.3.qcow2'/>

Usually, windows 10 vms are configured with cpu hostpassthrough, so if the real cpu supports aes, the aes flag will be passed to the guest too...can you check with cpu-z if aes is listed in the cpu flags?and what is the real cpu?

You need the full dsdt aml file (so, compiled file, use maciasl for example) saved in EFI/OC/ACPI folder, and then you need to add it in the opencore config: config.plist -> ACPI -> Add You can find copies of my dsdts in the gitlab link above, but take into account that part of the dsdt is built based on the addresses you have in the xml. My issue was related to the passed through sata controller. The new qemu 8 adds names (S00, for example) in the dsdt for all the devices attached to pcie root ports, and for whatever reason my sata controller doesn't like it. Once understood the issue, my final fix was to hide the S00 for the specific sata controller in a ssdt, instead of injecting the whole old dsdt.

delete vfio-pci.ids=1ac1:089a from syslinux, reboot, and you should see it listed for passthrough.

You have actually 2 scsi controllers defined: And your optical drive is attached to controller with index 0: Settings are correct. Since you are passing the optical drive only and not the whole controller, the optical drive is attached to a virtio emulated scsi controller and you need drivers for it, drivers are not included in windows. So, open device manager and manually install drivers for the 2 controllers (option "I have a disk"). After mounting the virtio iso inside the vm, point the driver search to x:\vioscsi\w11\amd64\ directory. If you have issues with the 225 virtio release try the latest one: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.229-1/virtio-win-0.1.229.iso

Add this to your syslinux config (in the block of unRAID OS label): Main - Boot Device - Flash - Syslinux Configuration label unRAID OS menu default kernel /bzimage append intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot Reboot Then, obviously start unraid without gui

download and install nvidia drivers, latest: https://www.nvidia.it/Download/driverResults.aspx/205173/en-us

I think you need to include in your vm settings also the audio part of the gpu, iommu group 28, address 2b:00.1. Make it a multifunction device with the video part of the gpu.

It's not, read carefully, there are files attached ready to be used, or alternatively instructions to build yours.

Please don't take it badly, I'm only trying to give proper info on this. You use vbios when it's needed, i.e. when the gpu that has to be passed is flagged as boot vga by the host; in all the other cases there's no need to pass a vbios; to check if it's flagged as "boot vga" one has to simply check for that string in the system log and check the corresponding address. This is because the video rom saved by the host it's not a 1:1 copy of the video rom of the gpu if it's flagged as boot vga; if it's not the boot vga the video rom is a 1:1 copy. As far as multifunction, one has to always set the gpu as a multifunction device: in bare metal hardware the gpu is a multifunction device so we emulate it as a multifunction device. Although the gpu can work if the gpu is not set as multifunction in the guest, in some cases, if it is not set as multifunction drivers can play badly. Moreover it's always strongly suggested to pass all the subdevices to the vm (video, audio, usb controller, etc.), for the same reason described above. +1 for checking cpu features.

--> video=efifb:off

Thanks, I have no solution, everything is correctly, as far as I can see, configured. The only thing I found is: May 23 20:57:30 Tower kernel: vfio-pci 0000:03:00.0: vfio_ecap_init: hiding ecap 0x1e@0x258 May 23 20:57:30 Tower kernel: vfio-pci 0000:03:00.0: vfio_ecap_init: hiding ecap 0x19@0x900 May 23 20:57:30 Tower kernel: pmd_set_huge: Cannot satisfy [mem 0xe0000000-0xe0200000] with a huge-page mapping due to MTRR override. which may break the gpu passthrough... Some suggest to boot with 'nohugeiomap' kernel argument (in your syslinux configuration), don't know if it can work..

it could be that the application you are running inside windows is not capable of running on multiple threads.

That's because model is not defined in libvirt. I don't think disk model was implemented in libvirt. Try to add a qemu override and see if that works. So, for serial and model do the following: - define the disk block with your disk, set a serial and give it an alias starting with ua-: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/path/to/disk.img'/> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' unit='1'/> <alias name='ua-mydisk'/> <serial>YOURSERIALNUMBERHERE</serial> </disk> - add at the bottom before the domain closing tag a qemu override referring to the alias: <qemu:override> <qemu:device alias='ua-mydisk'> <qemu:frontend> <qemu:property name='model' type='string' value='VMware Virtual IDE Hard Drive'/> </qemu:frontend> </qemu:device> </qemu:override> </domain> And make sure you defined the proper legacy schema at the top of your xml: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

May be caused by virtiofs; try to stop using this and use a samba share for example and see if the crashes stop.