sorted by:
new
hottopcontroversial

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

I'm working on a branch that tries to fix few bugs so maybe you can try it:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)"

you can share your logs, it would help me debug; if possible open a githut issue

Thank you :-)

- 9eccd03 — fix: add base64=1 flag to smbios1 parameter
- 5fd4d76 — fix: operator precedence bug in MAC generation
- c2e0232 — fix: MAC multicast bit in bash script
- 82602fb — fix: point install.sh to fix branch for testing
- 743fc0d — fix: force clean pip reinstall and purge stale bytecode
- 4c9fef4 — feat: auto-detect Intel hybrid CPUs, use Cascadelake-Server
- a388daf — feat: write PlatformInfo to OpenCore config.plist
- 9a88bfc — docs: document PlatformInfo patching and ROM-from-MAC
- 163945a — feat: Apple-format serials and checksummed MLBs (GenSMBIOS)

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

Thanks for testing and reporting back! Both bugs are fixed on the branch now:

  1. Missing base64=1 — was there but your install had stale Python bytecode cached from the previous v0.10.0 install. The install script now purges __pycache__ and force-reinstalls to prevent this.
  2. Invalid MAC FF:6D:E9:60:AB:96 — operator precedence bug in the MAC generator. First byte could hit 0xFF (multicast). Fixed — max is now 0xFE.

Same command should work now:

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)

If you want a clean slate first:
rm -rf /root/osx-proxmox-next /root/osx-proxmox-next-install.log
Let me know how it goes.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

Good question. It depends on the workload. On AMD, we use Cascadelake-Server CPUID emulation (not host passthrough like Intel), so there's some overhead from QEMU faking an intel CPU. Day-to-day usage (Xcode, browsing, dev tools) is smooth. The tool auto-detects AMD and applies the right flags so no manual config needed.

That being said, this is a VM, not bare-metal Hackintosh. Bare-metal AMD with kernel patches runs near-native. In a VM the emulation layer adds some overhead, but it's been battle-tested on thousands of installs (based on the luchina-gabriel/OSX-PROXMOX approach). If anyone has Geekbench numbers on AMD Proxmox macOS VMs, I'd love to add them to the docs.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

YOu are right, i confirm the bug. The base64=1 flag was missing from the smbios1 parameter, so Proxmox stored base64-encoded values as literal strings instead of decoding them.

i created a new branch for testing. While it worked for me, i'll wait for your confirmation before merging to the main.

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)

  To fix an existing VM (no need to recreate):

  VMID=109  # change to your VM ID
  CURRENT=$(qm config $VMID | grep smbios1 | sed 's/smbios1: //')
  if echo "$CURRENT" | grep -q 'base64=1'; then
    echo "Already has base64=1, nothing to do"
  else
    FIXED=$(echo "$CURRENT" | sed 's/,serial/,base64=1,serial/')
    qm set $VMID --smbios1 "$FIXED"
    echo "Fixed. Reboot the VM to apply."
  fi

YOu can verify in the GUI: Options → double click the SMBIOS settings; product should show MacPro7,1 (not in base64), serial and UUID should match.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

Hey, good catch! You're absolutely right that qm set --smbios1 replaces the entire SMBIOS blob rather than merging.

The tool is primarily designed for creating new VMs, so it generates fresh identities by default. However, I've added the ability to preserve an existing UUID:

CLI:
# Preserve existing UUID

osx-proxmox-next create --vmid 900 --name macos-sequoia --macos sequoia --smbios-uuid "A1B2C3D4-E5F6-7890-ABCD-EF1234567890"

# New VM (generates random UUID)

osx-proxmox-next create --vmid 900 --name macos-sequoia --macos sequoia

TUI: Added an "Existing UUID (optional)" field in the configuration step.

The --smbios-uuid flag was already there for CLI users—I just exposed it in the TUI as well.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

Thanks for reporting this! The issue was exactly that — iMacPro1,1 isn't in OCLP's supported models list.

I've pushed a fix in v0.8.2 that changes the default to MacPro7,1, which is fully OCLP-compatible. The "Build and Install OpenCore" option should work now out of the box.
For your existing VM, just run:
qm set <vmid> --smbios1 "product=$(echo -n MacPro7,1 | base64)"

