ghost82

Check: BIOS >> Advanced >> NB Configuration >> IOMMU --> is enabled, not auto, not disabled

I wasn't expecting the boot repair, anyway it can happen, basically is like you physically disconnected the hd from a scsi controller and connected it to a sata one. If I were you I would make a backup copy of the vdisk and run the boot repair. If nothing improves or if the disk will get corrupted you can revert the changes in the xml with the original disk.

From what I can see there's no irq conflict. Can you try changing the virtual virtio controller to a sata one for the disks and check if things are better? Change from this: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vm/win10/vdisk1.img' index='3'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-WDC_WD20EZRX-00DC0B0_WD-WCC1T0211008' index='2'/> <backingStore/> <target dev='hdd' bus='virtio'/> <alias name='virtio-disk3'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> To this: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vm/win10/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-WDC_WD20EZRX-00DC0B0_WD-WCC1T0211008'/> <backingStore/> <target dev='hdd' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk>

I would try to enable allow unsafe interrupts in unraid settings (reboot after change). If this doesn't work I would try kernel parameter pci=noaer (reboot after change). Do not make any manual changes, you should pass only 05:00.0 and .1, do not passthrough pci bridges, set 05:00.0 and .1 in a multifunction device.

Since the gpu is quite old, and I imagine the drivers too, they may expect the sound to be on the same bus/slot but different function (which it is in the real hardware, but not in the vm), so I would give a try by modifying the vm xml from this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0c' 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='0x0c' 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='0x0c' 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='0x0c' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </hostdev>

Yes, I added a note to my post above as I saw later that that gpu could be without uefi in bios and as you know mac os doesn't work without uefi gpu (at least versions of latest years). Yes, the actual version of macinabox doesn't include virt-manager. Take into account that you can avoid this, you can have a separate disk with the EFI files (opencore.qcow2, opencore.img or whatever you want) and let the original apple EFI files on the disk; you will boot from the separate disk which will find and boot mac os disk; by this way you can easily replace the EFI disk without having access to the mac os disk. Anyway both ways work. It's similar, but not the same; when you build a virtual machine with machinabox all the hardware is emulated, even the cpu, so the basic setup should work for all without any change. Thing change when you passthrough hardware (like gpu, ethernet, usb, etc.), when you customize things changes to the opencore config could be mandatory to make all the things work together. In real you used vfio; when you passthrough hardware to a vm, in this case the gpu, you are attaching it to the vfio driver. And this is the important thing!!!

Open the vm in the xml mode and check at the bottom if there is something related to that usb device; if it's there manually delete the offending block of code.

If the vm is properly configured, without anything else running in the host (or nearly nothing running on the host) you could take into account that the vm will perform bare metal -5 - -10%; so if you assign let's say 4 cores/4 threads to the vm, it will perform like a real 4 cores/4 threads minus 5-10% in performance; this is a rough estimation. this is only a matter of money, but make sure the cpu(s) supports vt-d and vt-x, so you will be able to passthrough hardware (descrete gpu?) through vfio to the vm. About the gpu, to give you an example, I have the latest 6900xt which gives a score of about 140.000 in Geekbench (it's mac os); online results with the same gpu are higher too (about 180.000), but this may depend on cpu bottleneck as I have 2 old sandy bridge xeon cpus. I would say that also the gpu will perform near bare metal performance, vfio is good; make sure to use q35 machine type for the vm so it will be more compatible with pcie passthrough.

I remember garage band was preinstalled on mac os leopard in my old old old mackbook pro, cannot you use an older version or is it a no go?

Yes, it should work, but it's more complicated to make it work, first because usually the igpu is the primary gpu used by the host and isolate it to make it available for the vm can be a mess (because of iommu groups, because of the motherboard bios, because of the os system...), second you should setup opencore for your igpu and this may include framebuffer patching. You could follow dortania's guide and hackintosh forums; unfortunately I cannot help too much for igpu, never passed through to any vm.

