On 11/29/2023 at 6:58 PM, ibbanez said:

I have a question. I tried searching, but maybe I'm using the wrong keywords. What additional steps do I need to do to build different VM's? Like I have a Big Sur one running, but I want to try Monterey. Also, Can you simply update the VM like normal to get OS updates to newer versions? 

From My experience, you just have to delete macinabox docker app data folder, and rename template script for vm, so when you run new monterey docker it won't overwrite your Big Sur script (but you have to rename it through terminal, not web gui), and in case of updates, I was able to update Big Sur, monterey and Sonoma normally, I just updated opencore, components and it worked every time.

Question, once I have a working BigSur VM, what happens if I upgrade to a newer version of macOS from within the VM? Will everything break?

I have successfully installed BigSur several times on more than one UnRaid instance.  I have edited the VM instance so that only the BigSur, recovery, and EFI show on the opencore boot screen. 
 

How do I get it to automatically boot BigSur after a timeout?

 

Next question is how do you completely remove a VM?  I tried to install Monterey but had issues.  I have deleted domains, appdata for Monterey, but still it shows up in the list of VMs.  Selecting remove with files, just spins.  What places do I  have to touch to get rid of it?

 

Thanks for the help.

 

 

Dennis

Edited December 11, 20232 yr by DWomack
Spelling

On 12/10/2023 at 7:34 PM, mackid1993 said:

Question, once I have a working BigSur VM, what happens if I upgrade to a newer version of macOS from within the VM? Will everything break?

I think so

On 12/11/2023 at 3:28 PM, DWomack said:

I have successfully installed BigSur several times on more than one UnRaid instance.  I have edited the VM instance so that only the BigSur, recovery, and EFI show on the opencore boot screen. 
 

How do I get it to automatically boot BigSur after a timeout?

 

Next question is how do you completely remove a VM?  I tried to install Monterey but had issues.  I have deleted domains, appdata for Monterey, but still it shows up in the list of VMs.  Selecting remove with files, just spins.  What places do I  have to touch to get rid of it?

 

Thanks for the help.

 

 

Dennis

If it just spins, you have to edit xml manually and remove Nvram line completely, now it should be removable, but if You want the manual way, You can remove files manually (assuming that all your oaths are default)

from:

/etc/libvirt/qemu

/mnt/user/domains

/mnt/user/isos

and macinabox files from

/mnt/user/appdata

i think that are all locations, but someone correct me if I am wrong

 

On 11/29/2023 at 6:58 PM, ibbanez said:

I have a question. I tried searching, but maybe I'm using the wrong keywords. What additional steps do I need to do to build different VM's? Like I have a Big Sur one running, but I want to try Monterey. Also, Can you simply update the VM like normal to get OS updates to newer versions? 

You have to delete appdata folder of macinabox and remove container, also you have to change macinabox_helper script name (manually from commandline, Because when you change it in the ui, physical names remain intact) so it won’t be overwritten when you will run new docker image. Lastly you just run new macinabox container with new settings for different macOS

Ok so everything went smooth as butter following the older spaceinvader video

 

the only weird part was when I downloaded OpenCore configurator it said this is an older efi, i just ignore this and continued following along. The next "weird" thing was that the EFI partition didn't include the NvVars file, just the EFI folder. Again, ignore and copied it to the correct partition.

After this, I shutdown and followed some of his edits to the VM helper script (adding name, etc). I tried adding some CPU's and updating RAM and I've never been able to boot again.

 

I get this error in the log at the moment:

2024-01-13T22:46:40.073081Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.073111Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
2024-01-13T22:46:40.074095Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.074103Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
2024-01-13T22:46:40.074948Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.074955Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
2024-01-13T22:46:40.075725Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
2024-01-13T22:46:40.075732Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.fma4 [bit 16]
qxl_send_events: spice-server bug: guest stopped, ignoring

 

I tried changing the topology setting in the helper script and changing the custom to "unraid" neither of those changes made any difference. So I also tried putting my CPU's and memory back to where they started thinking it was related to that and it seemed to still have an issue. Any ideas what I can try or do I have to start over all together?