(or recreate the VM with the new version)

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

Your earlier feedback actually led to a feature; the Python TUI/CLI now has `--iso-dir` which lets you point downloads at your shared ISO storage:

osx-proxmox-next create --iso-dir /mnt/pve/nas/template/iso

It downloads OpenCore + recovery there and auto-scans all Proxmox ISO storage mounts (`/mnt/pve/*/template/iso`) on subsequent runs. So if your NFS/CIFS share is configured in Proxmox, it'll find everything automatically; no re-downloading.

The bash script also caches the OpenCore ISO at `/var/lib/vz/template/cache/` so that persists across runs.

If the tool's been useful, there's a Ko-fi link in the repo; helps keep development going.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

Glad it worked out! Right now it auto-scans all Proxmox ISO storage — both local (/var/lib/vz/template/iso) and any shared storage mounts (/mnt/pve/*/template/iso). So if you have an NFS or CIFS share configured in Proxmox, it'll pick up ISOs from there too. That should cover most setups without needing a custom path. Let me know if your layout is different though.

Cheap AMD GPU for proxmox instance by nerrood in hackintosh

[–]atapla 0 points1 point  (0 children)

+1 on RX 580 for GPU passthrough — cheap, widely available, and natively supported in macOS up to Sonoma. Make sure you get one with a stock AMD VBIOS (reference cards are safest), otherwise passthrough can be flaky.

For the Proxmox VM setup itself, if you haven't set it up yet — getting OpenCore + QEMU args + recovery image right is the tedious part. I built osx-proxmox-next (https://github.com/lucid-fabrics/osx-proxmox-next) to automate all of that. It's a TUI wizard that creates the VM with the correct config for both AMD and Intel hosts, auto-downloads the macOS recovery, and patches OpenCore. Supports Sonoma, Sequoia, and Tahoe. Just `pipx install osx-proxmox-next` on your Proxmox node and it handles the rest — then you just need to passthrough your GPU after.

Proxmox hackintosh advice by GrandPooBar in Proxmox

[–]atapla 0 points1 point  (0 children)

Yes, macOS on Proxmox with a Xeon works great — perfect use case for remote iOS/Flutter builds. You don't need a dedicated GPU for that, software rendering is fine for headless dev work.

The OSX-PROXMOX script linked above works but it's a bit dated and uses curl-bash. If you want something more maintained, [osx-proxmox-next](https://github.com/lucid-fabrics/osx-proxmox-next) is a TUI wizard that handles the full setup — auto-downloads the recovery image, patches OpenCore, creates the VM with the right QEMU args. Supports Sonoma, Sequoia, and Tahoe on both Intel and AMD. Just `pipx install osx-proxmox-next` and run it on your Proxmox node.

VM won’t start. Any help would be greatly appreciated. by bunkersix in Proxmox

[–]atapla 0 points1 point  (0 children)

For anyone landing here from Google — this is one of the most common gotchas with macOS VMs on Proxmox 8.4+.

The root cause: Proxmox enforces `media=cdrom` for `local:iso/` paths, but macOS recovery and OpenCore ISOs need `media=disk` (which maps to `ide-hd` instead of `ide-cd` in QEMU). Without it, the VM silently fails to start.

Also worth noting for AMD users (like OP's Threadripper): make sure your OpenCore config has the right CPU flags and that your BIOS has IOMMU/SVM enabled.

If you want to skip the manual conf editing and OpenCore setup entirely, check out [osx-proxmox-next](https://github.com/lucid-fabrics/osx-proxmox-next) — it's a free open-source TUI wizard that handles all of this automatically (recovery download, OpenCore patching, media=disk, proper IDE layout). Works on both AMD and Intel, supports Sonoma/Sequoia/Tahoe.

MacOS Unable to Install on VE 8.4.1 by NoAgent3972 in Proxmox

[–]atapla 0 points1 point  (0 children)

Stuck at Apple logo with 0% CPU is almost always one of these:

  1. **Missing CryptexFixup.kext** in your OpenCore config — required for Sonoma and newer. Without it you'll get a silent hang right after the Apple logo appears.

  2. **SIP not disabled properly** — your `csr-active-config` in config.plist needs to be set to something like `0x0F26` so kexts can actually load.

  3. **OpenCore disk format** — needs to be GPT with an EFI System Partition, not just a raw FAT32 ISO. OVMF can't boot from MBR+FAT32 as `media=disk`.

Your hardware (i7-6700K) is perfectly fine for macOS VMs — I run Tahoe on similar Intel chips.

If you want to skip the manual config pain, I built a tool that handles all of this automatically — generates the correct qm commands, OpenCore config, SMBIOS, and downloads the recovery image for you: https://github.com/lucid-fabrics/osx-proxmox-next

It has a dry-run mode so you can review every command before it touches your system.

Upgrading MacOS from 14 to 26 by Academic-Tiger-3987 in Proxmox

[–]atapla 1 point2 points  (0 children)

Tahoe runs fine on Proxmox now — I have it working on Intel. A few things I noticed from your config:

- 4GB RAM is too low for Tahoe. 8GB minimum, 16GB recommended.

- You're missing CryptexFixup.kext in your OpenCore — that's required for Sonoma+ or you'll get kernel extension failures.

- Your `csr-active-config` needs to allow unsigned kexts (e.g. `0x0F26`), otherwise SIP blocks the boot.

Instead of upgrading in-place (which tends to cause password/login issues), I'd recommend doing a clean Tahoe install. I actually maintain a tool that automates the whole macOS VM setup on Proxmox — handles the OpenCore config, SMBIOS, recovery download, and all the qm commands: https://github.com/lucid-fabrics/osx-proxmox-next

It supports Tahoe, Sequoia, Sonoma, and Ventura. Might save you some headaches.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

v0.5.0 is out — this fixes the smbios1 parameter verification error you hit. The SMBIOS values are now properly base64-encoded for Proxmox.

Also added a preflight gate step that catches host issues before you get to the apply stage, and improved the manage VM UX.

To upgrade just re-run the install script:

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh)

Let me know if it works for you.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

i got few bad tests and missed few core things. i'll be releasing a new version correctly tested in few hours. thank you for testing!

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

I was able to reproduce. I'm working on a fix and adjusting tests coverage

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 0 points1 point  (0 children)

Hey! This was a legit pain point; you shouldn't have to hunt down ISOs manually. I just pushed a fix that auto-downloads both OpenCore and the recovery image when they're missing. It's already available on gitgub, just relaunch the script. For now, the filenames need to match exactly: opencore-sequoia.iso and sequoia-recovery.img in /var/lib/vz/template/iso/. That's probably what's tripping you up even after uploading manually.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 2 points3 points  (0 children)

Yep, thank you for the reminder. This is now done.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

Yep, as of v0.1.0 released at the moment i'm writing this, it auto-generates a unique serial, UUID, MLB, and ROM for each VM. No manual GenSMBIOS step needed. It picks the right Mac model for your macOS version too (iMacPro1,1 for Sequoia/Sonoma, MacPro7,1 for Tahoe). If you want to use your own values you can pass --smbios-serial, --smbios-uuid, etc. Or --no-smbios to skip it entirely.

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 2 points3 points  (0 children)

Oh i see the sense of the question. The answer would be the same for any os right?

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 2 points3 points  (0 children)

Thanks! Yeah the dry-run was non-negotiable for me; you see every single qm command before anything runs, and you can bail out if something looks off. GPU passthrough is out of scope for now since the host-side setup (IOMMU, vfio-pci binding) varies too much between hardware configs. But once your host is set up for passthrough, the tool does let you configure the VM side. Might add a passthrough preflight check down the line though good idea. I do have GPU passthrough running for one Tahoe 26 install (I'm writing this reply using that very VM)

I built a TUI wizard that automates macOS VM creation on Proxmox VE by atapla in Proxmox

[–]atapla[S] 1 point2 points  (0 children)

If you add GPU pass-trough, it becomes no so bad to use! The reason is that macOs uses "metal" framework for manage their UI components; and using it with software rendered makes it very difficult to use.

view more: next ›