ghost82

It's the .fd file where nvram variables are stored, it's defined in the xml, between <nvram></nvram>, for example: <nvram>/opt/macos/OVMF_VARS.fd</nvram> In your case, it's missing in that path, why I don't know. If you still see methods 1 and 2, yes, remove the container and install the new one.

Not sure if it's possible at all by passing the disks by by-id, but if you have a second sata controller, pass it through with all the disks attached and they will be seen as native. This is an example of my disk in a mac os vm with a sata controller passed through:

If you have access to the vm a copy of your ioreg could help, also you could share your opencore image or efi folder. What version of mac os you are running? And what is that "Display" gpu listed under "Video card"? Can you share your xml?

diagnostics may help, this log says nothing.

I can't see anything in logs, so my suggestions are: 1. setup the vm with vnc only 2. boot the vm and enable remote desktop or any other remote management software inside the vm 3. Optional: try from an external device to connect to the remote desktop installed inside the vm and check that everything works 4. Remove vnc and qxl from xml and setup your gpu passthrough (vfio setup is already ok): set it as multifunction, replace this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/vbios/Geforce_RTX2070.rom'/> <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='0x01' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </hostdev> with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/vbios/Geforce_RTX2070.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> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x2'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x3'/> </hostdev> 5. Check the vbios you are passing, remove the nvidia header if you dumped it with gpuz 6. Connect a monitor to the gpu and boot the vm; if you get a video output stop here 7. If no video output, connect to the vm from an external device to remote desktop installed previously inside the vm 8. Check in device manager if you have your gpu listed 9. if you have your gpu listed but with some error code, like error 43, install latest nvidia drivers 10. If it still doesn't work, I would try to physically change the pcie slot of the gpu, if it's possible at all (sometimes source bus 01 has some issue in some builds) Optional: in the meantime, between one point and another, if you are a religious man, you can pray some god of your choice to have the setup to work If it still doesn't work attach new diagnostics with all these changes applied and descriptions of what you did.

Installation is not from disk to disk, but it's a network installation, meaning that you download the base system image and then download from apple servers the installer.

exactly.

There's no more method 1 and 2

An important clarification! bus 0x01 is not "built-in", bus 0x00 is. However, in the code in github it is (in)correctly set to bus 0x00. "Incorrectly" because the address of the nic is currently set at bus 0x00, slot 0x00 and function 0x00, which should be a reserved address for host bridge! This should be changed to bus 0x00, slot 0x02 and function 0x00

Try replacing video driver with something else. qxl for example, see if it boots, then (if) once installation finishes, if you want vmga for a particular reason try to replace again. Change this: <video> <model type='vmvga' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> With this: <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>

You didn't provide any data, on the contrary you are saying that "log looks normal", that means everything is ok. No polemics, but you should try a little harder to provide some data, maybe diagnostics? Diagnostics includes lots of data about your system and the vm configuration so one can have a look and maybe find something to fix. So, make your changes for your gpu passthrough, try to start the vm, save diagnostics and attach the file here to share with others.

Are you sure? https://www.nv-drivers.eu/download-GeForceGTX750Ti-drivers-for-WindowsXP-32bit.html https://www.nv-drivers.eu/final-download-driver-for-GeForceGTX750Ti-with-id-168.html Official website: https://www.nvidia.com/en-us/drivers/results/105040/ http://us.download.nvidia.com/Windows/368.81/368.81-desktop-winxp-32bit-international.exe Old drivers require workarounds to mask vm detection.

This helps, so we know that the setup is correct. I then suspect is an ovmf bios issue: I don't know what version of ovmf unraid includes, you can try the attached ones, save them somewhere and point the paths in the xml of the vm of OVMF_VARS.fd and OVMF_CODE.fd to these new files. OVMF_commit-6612ff8-24-12-2021.zip

From what I read the qxl driver (the spice protocol has nothing to do with the issue) is missing 2560x1080. A workaround is to install virt-manager and connect to the vm with it with the following settings: View -> Scale display -> Auto resize VM with window

This may help: https://askubuntu.com/questions/729673/ubuntu-full-disk-encryption-with-encrypted-boot/801394#801394 It's for ubuntu, but it can be adapted for kali. Witch error you get? Did you add GRUB_ENABLE_CRYPTODISK=y?

Gpu is not set as multifunction. You didn't run the vm before attaching diagnostics, so no info on what's happening. Gpu is not isolated (attached to vfio). You may need to dump and use your vbios. Run the vm, then attach diagnostics if you are not able to fix yourself.

unraid has no drivers for wifi, but the stick will be recognized and it could be passed to the vm, into which it will run natively.

What do you mean by 'separate'?Not bridged network or with a totally different network carrier? If it's the first, instead of passing through that stick, you can try to passthrough a wifi stick, pretty a standard device to passthrough compared to the 3g modem. If you want a totally separated network I would opt for a 3g modem to allocate the sim with wifi capabilities + usb wifi stick to passthrough.

There are no guides as far as I know, nor a known method to passthrough that usb stick modem; all I know is that the device may split into multiple usb devices after initialization. Sending AT commands to the modem could also help in not initializing the stick in the host. However you need to search and test by yourself.

Try to access ovmf bios with esc button and boot manually the windows entry; if it works change boot order and save.

I have zero experience with encryption/lvm, I don't think the issue is related to this; did you create (manually or automatically) the efi partition and installed grub on it?

It should be an issue with the nvidia drivers (1) or hardware related (2). (1) Set the gpu as multifunction, replace this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x3f' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/isos/Gigabyte.GTX980Ti.6144.151027_fix.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x3f' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x3f' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/mnt/user/isos/Gigabyte.GTX980Ti.6144.151027_fix.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x3f' slot='0x00' function='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/> </hostdev> It can be wrong vbios Gigabyte.GTX980Ti.6144.151027_fix.rom: do not download it but dump it (linux preferred, or gpuz+hex edit) Use latest nvidia drivers Switching to q35 machine type may help (2) faulty gpu, but could be also the psu

Your amd gpu needs the vendor reset plugin to properly initialize. So, does it work if you reboot the vm? The only cases I read about issues with the amd patch and the audio part not being able to initialize properly is with some 5000 amd series card.

Just for info, when you are in the uefi shell, if you type 'exit' it should reboot the vm without closing the vnc connection, so you don't lose time for opening a new vnc window. Yes, that was exactly what I wanted to write, sorry for not giving a more detailed description. Not sure why the entry is not automatically detected.

In the screenshot you posted you have the map of your drives and you see FS0, that is the partition which most probably contains the EFI folder with the .efi payload.