It is always recommended to dump your own bios file: the 70 kb file could be good, I would check it with an hex editor and see what it's inside. If the dumped file is crap, you should search and solve why you are not able to dump the vbios: this is recommended, because if the gpu is in use by the host you wont be able to use it even with a proper vbios. It works the same way as a bare metal hackintosh, you need lilu/whatevergreen kexts and all the workarounds (if any) needed for bare metal hackintosh. The only thing that changes compared to bare metal is that you need also to set the topology of the vm: make sure to pass both video and audio of the gpu, set them as a multifunction device (same bus, same slot, different function) and do not use bus 0. It is recommended to attach them to vfio; not sure what you are asking: you need to passthrough both devices (audio and video, so 2 checkmarks), if they are alone in the same iommu group it's ok, if they are together with some other device use acs patch to split them. On top of this make sure the vbios of the gpu is uefi, otherwise nothing will work.

I would check if there is some irq conflict with the msi utility, in particular check for shared irq with the virtual sata controller: https://forums.unraid.net/topic/76035-help-struggling-with-nvidia-audio-passthrough/#comment-1076592 This may change irq arrangement, alternatively try to restore the older version

Monterey has no drivers for 1070, so there's no way to get acceleration or any video output from that gpu; stick to high sierra (with installed nvidia drivers), change gpu with a compatible one, or do not use gpu passthrough.

Monitor is attached to the gtx, but the gpu is bound to vfio, so it's perfectly normal that at some time during unraid boot and after some video output the screen will look like it's frozen. The gpu is isolated and the os cannot use it for its video output anymore, because you set it to be reserved for something else (vm for example). Connect to unraid from another device and you will find that it's booting and it's not crashing.

Type this in unraid terminal: virsh undefine --nvram "Macinabox BigSur"

Ciao, credo che unassigned devices possa esserti di aiuto (sempre che tu non voglia assegnarli all'array, ma non credo proprio..). Lo scarichi da community applications. Qui la discussione specifica:

And this? https://askubuntu.com/questions/6769/hibernate-and-resume-from-a-swap-file First reply may contain some useful info.

data should be in the larger partition, nbd0p8, try to mount it somewhere.

it's -l not -1

is something using the qcow2 file?is the vm completely shutdown? If so, try to remove the "dirty bit".

the recovery needs to download more or less 12 gb, unless you have a fast connection it sounds like you have a corrupted installer and that's probably why it reboots to the bootscreen. I would start from scratch again.

You are the only one that knows what your hard drives contain, so make a copy of what you need. Or if the quesrion is if you can clone several drives into one image, as far as I know...no. As far as the vm, to run it only needs the os partion image(s) (and the efi partition (if efi)). Usually you clone the whole drive containing all the os partitions. If I were you I would attach the os hard drive in the server and pass it to the vm directly, or if you want an image file for the disk, I would attach the os hard drive in the server and use linux dd command to clone it as a raw image; or another alternative is to boot your old pc from a linux live usb pedrive/cd/dvd and use dd command to clone the hd as a raw image and then transfer it somewhere in the server. Take into account that you need space to save image(s), on a disk different than that you are cloning, at least a free space equal to the whole disk capacity you will clone. I would avoid any virtio device and use legacy ones when you create the vm.

You can use qemu-nbd command line. First backup your qcow2 file. Then in a terminal: Load kernel module: modprobe nbd max_part=8 Create nbd0 block device: qemu-nbd --connect=/dev/nbd0 /replace/with/path/to/file.qcow2 Use fdisk to list partitions and see if you get any output: fdisk -l /dev/nbd0 Yiu can also use fsck to try to repair partitions: fsck /dev/nbd0p1 nbd0p1 being partition 1. You can also mount the partition (in this example nbd0p1) somewhere: mount /dev/nbd0p1 /mnt/somepoint/ Once done, disconnect: qemu-nbd --disconnect /dev/nbd0

sounds like you have a firewall installed into the vm which prevents other hosts on the same lan to access that port; check iptables or any other firewall rules. Or you may have a firewall in the router.

follow the tutorial, your installation is not completed. mac os base system is the recovery (first boot), you need to select mac os installer to complete the installation, or better, let the bootpicker timeout without selecting anything and it will automatically select and boot the proper partition to complete the installation, all is managed by nvram entries.