10 hours ago, austin said:

2024-01-13T22:46:40.073081Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]

These are warnings and that features are simply ignored because your native cpu doesn't support them.

 

10 hours ago, austin said:

The next "weird" thing was that the EFI partition didn't include the NvVars file

You don't need that file, that is for emulated nvram, and you will not emulate it.

 

10 hours ago, austin said:

OpenCore configurator it said this is an older efi, i just ignore this and continued following along.

This is the issue, if you use the configurator with an older or newer version of opencore it will mess your configuration file.

What is not working is opencore because it's not configured properly/wrongly or because the image you are using is too old for the os you're trying to boot.

 

10 hours ago, austin said:

Again, ignore and copied it to the correct partition.

I suggest to not copy the efi folder to the macos disk, but let it stay alone in its own disk and configure the vm boot from it, so that the original efi in the macos disk will be simply ignored, otherwise if you mess things with the efi it will be more difficult to mount that partition.

Edited January 14, 20242 yr by ghost82

8 hours ago, ghost82 said:

I suggest to not copy the efi folder to the macos disk, but let it stay alone in its own disk and configure the vm boot from it, so that the original efi in the macos disk will be simply ignored, otherwise if you mess things with the efi it will be more difficult to mount that partition.

 

Thank you Ghost! Trying this now. One question, can I still use the OpenCore configurator to set my serial number? Does anyone know which version of OpenCore Configurator is compatible with this macinabox method?

23 hours ago, austin said:

 

Thank you Ghost! Trying this now. One question, can I still use the OpenCore configurator to set my serial number? Does anyone know which version of OpenCore Configurator is compatible with this macinabox method?

You can download Hackintool to check what version of OpenCore You have and then download suitable OpenCoreConfigurator, and I would advise You to use GenSMBIOS script to generate serial number instead of OCC.

So I successfully booted up and even got updated to the latest OpenCore! I was hodge poding a lot of docs but at the end of the day, it's working perfect. I have iMessage working (I cloned an actual serial number for an old broken laptop I have laying around) and everything is smooth!

 

I learned pretty quickly that people seem to hate on OpenCore Configurator, so I switched and used a number of different tools to get to the endpoint.

1. I used MountEFI.py at first https://github.com/corpnewt/MountEFI to mount my EFI

2. Then OCAT (OpenCoreAuxillaryTools) https://github.com/ic005k/OCAuxiliaryTools to upgrade my EFI to the latest opencore, there is a button to do this and it handles it all for you. You just need to mount the EFI, which I ended up having to do with OpenCoreConfigurator's mount option (I already had installed, but didnt end up using it besides for mounting) to mount the EFI that the unraid box was actually using. By default MountEFI.py was mounting the EFI of the boot drive and not the secondary disk from the unraid VM. 

3. After updating you'll have an exclamation point at the top center of OCAT, this runs OCValidate which checks your config.plst. I had to update only one configuration to fix, which I just googled. It required me to go to NVRAM in OCAT and delete one of the reocrds and replace with a new value.

4.I think I might've had to do something in ACPI by running https://github.com/acidanthera/MaciASL and changing some CPU pinning thing or something, I did so many random things that I probably have all of this wrong. BUT, it works! So I dont care.

On 1/15/2024 at 9:20 PM, austin said:

So I successfully booted up and even got updated to the latest OpenCore! I was hodge poding a lot of docs but at the end of the day, it's working perfect. I have iMessage working (I cloned an actual serial number for an old broken laptop I have laying around) and everything is smooth!

 

I learned pretty quickly that people seem to hate on OpenCore Configurator, so I switched and used a number of different tools to get to the endpoint.

1. I used MountEFI.py at first https://github.com/corpnewt/MountEFI to mount my EFI

2. Then OCAT (OpenCoreAuxillaryTools) https://github.com/ic005k/OCAuxiliaryTools to upgrade my EFI to the latest opencore, there is a button to do this and it handles it all for you. You just need to mount the EFI, which I ended up having to do with OpenCoreConfigurator's mount option (I already had installed, but didnt end up using it besides for mounting) to mount the EFI that the unraid box was actually using. By default MountEFI.py was mounting the EFI of the boot drive and not the secondary disk from the unraid VM. 

