• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • VMware Cloud
  • Home Lab
  • Nested Virtualization
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • VCSA
  • VSAN
You are here: Home / Apple / GPU passthrough with ESXi on the Apple 2019 Mac Pro 7,1

GPU passthrough with ESXi on the Apple 2019 Mac Pro 7,1

12/23/2020 by William Lam 12 Comments

The expandability of the Apple 2019 Mac Pro (7,1) has been the primary reason VMware customers have been so excited for this new platform for virtualizing macOS on ESXi. The most common request that I hear from customers is for GPU passthrough.

Although VMware does not officially support GPU passthrough, even for the existing Apple hardware systems on the VMware HCL, this has been a topic I have been keeping an eye out on, especially from what the VMware community is doing in this space.

My intention for this blog post is to provide a resource for the community on capturing the success and failures when attempting GPU passthrough on a 2019 Mac Pro. For those interested and have capable hardware, you may want to start with the VMware HCL for GPU passthrough devices listed under Virtual Dedicated Graphics Acceleration (vDGA). This may be your best chance to successfully passthrough a GPU that will be recognized by either a macOS or Linux/Windows guest operating system.

If you would like to share your experiences, feel free to leave a comment or reach out by filling the contact form.

Disclaimer: Although ESXi installs and runs on the Apple 2019 Mac Pro 7,1 it is currently not certified on the VMware HCL. There are no timelines on the certification due to challenges with COVID-19.

Radeon Pro W5700X MPX Module

Thanks to fellow reader Ned who recently reached out and shared his experience with the Radeon Pro W5700x MPX Module from Apple. Ned's initial attempt to passthrough the GPU to a macOS guest caused it to kernel panice when loading the Radeon Framebuffer Driver (RadeonX6000Framebuffer). I had suggested using a GPU that was on VMware's HCL to see if that made a difference or experiment by using a Windows guest to see if the behavior was the same.

It turns out that by using a Windows 10 (64-Bit) guest, Ned was successful in passing through the Radeon GPU to the VM and this looks to be an issue with the macOS driver, at least running in a VM. This testing was done using latest ESXi 7.0 Update 1b release.

More from my site

  • Aquantia/Marvell AQtion (Atlantic) driver now inbox in ESXi 7.0 Update 2
  • Apple NVMe driver for ESXi using new Community NVMe Driver for ESXi Fling 
  • Virtually Speaking Podcast: MacOS Virtualization and MacStadium
  • Update on ESXi on Apple Mac Mini 2018 & Mac Pro 2019
  • ESXi on the new 2019 Apple Mac Pro
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Apple, vSphere 7.0 Tagged With: apple, GPU, mac pro

Reader Interactions

