• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by ghost82

  1. First check your iommu groups: you need all of the components of your gpu device in a iommu group, or each in its own iommu group, without other devices. Take the following picture as an example: Let's consider iommu group 29, which has the vga (video component) of the gpu (10de:2484) and the audio component (10de:228b) Both the audio and vga components are in the same physical device, the gpu. You need to passthrough all the components to make a proper passthrough, so you need to put a check (i.e. bound to vfio) both for the vga and for the audio compon
  2. May be an issue with the parrot os: first check that the sha256 of the iso is that reported to where you downloaded it, so to be sure the image is not corrupted in some way. Try to boot from the cdrom and go with the live, once booted in the live environment I read that you should have a link on the desktop to install the os. Different options: 1a. emulated controller, hd passthrough, whole disk You emulate a sata or virtio controller to which your passedthrough hd is attached 1b. emulated controller, hd partitions passthrough Same as above, but y
  3. You need to passthrough all the components of the gpu, for sure the audio part, and maybe also usb controllers (if any). Put that in the same bus, slot, each with a different function, in a multifunction device (N.B.: unraid fails from the vm setting gui to properly set correct addresses).
  4. From your original code: <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Parrot-kde-security-4.11.1_amd64.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/ParrotOS/vdisk1.img'/> <target dev='hdc' bus='sa
  5. I'm reading several posts of users asking for help about gpu passthrough not working in different operating systems in their virtual machines. If one uses the unraid gui in the setup of a virtual machine to passthrough the gpu and its audio part, unraid saves into the libvirt xml the video part into a target address, as far as I tested, domain = 0000, bus = xx, slot = 0, function = 0, and the audio part into another target address, domain = 0000, bus = yy, slot = 0, function = 0. This will results in different behaviors, the worst one is that the gpu isn't detected at all by the gues
  6. in the target, video is attached to 05:00:00 (bus:slot:function), audio is attached to 07:00:00 (bus:slot:function); attach audio to 05:00:01 (bus:slot:function) <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/storage/storage/files/dump.rom'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0' multifunction='on'/> </hostdev> <hostdev mode=
  7. Hi, not many information to help you. Please provide: 1. are you trying to install from scratch or to pass/convert an existing installation? 2. if you are trying to pass/convert an existing installation, was windows installed with legacy bios or uefi? was it a bare metal installation or other? 3. xml of the vm: provide q35+ovmf (if windows was installed in uefi mode), q35+seabios (if windows was installed in legacy bios mode) 4. any other useful information the above is one of the correct methods to pass the entire disk as source, of course if
  8. Maybe is it going to sleep? turn off sleep/hybernation
  9. The reply from @bastl contains some useful suggestions and correct information. Anyway: 1. your converted disk is not booting because you're using ovmf and your disk doesn't have any efi partition (see UEFI interactive shell, see no FS0 in the mapping table). Moreover, depending on the hardware version set in your vm with the "old" hypervisor, this may be incompatible with the machine type version you are using. This is a common issue with converted vmware images, for example. Update the hardware version of your vm in the old hypervisor and use seabios in qemu.
  10. Did you hotplug it once vm was started? If so, attach the converter before starting the vm, or reboot the vm once it's attached.
  11. Here the results of my tests, they were very fast, all results are expected. Note that these were done on an already installed Big Sur 11.4 (20F71) disc. Passed through cpu(s) are intel xeon E5-2687w (3,1 GHz). Emulated Penryn cpu DhinakG Penryn patch: NO CPU: Penryn 1 socket, 2 cores, 1 thread System booted? YES CPU detected as: 3,1 GHz Intel Core 2 Duo DhinakG Penryn patch: NO CPU: Penryn 1 socket, 1 core, 1 thread System booted? YES CPU detected as: 3,1 GHz Intel Core 2 Solo DhinakG Penryn patch: NO CPU: P
  12. something here sounds strange, because the image I linked is the same macinabox image, with updated opencore version, same settings, with added new patch for penryn. So if you were able to boot by adding the penryn patch on "your" image, you should boot also with "my" image. Here I'm not sure, because if the cpu is seen as penryn, the patch shouldn't be needed. Tomorrow I will have some spare time, I will test and report back, I'm just ready for some kernel panics No reason as far as I know.
  13. See the differences: Emulated Penryn cpu xml This results in: Note "Intel Core 2 Duo" cpu host passthrough This results in: Note "Intel Xeon E5 8 core" N.B.: when I use the host-passthrough I define topology with -smp custom qemu args instead of libvirt, it's the same, it doesn't change anything. So, if you don't read "Intel Core 2 Duo" your configuration is wrong.
  14. No, your cpus are perfectly fine, mac os is able to run with older cpus (back to pentium!); about xeon I'm running it on 2x e5-2687w (v1). First of all glad that you got it working. About the penryn patch, as I told to glennv, there's something strange: in the xml, in a standard macinabox installation (so no change in cpu, ram, passthrough, etc.), the cpu mode is defined in 2 places: <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='2' threads='1'/> </cpu> Here is defined as host-passthrough, so
  15. Take also into account that macinabox hasn't been updated from a quite long time, in respect to mac os updates. On the other hand mojave, catalina and big sur received security upgrades and minor version upgrades. Maybe the bootloader needs to be updated too with a more recent version, or use the included one to run an older minor version of mac os, compared to what it downloads. I know this may be frustrating since one expects to follow a tutorial and have things working.. I have an eavily customized big sur 11.4 vm, I upgrade opencore about once/twice a week and I never h
  16. I don't think so, nearly all the hardware is emulated and the template is the same, for all. Unfortunately, without debug logs (that of the bootloader, not that of unraid) it's nearly impossible to help. Writing as much information as possible and attaching the logs is important to debug issues, the "it doesn't work, there's a bootloop" is of no help.
  17. cpu is emulated as penryn with the default configuration, having an amd or intel is not the issue. Moreover intel can run natively with a ton of less patches compared to amd.
  18. Sharing my theme BigSurFlat for opencanopy, works with latest oc/ocbinarydata versions. Available on github:
  19. I think each mount must be attached to a pcie-root-port, so I added 2 more and changed some target addresses. Try this (updated): <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>Ubuntu</name> <uuid>606c95e9-2abc-dbd0-afa5-b3c9ae1d8685</uuid> <metadata> <vmtemplate xmlns="unraid" name="Linux" icon="linux.png" os="linux"/> </metadata> <memory unit='KiB'>52428800</memory> <currentMemory unit='KiB'>52428800</currentMemory> <memoryBacking> <nosharepages/> </
  20. Sorry, not true with driver version 466.63 (there's only the 3080ti, not the GT710): Driver v. 466.47 according to nvidia should support the GT710 and the 3080, but 3080ti is not listed...not sure you can run both...:
  21. Last thing: If you look at the second window from the left, the error points to bus 0, slot 8, function 0. This refers to the (wrong) audio part of the GT710, not the 3080 ti (see the source address and the wrong target address set in the vm below): <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/> </source> <alias name='hostdev2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function=
  22. If it doesn't work, I think you will need to change the machine type from i440fx to q35: with the i440fx pcie devices are detected as pci legacy endpoints. For some devices you won't notice any difference, others may have issues. Fastest way is to create a new q35+ovmf machine pointing at the same vdisk. Remember to apply the bus/slot/function modification, as above.
  23. The gui doesn't set the correct addresses when you passthrough the video and audio of the gpu. If you look at the source addresses for each gpu audio and video are on the same bus, same slot, and different function: For the GT710: Video on bus 1, slot 0, function 0 Audio on bus 1, slot 0, function 1 For the 3080ti: Video on bus 23, slot 0, function 0 Audio on bus 23, slot 0, function 1 So set the target addresses same way, you need a multifunction device. Replace this: <hostdev mode='subsystem' type='pci' managed='yes'>
  24. See also this: I think you can start the installer from the uefi shell too. If there's an efi pa rtition windows boots with ovmf, if there isn't windows boots with seabios. Fast boot is to boot faster but it can be a works like a sort of hibernation. Secure boot prevents tampering of the bootloader and system files and it check digital signatures of option roms, again also this can be a pain.. So I disabled them all. Exact: if you have a uefi gpu, most probably it's a hybrid firmware, that means that you can boot both with u