3. After updating you'll have an exclamation point at the top center of OCAT, this runs OCValidate which checks your config.plst. I had to update only one configuration to fix, which I just googled. It required me to go to NVRAM in OCAT and delete one of the reocrds and replace with a new value.

4.I think I might've had to do something in ACPI by running https://github.com/acidanthera/MaciASL and changing some CPU pinning thing or something, I did so many random things that I probably have all of this wrong. BUT, it works! So I dont care.

 

Have you seen EFI-Agent on GitHub?
 

So, what version of macOS do you have running?  I am at Big Sur. 

 

When I start the VM it runs thru a bunch of code, which are boot messages from OpenCore?

 

Then it is at an OpenCore picker screen and I pick Big Sur and it boots.

 

How do I get it to go straight to Big Sur?

 

I hope SpaceInvader One is progressing along to the new release of Macinabox.

 

 

Dennis

 

Edited January 17, 20242 yr by DWomack
Additional info

Well I was working and excited until I rebooted my entire unraid box and the entire VM disappeared. Is there an XML file somewhere that I can re-add it?

So I’m a bit of a unraid noob but been running bare metal and proxmox hackintosh’s for a while now so fairly confident editing plist files and opencore bootloader.

 

Having recently built a new unraid server to replace my creaking and old Synology NAS, I figured I may as well get MacOS running on it as it’s on all the time anyway and I wouldn’t need to flash up my gaming PC/Hackintosh every time I needed to do something.

 

Fast forward, I have unraid running great with loads of dockers etc, and following spaceinvaderone’s excellent tutorials, a fully working Big Sur vm with passed through WiFi card, USB PCI-E card and GPU (RX580)

 

As I’d been running Ventura on Proxmox for ages, I thought I’d tinker with the vm to see if I could get Ventura running. There seems to be no guide out there to show you how to do this and all the searching I did pointed at a couple of Docker options that were limited in functionality. I have skimmed through this thread so apologies if it's already covered! Anyway……a long while later - success

 

My setup is an intel server; Xeon E5 2697 v4 running on an ASUS X99-E WS motherboard with 128GB 2300 ECC memory. There is no reason why an AMD setup shouldn’t also work with a few tweaks. Here’s what I did:

 

1.    I used the ‘backup vm’ app from community applications to backup my BigSur vm

 

2.    I then stopped all PCI-E passthrough to the vm to mitigate any issues with passthrough breaking during the install. There is a bug in the current version of unraid where if you deselect GPU passthrough and go back to VNC, you will get the ‘guest has not initialised the display’ message and won’t be able to do anything. Luckily, I had a copy of the vm xml prior to passing through the GPU and just copied it back to the vm. I then tweaked the cpu cores and memory, reran the mackinabox helper script and that fixed the problem. There is a thread if you search for the no display error that tells you how to fix the xml but it was simpler for me to just copy back the original from the initial BigSur install.

 

3.    I then created a new user script and copied the script content from spaceinvaderone’s helper script. I then changed the custom xml entries that the script injects into the vm xml when run. I got the new values from Nick Sherlocks excellent tutorial on installing Ventura on proxmox: https://www.nicksherlock.com/2022/10/installing-macos-13-ventura-on-proxmox/ This is where you may be able to use the AMD values for CPU arguments if running an AMD CPU. Essentially, I changed my script to use the Intel CPU argument 

echo "<qemu:arg value='host,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor'/>" | tee --append /tmp/"$XML"4.xml

 

This replaced the old line:

echo "<qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,+rdrand,check'/>" | tee --append /tmp/"$XML"4.xml

 

This then passes the CPU through to the vm and doesn’t do any CPU emulation.

 

4.    I then used Opencore Configurator to mount the EFI partition and delete all the unnecessary kexts (as I’m using a Fenvi T919 WiFi/Bluetooth card that is natively supported in Ventura, I didn’t need all the bluetooth or wifi/broadcom kexts)

 