Comments

  1. Johnny says

    12/23/2020 at 8:13 am

    Great to read that, but passthrough for all platform can be much better than a mac. Like using an Asrock.. to pass the main pci you have to turn off the onboard one. Perhaps a ‘sink’ function that can patch the esxi console could be a way somehow ?

    Reply
    • William Lam says

      12/23/2020 at 4:54 pm

      This post is for folks who have a need to virtualize macOS guests and need GPU passthrough capabilities. Per Apple and VMware’s EULA, to legally virtualize macOS, you must use Apple Hardware. This post is NOT geared towards folks who do not have these requirements and can run generic x86 platforms where GPU passthrough is well understood 🙂

      Reply
  2. Jonathan Fletcher says

    12/23/2020 at 8:45 am

    Thanks, William! What’s the forecast for ESXi on Apple Silicon? It looks like the new tech is going to give everyone a run for their money in the performance for the buck department. Thanks!

    Reply
    • William Lam says

      12/23/2020 at 4:51 pm

      No insights for ESXi on Apple Silicon but I know the Fusion folks are working on their initial enablement https://twitter.com/VMwareFusion/status/1326229094648832000

      Reply
      • Jonathan Fletcher says

        12/23/2020 at 6:54 pm

        That’ll be a good place to start. Thanks!

        Reply
  3. Markus says

    12/24/2020 at 5:19 pm

    About HCL: I am having quite some discussions with support about HCL certification of Mac Pro. They tell me that Apple has to do the certification. Is that true? I find it kind of strange that Apple has interest in VMware HCL certification at all!

    Reply
    • William Lam says

      12/26/2020 at 7:45 am

      VMware Support is correct, hardware certification of ANY kind is usually performed by the hardware vendor themselves. They determine which platform and subsequent components they wish to certify and that’s how the HCL is updated. Apple is an outlier as they have not join VMware’s partner program nor shown any interests in applying for hardware certification which would also include GPUs. That is why these efforts have mostly been community driven and VMware doing its best to support our customers. If you have any feedback/concerns in these areas and you have an Enterprise agreement with Apple, I highly recommend you share it with the account team.

      Reply
      • Markus says

        12/26/2020 at 8:05 am

        Hmm if that is so who certified the old Mac Pro / new Mac Mini? Support is not helping (not even try to help) since they say that Apple needs to put the system on the VMware HCL – which they will not do i guess.

        Reply
        • William Lam says

          12/26/2020 at 8:24 am

          Markus, as I’ve stated in my previous reply, in case it wasn’t clear. VMware has taken on the responsibility of certifying these platforms to better support our customers. This is not ideal for number of reasons.

          The 2019 Mac Pro is currently NOT certified per my note in the blog post. So they can NOT help and even if it was certified, there are no plans for GPU passthrough certification

          Reply
  4. Francis Augusto Medeiros-Logeay says

    12/26/2020 at 12:49 am

    Hi William! Since you mentioned GPU passthrough, any hopes of VMware realising a Horizon agent for Macs one day? It would be cool to use some Mac-VDI in a few use cases.

    Reply
    • William Lam says

      12/26/2020 at 7:40 am

      I’m not aware of any plans to do so from our End User Computing Business Units

      Reply
  5. n3dwilson says

    04/06/2021 at 7:05 pm

    Hey all, sorry I’ve been dark for a bit – I had to put these machines into production as bare metal and abandon my ESXi testing for a bit.

    Currently, I’ve been trying for the last day or two using vSphere 7.0.2. If I create a new VM from scratch and install macOS on it, or if I export a functioning VM out of VMware Fusion to my ESXi host, I get the dreaded reboot loop, which kernel panics and produces the following error message:

    DarwinPanic: panic(cpu 7 caller 0xffffff7faa9a4b63): “DSMOS: SMC read error K0: 133″@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/DontStealMacOS/DontStealMacOS-31.40.1/Dont_Steal_MacOS.cpp:192

    The only way to get past this, besides possibly starting a fresh VM with Mountain Lion and upgrading through the versions, is to install the ESXi unlocker. This should not be necessary, since I am attempting to virtualize macOS on Apple-branded hardware (MacPro7,1), but it was the only way to move forward.

    The next step from here was to try to get the GPU passthru to work. If you follow William’s excellent guide on the 2018 Mac mini, it pretty much works as advertised. I did add a specific hardware label to both the GPU and the associated HDMI Audio device. This is a significant improvement from ESXi 7.0 and 7.0u1, which would kernel panic on boot.

    When I boot a VM, I am able to see the GPU in the system profiler. Unfortunately, I can’t seem to get macOS to actually use the GPU for either acceleration or to drive a display. I did try disabling the kernel VGA driver, which didn’t seem to help much. I also tried setting svga.present = “FALSE” in the vmx file, but this was a bad idea – the machine couldn’t find an OS after doing so! The log message I got looked like this:

    [msg.Backdoor.OsNotFound] No operating system was found. If you have an operating system installation disc, you can insert the disc into the system’s CD-ROM drive and restart the virtual machine.

    Setting svga.present back to “TRUE” again will allow the VM to boot, but the GPU is not used:

    Graphics/Displays:

    Display:

    Type: GPU
    VRAM (Total): 128 MB
    Device ID: 0x0405
    Revision ID: 0x0000
    Displays:
    Display:
    Resolution: 1024 x 768 (XGA – eXtended Graphics Array)
    UI Looks like: 1024 x 768
    Framebuffer Depth: 24-Bit Color (ARGB8888)
    Main Display: Yes
    Mirror: Off
    Online: Yes
    Automatically Adjust Brightness: Yes
    Vendor ID: 0x15ad

    Display:

    Type: GPU
    Bus: PCIe
    PCIe Lane Width: x32
    Vendor: AMD (0x1002)
    Device ID: 0x7310
    Revision ID: 0x0000

    Sadly, I’m going to put this machine back into production as bare metal yet again. 🙁

    Reply

Thanks for the comment! Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Services Business Unit (CSBU) at VMware. He focuses on Automation, Integration and Operation for the VMware Cloud Software Defined Datacenters (SDDC)

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Sponsors

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy