ghost82

Attach new diagnostics Note that if you changed the machine version from the gui all your custom mod to the xml were lost. You should edit it in xml advance view.

Which version of unraid? For 6.9.2 and below: probably your alias is sata0-0-2, unraid gui masks it, I don't know why, so add this before </domain> <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.sata0-0-2.rotation_rate=1'/> </qemu:commandline> and make sure you have discard='unmap' in your disk block. Check if the disk is recognized as ssd: Boot mac os, go to About this mac --> System report... -> Sata Select the controller and you will see "support type" and "TRIM support": Support type should be solid state drive. If trim support is "No", run a terminal in mac os and type sudo trimforce enable ------------------------------- If you have unraid 6.10.0 RC1 and up, replace this: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/mnt/user/domains/macOS/macOS_disk.img'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> with this: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/mnt/user/domains/macOS/macOS_disk.img'/> <target dev='hdc' bus='sata' rotation_rate='1'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> Check if the disk is recognized as ssd: Boot mac os, go to About this mac --> System report... -> Sata Select the controller and you will see "support type" and "TRIM support": Support type should be solid state drive. If trim support is "No", run a terminal in mac os and type sudo trimforce enable In both cases, if you have issues attach diagnostics.

You have no video acceleration, so this is expected and not limited to monterey. --- If you run: qemu-img info /path/to/vdisk.img in a unraid terminal and in the output you see "virtual size" = "disk size", it means that the vdisk didn't shrink when you deleted files in the vm and when free space on vdisk increases (when you delete some files in the vm) it doesn't sync with the free disk space on the host; this means that one day in the future the host will see the real disk full. You can sync the free space between the vm and host in different ways, the fastest and preferred is to use trim inside the vm and setup the vdisk as non rotational. Note that if you use virtio controller to attach the vdisk this will probably not work (at least it didn't work last time I tried, now I'm passing through the sata controller directly); it works with emulated sata controller. a. For unraid < 6.10RC1 (6.10RC1 excluded): a1. check your vdisk settings in the xml, for example: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> and change the second line to: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> add this after <qemu:commandline> <qemu:arg value='-set'/> <qemu:arg value='device.sata0-0-3.rotation_rate=1'/> sata0-0-3 being the alias of the disk. b. For unraid >=6.10RC1 (6.10RC1 included): b1. check your vdisk settings in the xml, for example: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> and change to: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none' io='native' discard='unmap'/> <source file='/path/to/vdisk.img'/> <backingStore/> <target dev='hdd' bus='sata' rotation_rate='1'/> <alias name='sata0-0-3'/> <address type='drive' controller='0' bus='0' target='0' unit='3'/> </disk> c. in the mac os vm enable trim: run a terminal, type: sudo trimforce enable and follow instructions. Mac os will reboot, the vm will see the vdisk as an ssd, trim will be enabled and free space will be synched. --- That is not opencore, but opencore configurator. About the update of opencore I wrote something here: https://github.com/SpaceinvaderOne/Macinabox/pull/47#issuecomment-869157952

This is paid support. https://unraid.net/services

Bluetooth stack in monterey has undergone significant changes. This means that lots of cards do not work at all or do not work as intended. Best option is to have a monterey compatible original mac card to be installed into a pcie adapter. Supported chipsets for monterey should be: BCM943602 BCM94360 BCM94352 BCM94350

Opencore supports monterey fully, I'm running it with the latest monterey 12.3. That is THE question... You can look for commits at the official github acidanthera page: https://github.com/acidanthera/OpenCorePkg/commits/master and look for descriptions pointing to fixes for newer oses. If it doesn't boot you could enable logging to file in bootloader and see where/why it doesn't boot. Note that I have to say that for our qemu vms it's quite difficult that a "not so old" opencore will totally break the vm, unless you mess it with custom configurations or wrong settings. In most cases, if it boots big sur it will boot monterey. If the bootloader isn't able to boot a newer os because something in the os has changed and a fix is made to the bootloader to make it boot, you need to update the bootloader, you can compile it yourself, or you can wait for someone else to compile it and download the compiled files, or you can wait for someone else to compile it, to make a new vdisk with the newer files and download that vdisk and replace/boot with the new opencore. Abilities to do this range from low/medium to high, again if you are not expert, just take precautions (backups) and then ask for help if something goes wrong.

Simple answer is that you can update mac os from within mac os, and this will be successful if the bootloader is compatible with the new mac os version. Sounds weird, but it is what it is... So, if you don't know what you are doing, I would backup the vm you are going to update, mac os vdisk, bootloader vdisk (if any), vm xml, and then try the update. Then you will have 2 cases: 1. it boots without issues --> you are happy 2. it doesn't boot --> you are not happy: 3a. --> you restore the backup --> it boots --> you are not so happy because it didn't update, but at least it boots 3b. --> you fix it yourself or ask for help to make it to boot

