2月に私はosx-proxmox-nextに関する投稿を公開しました。このツールは、OpenCoreのplist編集に半日かかる代わりに、1コマンドでProxmox上にmacOS VMを構築します。

約1,500人がこれを読みました。その中には実際にインストールした人もいました。私が所有していないハードウェア上で。

そこで興味深いバグが明らかになりました。150回のコミット後、macOS on Proxmoxのガイドには一切出てこない5つの不具合と、それぞれの根本原因を紹介します。


1. インストーラーがCPU 100%で停止し、何も進まない

症状: macOSインストーラーがコピーフェーズに到達。CPUは100%に張り付き、ディスクI/Oとネットワークスループットは両方とも0。永遠にそこで止まる。

Xeon E5/E7 v2-v4ホストでのみ発生。

最初の修正は間違っていました。スタックがネットワークの問題のように見えたため、vmxnet3 kextがインストール中にロードに失敗していると仮定し、それらのホストをe1000-82545emに切り替えました。リリースしました。

すると実際のハードウェアを持つ人からissue #103が返ってきました: vmxnet3はネットワークが正常に動作し、e1000-82545emは全くアタッチされませんでした。私は状況を悪化させていました。

本当の原因は2層下にあります。これらのチップは本物のHEDTパーツで、デュアルソケット/マルチダイトポロジーを持ち、-cpu hostはそのトポロジーをゲストにそのまま漏らします。これをMacPro7,1 SMBIOSと組み合わせると、macOSはこれをマルチソケット対応と判断し、XNUのスケジューラーは重いマルチスレッドI/Oでライブロックします。インストーラーのコピーフェーズはまさにそのワークロードです。

修正はホストのトポロジーを渡さないようにすることです:

_XEON_HEDT_PATTERN = re.compile(r"Xeon.*E[57][ -]*\d+ *v([234])", re.IGNORECASE)

def _xeon_hedt_cpu_model(model_name: str) -> str:
    match = _XEON_HEDT_PATTERN.search(model_name)
    if not match:
        return ""
    if match.group(1) == "2":
        return "Haswell-noTSX,model=158,stepping=3"
    return "Broadwell-noTSX,model=158"

Enter fullscreen mode Exit fullscreen mode

私が繰り返し学んでいる教訓: 症状はネットワーク層で現れ、原因はCPUトポロジーにありました。症状から推測したことでリリースを台無しにしました。

2. VMが永久にリカバリモードで起動する

症状: クリーンインストールが完了する。以降の起動はすべてリカバリモードに戻る。OpenCoreピッカーでmacOSを選択するとその起動は成功するが、永続化されない。

原因: 標準のOpenCore設定でAllowSetDefaultがオフになっている。これはブートピッカーでのCtrl+Enterの背後にある設定です。これがオフだと、macOSエントリをデフォルトとして固定する方法がなく、オンディスクのリカバリボリュームがブート競争に常に勝ってしまいます。

設定パッチの1つのキー:

Misc -> Security -> AllowSetDefault = True

Enter fullscreen mode Exit fullscreen mode

その後、ピッカーで: macOSボリュームをハイライトし、Ctrl+Enterを押す。設定が保持されます。

3. インストール後のブート順序は予想とは逆である

macOSのインストール完了後、ブート順序は次のようである必要があります:

ide0;virtio0

Enter fullscreen mode Exit fullscreen mode

OpenCore(ide0)が最初、macOSディスク(virtio0)が2番目です。私はvirtio0;ide0を提案するヒントを出荷しましたが、これはより自然に読めますが間違っています: macOSディスクを直接起動し、OpenCoreを完全にスキップし、VMは初回起動でエラーなしでスタックします。

ハイパーバイザー上のmacOSは、OpenCoreを前面に置かずに起動することはありません。インストール時だけでなく、すべての起動で。

osx-next-cli post-install --vmid 100 --execute

Enter fullscreen mode Exit fullscreen mode

4. 起動のたびに「Memory Modules Misconfigured」