5.    I updated all the kexts to the latest versions, especially Lilu, Whatevergreen, AppleALC and VirtualSMC. Follow the guide at https://dortania.github.io/OpenCore-Install-Guide/

 

6.    Macinabox uses an old version of opencore (0.7.8) and the latest version is 0.9.7 so next it was time to update opencore and my EFI folder and files. 

 

7.    I downloaded the latest version of opencore from https://github.com/acidanthera/OpenCorePkg/releases

 

8.    I downloaded Propertree plist editor (https://github.com/corpnewt/ProperTree), used propertree to open the config.plsit from the BigSur EFI disk (mount the disk with opencore configurator as shown in spaceinvaderone’s install video). Then open the sample.plist in the Docs folder of the opencore download, place side by side

 

9.    I followed the opencore install guide (I used Intel HEDT/Broadwell-E under the configs sidebar) but follow whichever guide matches your CPU. The thing to bear in mind is I’m passing through the CPU to the vm as ‘host’, so the vm see’s my real CPU not as an emulated Intel ‘Penryn’ CPU in the current BigSur mackinabox vm. The motherboard is obviously emulated but I followed the guide for X99 (my actual motherboard) where motherboard parameters are used and it seemed to work. You may need to tweak slightly?

 

10. There is quite a bit of discrepancy between the Dortania guide and some of the settings in the mackinabox BigSur config.plist so I used the guide as the main reference, changing values where it told me to but where it was a bit ambiguous, I matched the settings from the mackinabox config.plist.

 

11. Once all the edits to the sample.plist was done, I renamed it config.plist and saved it to my desktop. I then followed the guide to build the EFI folder, finally adding the new config.plist once done.

 

12. I then replaced the BigSur EFI folder with the newly constructed EFI folder with the new config.plist and updated kexts and driver files.

 

13. I rebooted the vm to check it all worked and BigSur booted fine but now running on Opencore 0.9.7.

 

14. Next, I opened up a terminal window and used the command 

Quote

softwareupdate --fetch-full-installer --full-installer-version 13.6.4

 

This downloads the latest Ventura install app into your applications folder

 

15. I Then simply went to the downloaded file in applications, double clicked and followed the prompts to install Ventura over the top of Big Sur

 

16. To my complete surprise, it went through the full update with no errors and I was able to boot into Ventura 13.6.4

 

17. I renamed the vm from 'Mackinabox Big Sur' to 'Ventura'. If you use qcow2 in the macinabox docker configuration when creating the initial vm you’ll have a problem when renaming. There is a bug that messes up the disk setting in the xml when renaming a vm, changing it from qcow2 to raw. If you try and now boot, you go straight to a UEFI screen and your boot disk can’t be seen. You need to go into the xml and change the disk type back to qcow2 in the line that starts <driver name=

<devices>
    <emulator>/usr/local/sbin/qemu</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback'/>
      <source file='/mnt/user/domains/BigSur/macos_disk.img'/>
      <target dev='hdc' bus='sata'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>

 

18. I then came across another issue where when passing through the USB, WiFi and RX580 again, I just got a black screen. I checked my settings and they were the same as before so I was a bit stumped. I then compared the original BigSur xml with working passthrough, to the new Ventura xml and noticed that some of the lines had subtly changed for some reason. I replaced all the lines below the second <devices> </disk> entry from the BigSur xml in the Ventura xml. Voila! GPU passthrough now works.

 

19. Any changes from now on, as long as I used the updated helper script are fine and the vm performs fine.

 

20. I used GenSMBIOS (https://github.com/corpnewt/GenSMBIOS) to generate serials etc for an iMAC19,1 mac type and all iMessage services, handoff and Airdrop work fine. The Opencore guide tells you how to do this.

 

There’s an issue with the latest kernel that causes a crash when connecting the WiFi to an encrypted WiFi net (works fine with WiFi with no password) so I can’t connect the WiFi but I’m running hard wired so not an issue for me and all iServices seem to work fine.

 

I did a second update of another macinabox BigSur install to Sonoma and that also works following the guide above but Sonoma has dropped support for Broadcom cards and I had issues with Bluetooth that I couldn't seen to fix even with the OpenCore Legacy Patcher workaround so that was a non-starter for me and Ventura is fine for my needs

 

Hopefully this mini guide will help others to get Ventura (or Sonoma) up and running on unraid.

how to change vm name?when i rename everething has broken

1 hour ago, lomakor4 said:

how to change vm name?when i rename everething has broken

To rename, click edit on the vm and simply change the name. You’ll then need to follow the instructions at paragraph 17 above if the original vm was created with qcow2 disk type to get it working again

4 hours ago, iamtim2 said:

To rename, click edit on the vm and simply change the name. You’ll then need to follow the instructions at paragraph 17 above if the original vm was created with qcow2 disk type to get it working again

ty

when i change config plist in opencore i get error

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.9.6!

NVRAM->Add->7C436110-AB2A-4BBB-A880-FE41995C****->csr-active-config has illegal value!
CheckNvram returns 1 error!

Completed validating /Volumes/EFI/EFI/OC/config.plist in 2 ms. Found 1 issue requiring attention.

2 hours ago, lomakor4 said:

when i change config plist in opencore i get error

NOTE: This version of ocvalidate is only compatible with OpenCore version 0.9.6!

NVRAM->Add->7C436110-AB2A-4BBB-A880-FE41995C****->csr-active-config has illegal value!
CheckNvram returns 1 error!

Completed validating /Volumes/EFI/EFI/OC/config.plist in 2 ms. Found 1 issue requiring attention.

solved  need 0.7.7 opencore configurator        but changes dont apply after reset+config

Looking for an annotated user script that will remove all of what Macinabox has touched, so a new macinabox can be created.

 

A script would be much better than touch this, and this, delete this, etc.

 

Maybe the script could remove all VMs and the dockers necessary.

 

Sure I can stumble through all the steps, but a script that always works without mistakes would be much better.

 

Thanks to iamtim2 for posting his guide above.

On 2/4/2024 at 9:26 AM, iamtim2 said:

So I’m a bit of a unraid noob but been running bare metal and proxmox hackintosh’s for a while now so fairly confident editing plist files and opencore bootloader.

 

Having recently built a new unraid server to replace my creaking and old Synology NAS, I figured I may as well get MacOS running on it as it’s on all the time anyway and I wouldn’t need to flash up my gaming PC/Hackintosh every time I needed to do something.

 

Fast forward, I have unraid running great with loads of dockers etc, and following spaceinvaderone’s excellent tutorials, a fully working Big Sur vm with passed through WiFi card, USB PCI-E card and GPU (RX580)

 

As I’d been running Ventura on Proxmox for ages, I thought I’d tinker with the vm to see if I could get Ventura running. There seems to be no guide out there to show you how to do this and all the searching I did pointed at a couple of Docker options that were limited in functionality. I have skimmed through this thread so apologies if it's already covered! Anyway……a long while later - success

 

My setup is an intel server; Xeon E5 2697 v4 running on an ASUS X99-E WS motherboard with 128GB 2300 ECC memory. There is no reason why an AMD setup shouldn’t also work with a few tweaks. Here’s what I did:

 

1.    I used the ‘backup vm’ app from community applications to backup my BigSur vm

 

2.    I then stopped all PCI-E passthrough to the vm to mitigate any issues with passthrough breaking during the install. There is a bug in the current version of unraid where if you deselect GPU passthrough and go back to VNC, you will get the ‘guest has not initialised the display’ message and won’t be able to do anything. Luckily, I had a copy of the vm xml prior to passing through the GPU and just copied it back to the vm. I then tweaked the cpu cores and memory, reran the mackinabox helper script and that fixed the problem. There is a thread if you search for the no display error that tells you how to fix the xml but it was simpler for me to just copy back the original from the initial BigSur install.

 

3.    I then created a new user script and copied the script content from spaceinvaderone’s helper script. I then changed the custom xml entries that the script injects into the vm xml when run. I got the new values from Nick Sherlocks excellent tutorial on installing Ventura on proxmox: https://www.nicksherlock.com/2022/10/installing-macos-13-ventura-on-proxmox/ This is where you may be able to use the AMD values for CPU arguments if running an AMD CPU. Essentially, I changed my script to use the Intel CPU argument 

echo "<qemu:arg value='host,kvm=on,vendor=GenuineIntel,+invtsc,+hypervisor'/>" | tee --append /tmp/"$XML"4.xml

 

This replaced the old line:

echo "<qemu:arg value='Penryn,kvm=on,vendor=GenuineIntel,+kvm_pv_unhalt,+kvm_pv_eoi,+hypervisor,+invtsc,+pcid,+ssse3,+sse4.2,+popcnt,+avx,+avx2,+aes,+fma,+fma4,+bmi1,+bmi2,+xsave,+xsaveopt,+rdrand,check'/>" | tee --append /tmp/"$XML"4.xml

 

This then passes the CPU through to the vm and doesn’t do any CPU emulation.

 

4.    I then used Opencore Configurator to mount the EFI partition and delete all the unnecessary kexts (as I’m using a Fenvi T919 WiFi/Bluetooth card that is natively supported in Ventura, I didn’t need all the bluetooth or wifi/broadcom kexts)

 

5.    I updated all the kexts to the latest versions, especially Lilu, Whatevergreen, AppleALC and VirtualSMC. Follow the guide at https://dortania.github.io/OpenCore-Install-Guide/

 

6.    Macinabox uses an old version of opencore (0.7.8) and the latest version is 0.9.7 so next it was time to update opencore and my EFI folder and files. 

 

7.    I downloaded the latest version of opencore from https://github.com/acidanthera/OpenCorePkg/releases

 

8.    I downloaded Propertree plist editor (https://github.com/corpnewt/ProperTree), used propertree to open the config.plsit from the BigSur EFI disk (mount the disk with opencore configurator as shown in spaceinvaderone’s install video). Then open the sample.plist in the Docs folder of the opencore download, place side by side

 

9.    I followed the opencore install guide (I used Intel HEDT/Broadwell-E under the configs sidebar) but follow whichever guide matches your CPU. The thing to bear in mind is I’m passing through the CPU to the vm as ‘host’, so the vm see’s my real CPU not as an emulated Intel ‘Penryn’ CPU in the current BigSur mackinabox vm. The motherboard is obviously emulated but I followed the guide for X99 (my actual motherboard) where motherboard parameters are used and it seemed to work. You may need to tweak slightly?

 

10. There is quite a bit of discrepancy between the Dortania guide and some of the settings in the mackinabox BigSur config.plist so I used the guide as the main reference, changing values where it told me to but where it was a bit ambiguous, I matched the settings from the mackinabox config.plist.

 

11. Once all the edits to the sample.plist was done, I renamed it config.plist and saved it to my desktop. I then followed the guide to build the EFI folder, finally adding the new config.plist once done.

 

12. I then replaced the BigSur EFI folder with the newly constructed EFI folder with the new config.plist and updated kexts and driver files.

 

13. I rebooted the vm to check it all worked and BigSur booted fine but now running on Opencore 0.9.7.

 

14. Next, I opened up a terminal window and used the command 

 

This downloads the latest Ventura install app into your applications folder

 

15. I Then simply went to the downloaded file in applications, double clicked and followed the prompts to install Ventura over the top of Big Sur

 

16. To my complete surprise, it went through the full update with no errors and I was able to boot into Ventura 13.6.4

 

17. I renamed the vm from 'Mackinabox Big Sur' to 'Ventura'. If you use qcow2 in the macinabox docker configuration when creating the initial vm you’ll have a problem when renaming. There is a bug that messes up the disk setting in the xml when renaming a vm, changing it from qcow2 to raw. If you try and now boot, you go straight to a UEFI screen and your boot disk can’t be seen. You need to go into the xml and change the disk type back to qcow2 in the line that starts <driver name=

<devices>
    <emulator>/usr/local/sbin/qemu</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback'/>
      <source file='/mnt/user/domains/BigSur/macos_disk.img'/>
      <target dev='hdc' bus='sata'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>

 

18. I then came across another issue where when passing through the USB, WiFi and RX580 again, I just got a black screen. I checked my settings and they were the same as before so I was a bit stumped. I then compared the original BigSur xml with working passthrough, to the new Ventura xml and noticed that some of the lines had subtly changed for some reason. I replaced all the lines below the second <devices> </disk> entry from the BigSur xml in the Ventura xml. Voila! GPU passthrough now works.

 

19. Any changes from now on, as long as I used the updated helper script are fine and the vm performs fine.

 

20. I used GenSMBIOS (https://github.com/corpnewt/GenSMBIOS) to generate serials etc for an iMAC19,1 mac type and all iMessage services, handoff and Airdrop work fine. The Opencore guide tells you how to do this.

 

There’s an issue with the latest kernel that causes a crash when connecting the WiFi to an encrypted WiFi net (works fine with WiFi with no password) so I can’t connect the WiFi but I’m running hard wired so not an issue for me and all iServices seem to work fine.

 

I did a second update of another macinabox BigSur install to Sonoma and that also works following the guide above but Sonoma has dropped support for Broadcom cards and I had issues with Bluetooth that I couldn't seen to fix even with the OpenCore Legacy Patcher workaround so that was a non-starter for me and Ventura is fine for my needs

 

Hopefully this mini guide will help others to get Ventura (or Sonoma) up and running on unraid.

I was able to install Monterey using spaceinvaders video - but for some reason Ventura or Sonoma will not install. I show it downloading, preparing, the goes to the apple logo with progress but then it boots to boot menu with choice of Macintosh HD, Monterey, Recovery to choose from... I choose Monterey and check version and it's still Monterey

Although I have got Ventura working under Unraid, I wasn't very happy with the performance. The GUI was laggy, I was getting frequent micro pauses with the mouse cursor and UI elements such as scrolling windows and it just generally seemed a bit slow! I also had a couple of lock ups that took the whole server down with it.

 

I love Unraid for the NAS side and docker handling but I'm finding it a bit disappointing as a hypervisor for running VM's

 

A windows 11 VM wasn't that great either.

 

After a bit of investigation I tried a couple of things:

1.  I installed Ventura as a bare metal install and with 128GB RAM and 18 cores, it runs butter smooth, so not a hardware issue but BM is no good as I need the NAS functionality.

2.  I installed proxmox and then installed Ventura as a VM with the same RAM and core count as the VM running under Unraid. As with the Unraid VM, my RX580 is passed through and the VM disk is hosted on an NVME drive. Performance is night and day. Under proxmox, the VM runs very smooth, no glitches or slowdowns and no crashes despite identical settings and hardware passed through.

 

Conclusion, unraid running on my server does not do VM's very well! This is obviously an N of 1 and it might just be me 🙂 

 

I therefore took a different tack and probably off topic in this thread but I now have unraid hosted as a VM in proxmox with my disk controllers passed through along with an Nvidia Quadro p400 for Plex transcoding. As a NAS, it is working really well, and running a 10 disk pool (zfs) and 12 docker containers without a hitch for a week now.

 

Best of all, I'm able to run MacOS Ventura in a proxmox VM at the same time as Unraid with excellent performance. 

Thank you for the report.

To be sure :

Did you install Promox on unRAID, and install MacOS on Promox ?

 

5 minutes ago, PicPoc said:

Thank you for the report.

To be sure :

Did you install Promox on unRAID, and install MacOS on Promox ?

 

No, other way around. Proxmox as a bare metal install.

MacOS and Unraid are running alongside each other as VM's under Proxmox

Edited February 21, 20242 yr by iamtim2

OK, thanks.

Good idea.

But not for my usages. I need Parity and data disks specific on unRAID.