Do not use machine type q35 v.6.2, mac os doesn't like its acpi tables (and 6.1 too); use max v.6.0, original macinabox uses v.4.2.

In RC3 add this: <qemu:capabilities> <qemu:del capability='device.json'/> </qemu:capabilities> right after the </qemu:commandline> closing tag. Please read also this, as this should be a temporary workaround: https://forums.unraid.net/bug-reports/prereleases/rc3-vm-alias-handler-change-r1768/?do=findComment&comment=18036

You have issue with the nvme drive (cache). It seems hardware related, I would try to unplug and replug it.

I would try to switch from i440fx to q35. You can create a new q35-5.1 vm (ovmf) pointing to actual vdisk, so no need to reinstall windows.

Yes, confirmed, and already addressed in vm faq thread: https://forums.unraid.net/topic/51703-vm-faq/?do=findComment&comment=1034668 Also here: https://forums.unraid.net/topic/120232-atheros-ar9280-wireless-card-bar-error/?do=findComment&comment=1107467 I think a newer version of libvirt will make our custom qemu args to work again in some way. At the time of writing the -set argument doesn't work with json format, so while some -set commands can be translated in libvirt (like rotation_rate), others have no way to be translated (like x-msix-relocation)

It sounds like a voltage issue to the pcie slot, so I would say...hardware related. That card should need 3.3V, I think that sometimes it drops, leaving the device in the unknown header type 7f. You could try to look into your bios settings, I doubt you will find any voltage values to tweak for pcie, but maybe some settings like 'maximum performance', or something like that. Make also sure your power supplier has enough watts to run the build.

Can you try as a test to lower the amount of ram, let's say to 8 Gb and see if it's faster?

Hi, I already downloaded it, but there is no trace of of passed through 05:00.0. Please pass it through to a vm with the custom qemu arg, run it with the error and then reattach diagnostics.

Thank you @kilroyffor confirming. Since your case can be easily solved by the above solution, I was more interested in the diagnostics from @Arbadacarba

In addition add boot order=1 inside your nvme block, for example: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x19' slot='0x00' function='0x0'/> </source> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> Note that this is valid only if your nvme controller is at 19:00.0, otherwise, edit the correct block. I think that sata has boot priority over a vfio nvme drive. If it still doesn't work press esc when the vm boots to enter ovmf bios setup and change boot order there.

This needs to be updated for unraid 6.10.0 RC1 and up, see here: https://forums.unraid.net/topic/51703-vm-faq/?do=findComment&comment=1034668

Since this is an 'issue' specific with libvirt json format, running directly qemu from command line should work. If you attach diagnostics to see the command we can try to translate it for qemu and see if that works.

Looking at the qemu bugtracker, it seems confirmed there too; the alias is there, it's not stripped, the issue is with the -set and json format. https://gitlab.com/qemu-project/qemu/-/issues/787 Also here: https://gitlab.com/libvirt/libvirt/-/issues/287 There is a patch too, but it hasn't been merged. Not sure, how to eventually modify qemu.conf to add capability_filters; the only option could be to extract the unraid bzroot file, "patch" it, and recompress it, to have a persistent solution after a reboot. Moreover it's not clear if this is working or not. ...and: For rotation_rate I think you can actually add it to the libvirt xml without using the custom qemu arg (from libvirt 7.3.0, 6.10 RC3 should have >=7.8.0), something like this, in the target line of the disk section: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='path/to/vdisk.img'/> <target dev='hdc' bus='sata' rotation_rate='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> For x-msix-relocation the only option should be that described in the next post

Can you please check in your diagnostics file, after setting a vm with aliases in unraid (don't bother if they are stripped or not) and run it then stop it: 1. Extract diagnostics zip and go to qemu/VMName.txt 2. Open VMName.txt and check if the aliases are there: for example for 'sata0-0-1' alias, you should have this in the device line: id=sata0-0-1 Libvirt aliases translate to ids in qemu. If they are not there too, as a temporary workaround you could run the vm directly from the command line, adding all the ids you need, calling directly the qemu binary.

I asked because there is no error in the log you attached. Try to attach diagnostics, after trying to run the problematic vm.

Ok, open a bug in the appropriate forum section.

Not your fault for sure, even with a translator I'm missing the meaning, even if explained ahah, but all I need to know it's that it was sarcasm Did you try with the virsh edit command? It can be a bug in the gui stripping the aliases.

It's better to reserve some cpu power for unraid, core 0 at least, or core 0 + its hyperthreaded core. However I run for several months some vms with all the core assigned, and even at 100% power in vm without issues, now it runs with some dedicated cores. This really depends on what the host is doing when you have the vm running. You should try directly and see what fits your purposes, worst thing can happen is that unraid locks.