見た目の問題ですが、起動のたびに発生し、うんざりさせられます。

すべてのVMはMacPro7,1 SMBIOSを取得し、標準のOpenCoreイメージにはRestrictEvents.kextが含まれていません。macOSはエミュレートされたメモリレイアウトを見て、本物のMac Proがこのように構成されることはないと判断し、通知します。永遠に。

これを検索すると、ブート引数としてrevpatch=memtabを追加するよう言われます。ここでは何も効果がありません。 revpatch=memtabはMacBookAir SMBIOSモデルにのみ影響します。MacPro7,1ではno-opであり、多くの人が「動作しない」と報告する理由です。

実際の修正はkextを配布することです。RestrictEvents 1.1.6をEFI/OC/Kextsに入れ、config.plistに登録し、デフォルトのrevblock=autoMemorySlotNotificationExpansionSlotNotificationの両方をブロックします。ブート引数は必要ありません。

5. SequoiaとTahoeでApple IDサインインが失敗する

古いmacOSバージョンでは、vmgenidと静的MACでiMessageとFaceTimeにサインインできました。Sequoia 15とTahoe 26ではそうではありません。

AppleのDeviceCheckは現在hv_vmm_present sysctlを読み取ります。VMでは1を返し、サインインは資格情報に到達する前に拒否されます。

コミュニティの修正は、カーネルの文字列テーブルでの文字列スワップで、OpenCoreが起動時に適用します。hibernatecount sysctl名を見つけて、hv_vmm_presentに置き換えます:

Find:    ...hibernatehidready\0 hibernatecount\0
Replace: ...hibernatehidready\0 hv_vmm_present\0

Enter fullscreen mode Exit fullscreen mode

ルックアップは今、ハイバネートカウンターを解決し、これはクリーンブートで0です。macOSは0を読み、DeviceCheckは物理マシンと見なし、サインインが動作します。

これは特定の文字列レイアウトに対するカーネルパッチなので、macOSのポイントリリースで壊れる可能性があるものとして扱います。その理由で明示的な--apple-servicesフラグの背後にあります。

ボーナス: macOS VMのクローンは両方のiCloudを静かに破壊する

Proxmoxのフルクローンはバイトコピーであり、クローンはソースVMのSMBIOSシリアル、UUID、MLB、ROMを継承します。2台のマシン、1つのAppleハードウェアID。Appleはこれに気づき、どちらか一方でサインインに失敗します。

osx-next-cli cloneはフルクローンを作成し、直後にSMBIOS 4つ組とvmgenid、静的MACを再生成するため、クローンはAppleにとって別個のマシンとなります。


すべてがdoctorコマンドになりました

これらの問題はすべて、macOSが無関係に見える方法で誤動作するまで見えない設定レベルのミスです。そこで、任意のVMに対して実行できる12のチェックになりました:

osx-next-cli doctor --vmid 100

Enter fullscreen mode Exit fullscreen mode

バルーン、q35、コア数(2の累乗)、メモリ、CPUタイプ、NICモデル、エージェント、smbios1、ブート順序、virtio0 / ide0 / ide2の存在を確認します。行ごとにOK / WARN / FAILと修正ヒントを表示し、VM設定を直接読み取るため、私のツールが触れたことのないVMでも動作します。ガイドから手動でmacOS VMを構築した場合、そこを指し示してください。

まだ未解決: GPUパススルー

ここから修正できない唯一のこと。実際のGPUをmacOSゲストにパススルーするには、私がテストしていないハードウェアが必要であり、推測することは上記の#1のようなバグを生みます。これは最も多いリクエストであり、正直に言ってテストリグでブロックされています。

上記のすべては出荷済みでmainにあります:

curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh | bash

Enter fullscreen mode Exit fullscreen mode

リポジトリ: github.com/lucid-fabrics/osx-proxmox-next

まだソロプロジェクトです。私が所有していないハードウェアでバグに遭遇した場合は、issueを開いてください。上記の5つのうち4つがそうして発見されました。