I know several of you have reached out asking about the support for ESXi 6.5 on the Apple Mac Pro 6,1 but as of right now, the Mac Pro 6,1 is currently not supported with ESXi 6.5. I know this is not ideal especially for customers who wish to take advantage of the latest vSphere release. The good news is that VMware is in the process of testing the Apple Mac Pro 6,1 for ESXi 6.5, however there is not an ETA on when this will be completed. Some of you might be wondering why this did not happen earlier?
Give your Mac's Finder new super powers, manage files and folders faster, control it all with Path Finder. Get full keyboard navigation in a Finder-like app with dual pane view, folder sync, and a long list of tools.
The primary reason is that hardware certification for ESXi is actually performed by the hardware vendors. Once a vendor completes the certification for a particular hardware platform or component, they submit the results to VMware and the VMware HCL is updated.
If there is a piece of hardware that is not on the VMware HCL today, it is definitely worth reaching out to your hardware vendor to inquire about its status. In Apple's case, it unfortunate as they do not participate in VMware's Hardware Certification program for ESXi which makes certification challenging. VMware intends to continue to support customers who require the use of Mac OS X Virtualization and will work towards getting the Mac Pro's certified for latest version of vSphere as mentioned earlier. Historically, testing and certifying ESXi for Apple hardware does take an additional amount of time and in some cases, code changes may even be required due to unexpected hardware changes from Apple. I hope this gives customers some additional insights into how Apple hardware is certified for ESXi. If you would like to see this improved in the future, you may want to reach out to Apple and provide them with your feedback.
Before you close this blog post thinking it is going to take awhile before there is going to be an update regarding ESXi 6.5 and Mac Pro 6,1, please continue reading further 🙂 UPDATE - ESXi 6.5 Update 1 just GA'ed yesterday and is fully supported with all current Apple Mac Pro 6,1 (as you can see on the HCL ) and the workaround mentioned below is no longer required. This means you can install ESXi without any modification to the image. UPDATE - VMware has just published the following which outlines the officially recommended workaround to install ESXi 6.5 onto the Apple Mac Pro 6,1. The VMware HCL has also been updated to include the. In a future release of ESXi, the workaround will not be required and ESXi will just install out of the box. This temporarily workaround is to enable customers who wish to run the current version of ESXi 6.5 which includes GA release, 6.5a and 6.5p01. Disclaimer: The following section below is not officially supported or recommended by VMware.
Please use at your own risk. Early last week, I had a customer who had reached out to me that attempted an install of ESXi 6.5 on their Mac Pro 6,1. They were already aware that the platform was not officially supported with ESXi 6.5, but wanted to see if I had any ideas that they could try. When attempting to boot the ESXi installer (upgrade or fresh install), they saw the following error message in the ESXi logs: WARNING: vmwahci00000e00: ExceptionHandlerWorld:AHCISIGNALABORTREQUEST signal.
Vmwahci00000e00: ExceptionHandlerWorld: Abort scan took 1 (us) to complete, 0 commands aborted. FSS: 5749: No FS driver claimed device The customer had theorized that perhaps there was an issue with the AHCI driver but since the system would not boot further, there was not much more they could do. Looking at the error, I also agreed the issue might be related to the AHCI driver which gave me an idea. The specific driver shown in the logs is the new AHCI which is new in ESXi 6.5. Perhaps, the new driver is not able to claim the disk drives and is preventing the boot-up. I recommended to the customer that they could actually fall back to the 'legacy' vmklinux driver and see if that would allow them to progress further and to my surprise, that actually worked. Not only did the installer completely boot, but the customer was able to perform both a fresh install of ESXi 6.5 as well as an upgrade from ESXi 6.0 to 6.5 on the Mac Pro 6,1 without any issues.
Of course, we do not know if this is the real fix or if there are other issues. So far the customer has not reported any issues but it is still recommended that customers who want official support for Mac Pro 6,1 and ESXi 6.5 to hold off until it is certified by VMware. For customers who wish to push the 'Not Supported' boundaries a bit, below are the instructions on how to get ESXi 6.5 booted and installed on Mac Pro 6,1. Add the following ESXi boot option (persistent) by pressing SHIFT+O when you are presented at the initial black screen.
PreferVmklinux=True At this point, you can now successfully boot the ESXi 6.5 installer and perform either a fresh install or an upgrade. You will NOT need to perform this operational again as the change is persistent. If you prefer not to manually have to add the ESXi boot option by hand, you can create an ESXi bootable USB key and then simply edit both boot.cfg and efi/boot/boot.cfg and append the option as shown below: kernelopt=runweasel preferVmklinux=True I will be sure to share this information with our Engineering folks working on testing the Mac Pro 6,1 but at least we know its possible to install ESXi 6.5 🙂 Big thanks to Andrew for reaching out and I think we were both pleasantly surprised by the outcome. FYI - For customers who use the Apple Mac Mini, ESXi 6.5 seems to run fine without any issues (e.g. Fresh install or upgrade). I have not heard of any real major issues, so you should be fine.
Please note that the Apple Mac Mini is not an officially supported hardware platform, please use at your own risk. Thanks so much for taking the time to help with this! We used this for some development hosts and so far things appear to be working OK. Looking forward to official support and putting this into production.
We’ve had a much better experience installing macOS Sierra VMs on 6.5 (with the new Guest OS version OS X 10.12 setting). Previously we’ve had issues installing Sierra from ISO (converted in various ways from the InstallESD.dmg) and sometimes issues booting into the OS but now it appears to work without issue. Thanks a lot! This workaround also fixed my issue that ESXi 6.5 vmwahci doesn’t recognize the drive attached to qemu-kvm AHCI controller.
I got errors like this: vmkernel.log:3415:2017-03-27T02:47:20.507Z cpu0:66624)vmwahci00000002: scsiDiscover:calling ahciReadIdentityData vmkernel.log:3416:2017-03-27T02:47:20.517Z cpu0:66624)WARNING: vmwahci00000002: ExecInternalTempDMA:ERROR: DMA transaction did not transfer data for internal command. Vmkernel.log:3417:2017-03-27T02:47:20.517Z cpu0:66624)WARNING: vmwahci00000002: ahciReadIdentityData:ERROR: failed to read identity vmkernel.log:3418:2017-03-27T02:47:20.517Z cpu0:66624)vmwahci00000002: scsiDiscover:ahciReadIdentityData failed! I’ve tried to find other potential uses of my Mac Pro 6,1.
Before finding this site, I’ve only focused on Linux. However, I found the video parts of my two D700 cards were shown in grey/disabled for passthrough at the hardware dialog box of ESXi 6.5, but only the audio parts could be enabled. Any methods or suggestions to have D700 GPU passed-through to guest OS?
By the way, FYI, with the newest iso I donwloaded, I did not need to use the ‘prefervmklinux=True’ to get an event-free boot. Hi William, I was going to inquire about an interesting topic via LinkedIn but I’ll start the conversation here. On the 2013 Mac Pro, using either RHEL (maybe CentOS)/Ubuntu or Windows 2008/2012 R2 been able to successfully get OpenCL running on a virtualized instance with passthrough (or do you require it)(does it function like Nvidia GRID technology)? I ask because I have a huge Dell PowerEdge tower that frankly, runs too hot and loud for my office lab. I need the GPU for professional requirements and I need OpenCL applications to recognize the GPU (at least one of them). I think I read that the legacy AMD driver under 14.04.fglrx. was being used.
One of the issues I have came across so far on bare hardware recently with AMD is the provider supplied drivers are messy. AMDPRO-GPU is the driver being used under 16.04 LTS that supports newer GCN GPU architechtures for which I thought this should be, at least if it’s what people claim they are variants of here: William, would you be willing to validate on any VM, Linux or Windows, that you can run an OpenCL application (i.e.
William, I’ve followed your blog for years, running my first DFIR lab with a MacMini server model, later a full blown Dell R610 with dual Xeon hex-cores and now, I had to downgrade that (because it was just too hot in my lab) to a Mac Pro. This will be running my SIEM/UEBA, AD-DS/NPS server along with my SOA and ITSM solution – I’m a little concerned on applying As some of this is done at microcode level by the vendor, we all know Apple could give a hoot about DellEMC or VMware – will this even work? Look, I like Dell servers. They are made in Round Rock and I support that. I don’t support not being able to run a consumer GPU on a 16x PCI lane (just because) or proprietary drives so I’d really like to know I can patch this OS without bricking it. Your thoughts on mitigation for the hypervisor host? We are seeing the latest firmware (MP61.0120.B00 – released in conjunction with macOS 10.13) for the Mac Pro cause many varying issues after the install of ESXi 6.5U1 (note we don’t see any errors during the install).
We have seen the following behavior on identical Pros with the above firmware after we set management network info and then reboot: -Management network IP and root password are forgotten (even though we’ve logged in with the password just minutes earlier before the reboot) OR -“BANK5: invalid update counter. No hypervisor found.” OR -“kernel= must be set in /boot.cfg.
Fatal error: 32 (Syntax)” We have tried multiple install medias (to rule out a bad CD or USB stick), and we have zeroed out the SSDs in the Pros. The only thing in common with the errors we see is the latest firmware version (MP61.0120.B00), and using the preferVmklinux=True workaround is the only thing we’ve found to mitigate the issue. Happy to provide more information or run any tests, but for now we’ll continue to use the workaround. Thank you @specter345.
I know this is the case with that firmware, it is intended to address the Thunderkit (Sonic Screwdriver) exploit which Rich Smith of Duo Labs and I confirmed. My issues today are now with EFI MP61.88Z.0116.B600 which IS listed as compatible with 6.5u1.
The installer works without issue, if you don’t mind being pwned at ring -2, -1 and 0 should that exploit be used against you which is only possible with the Thunderbolt to Gigabit Ethernet adapter. The main concern I am having is with this supported EFI release above. I have that EFI firmware as well and while I am aware of its vulnerabilities, both Broadcom BCM577xx onboard pNIC’s are recognized yet the Thunderbolt adapters needed for additional connectivity are not.
I have six of these and I plan to use at least four in a managed network. If the vmkernel doesn’t recognize them with supported firmware, that is a whole different ball of wax that VMware needs to address as these should appear as essentially no different that any pNIC connected directly to the PCI-E bus. @specter345 & @Brian Apologies for the delay, I’ve been on paternity leave and yesterday was literally my first day back.
Can I ask if either of you have filed an official VMware SR (this is the recommended approach so we can properly track issues/requests), if so, can you provide that to me? I’m still catching up from being away, but I did drop a note to a few of the Engrs. They did confirm that they’ve got latest ESXi 6.5u1 running on both MP61.88Z.0116.B600 (listed on VMW HCL) as well as MP61.88Z.0120.B652 (included w/MacOS 10.13.3) without any issues. If you’re still having trouble installing ESXi, it would be great to get an SR filed (if you haven’t already with all the details and steps you’ve taken). With respect to the comment from Brian on the Thunderbolt to Ethernet Adapter, this is not something that was ever officially supported by VMware. I’m not sure if you’re aware or had assumed (although this has mostly worked as the Apple device uses tg3 driver, it was mostly luck that I had discovered it rather than something VMware officially blesses and is listed on HCL).
I will definitely do that. I have some other things to run by you guys as we are really stuck. The mac pro has officially passed all osx tests by a certified tech.
When we boot esxi in our pre deployment lab on this 2017 mac pro it works fine. We can even reboot it with out issues. We then move the mac pro into a sonnet case and continue to rebooting in the lab and its fine. We then move the mac pro into the data center and it crashed like clockwork.
It comes up with different errors depending on the version of esxi. We are stumped on what it could be. How can it work in our pre deployment lab fine and be rebooted, have the power cord out and plugged back in and still boots? Once moved into our data center it fails to boot immediately. Here are the list of errors: ESXi 6.5: Failed to mount boot tardisks. ESXi 6.5: fatal error: 32 ( syntax ) ESXi 6.0 Key error ‘Bootstate’ Esxi 6.7: Error loading /state.tgz / fatal error: 6 Again its only crashing when moved to the data center. 0) Apple Hardware MacPro Black 3.5 GHz, 6-Core Intel Xeon E5 Model 6,1 Late 2013 32GB 512GB Apple PCIe SSD (SM = Samsung) BIOS Vendor:Apple Inc.
Macs Fan Control For Mac
0) Apple Hardware MacPro Black 3.5 GHz, 6-Core Intel Xeon E5 Model 6,1 Late 2013 32GB 512GB Apple PCIe SSD (SM = Samsung) BIOS Vendor:Apple Inc. Hi MacITC I am having very similar problems with ESXi on two Mac Pro 6,1’s. I have tried versions of ESXi including 6.5.0u1 and 6.5.0u2. After the initial installation, all is working perfectly but after a full power down, disconnection of cables and relocation of the Server, I get the wonderful PSOD. I have tried setting the ‘preferVmklinx=true’ boot option on various occasions and still end up with the same result.
Our current work around is to not power down the server! This is obviously very problematic and not always possible.
Heat Fan Control In Esxi For Mac Mini
I have 3 other Mac Pro 6,1’s on site running 6.5.0 and earlier versions of EXSi perfectly. The only difference I can think is the firmware version as the problematic Mac Pro’s were purchased later and shipped with a newer firmware.
Esxi Mac Mini
This is driving me insane. In order to verify your experience I have shutdown the MacPro from above twice. Shutdown: – ESXi is starting seamless but the VCSA VM on the Server is marked red as invalid VM — This might be just an unpleasant conicidence — VM was beyond repair, had to re-install and reconfigure the VCSA 2.