Hacker News Reader

Comment by mherrmann | Hacker News Reader

Just spent 4h trying to set this up. It's a pain. If you ever stop a running instance, the dedicated host - for which you are paying - stays in "Pending" mode for indefinite amounts of time. I am still stuck at getting macOS to recognize my non-default volume size > than the tiny 30 GB it comes with. Huge pains for something that should not be so hard (a decently strong macOS VM). Would not recommend.

View on HN

Disclosure: I work for AWS and am part of the team that built EC2 Mac instances

1) After every stop/terminate of Mac instances, EC2 runs a scrubbing workflow on the underlying Dedicated Host to wipe the Mac mini's non-volatile storage and reset the NVRAM variables, to enable same security posture as any other EC2 instance. This workflow also upgrades the T2 chip on Mac mini to the latest BridgeOS version if needed. It may take 30-60 mins for this scrubbing workflow to complete, and up to 2-4 hours if BridgeOS update is required - during which the host shows up in "pending" state. We're actively working on lowering this scrubbing duration and really appreciate your feedback here. Important to note - You are not billed for any duration(s) during which the Mac1 Dedicated Host is in "pending" state (or any state other than "Available").

2. Once you have increased the size of the EBS volume on your Mac1 instance, you can execute following commands within macOS guest to increase the size of your APFS container.

1. Copy and paste the first three lines

PDISK=$(diskutil list physical external | head -n1 | cut -d" " -f1)

APFSCONT=$(diskutil list physical external | grep "Apple_APFS" | tr -s " " | cut -d" " -f8)

sudo diskutil repairDisk $PDISK

2. Accept the prompt with "y", then paste this command

sudo diskutil apfs resizeContainer $APFSCONT 0

Since the EBS volume was resized after boot, an instance reboot is required before the additional disk size is available for your use.

That's interesting about the billing. Playing devil's advocate here -- if I provisioned a Mac dedicated host, used it for the ~1 hour that I actually need, and then repeatedly cycled instances for the rest of the 24 hours to maximize the amount of time that it spends in "pending", would I indeed succeed in paying substantially less than 24 hours worth of time while still obeying the Apple-imposed "one customer per day" restriction? Would this violate a TOS?

How much concern is there on your team that Apple will make breaking changes to internals that you rely on? I've seen that happen multiple times in the past to JAMF, seemingly without any heads up.

We have worked closely and transparently with Apple over the past few months not only on the product definition and platform design, but also on multiple architectural decisions for this offering. Many a times - even though not apparent in those moments (but only in hindsight) - Apple has nudged us in right directions that aligned with their future plans. Granted - it's challenging to keep up with the pace of both Apple and AWS - inadvertent regressions do get introduced with certain releases, but we're building mechanisms to catch and jointly remediate them early. Ultimately, both Apple and AWS are excited about this offering, and share the vision of bringing AWS benefits to all Apple developers. We only expect this collaboration to further deepen going forward.

Question: If you are already working with them, why do you have to use Mac Mini's, as opposed to, say, Apple giving you a special version of the OS that runs on "normal" hardware? Hackintoshs are real and there should be no reason for you to use Mac Mini's in the first place. Of course you can't use a Hackintosh, but the existence of this alternative suggests that this is a possible avenue to explore, especially when cooperating with Apple and keeping to a specific hardware that has the drivers or where drivers can be added easily.

This is The Question and it applies to every single one of these stupendously wasteful deployments of time, space, energy and capital.

Every single mid-sized IT shop in the world has an urgent and valid use-case to virtualize OSX in an efficient and portable manner. Most individual power-end-users have similar use-cases.

How many hours / dollars / gigatons-of-carbon / calories are wasted on this comically inefficient, user-hostile and gratuitously complex state of affairs ?

> How many hours / dollars / gigatons-of-carbon / calories are wasted on this comically inefficient, user-hostile and gratuitously complex state of affairs ?

Many, many more that are being "saved" by them not bundling chargers in iPhone. Kind of shows you where they stand.

Follow the $$$.

Apple's whole shtick is hardware/software integration; they'd have to make and sell the hardware for the VMs to run on.

Don't they already? Mac Pros are a thing. They even are rack mountable.

This is nonsensical. Apple is a hardware company before they are software. In addition, they would have to provide support for the software running on hardware that they don't know, understand or whatever else.

It would have been more likely for AWS to give specs to Apple, who could have then created a custom job for some extra monies.

In reality though, using Mac Minis is perfectly reasonable. It's likely the cheapest option for both Apple and Amazon.

Who would provide large-scale hardware support to AWS for this approach? Certainly not Apple as it’s not their hardware. Also in a few minth from now people will want M1 cpu’s and you wouldn’t have worked towards that at all. If someone is fine with the Hackintosh experience, there are ways to do it in AWS already now.

It’s an “as-A-Service” offering. The hardware is abstracted and you get you use MacOS and its services on demand. It’d be the same as asking Dropbox what happens when their underlying hard drives reaches end of life from the manufacturers. It’s not our problem.

A patched version of macOS that Apple provided could just be a AMI on EC2. They run it on x86 test boxes internally, at least until they complete the transition to Apple Silicon, so it should be possible.

Apple just doesn’t want to support it, and for developers, they want them to buy Macs to work on and only use VMs when absolutely necessary.

Because Apple is a hardware company. I wouldn't expect them to be supportive of a Hackintosh solution, to the point of making it difficult to operate.

I assume this is the v1 product, and simply preparing for the v2 using Apple silicon (M1? M2?)

Apple sells integrated hardware and software. They don’t license macOS to anyone else. Why would they start now having seen that strategy fail in their corporate history already?

Let's be honest. Nobody is running workloads on Mac Mini servers because they think it's a good server OS or good server hardware. They're doing it to run Xcode as part of a CI/CD pipeline (or some other kind of automated testing) in order to develop applications for iOS devices. No, there is no money in Apple for either licensing out their IP or building their own server brand. It's a loss leader or at best a break-even, low-margin business for them, but it's a compliment to their high-margin businesses (having more/better apps means more App Store revenue and helps keep users on the hardware/software platform). Not having a convenient way to run Xcode in an automated workflow is a strategy tax on their other, profitable lines of business.

Or at least have Apple send them Mac Mini hardware not in a Mac Mini case that would hopefully lead to a more integrated or robust solution than a computer sitting in a sled. Would this be beneficial?

Mac sold outside of a shiny brushed aluminum case?

Jony Ive rolling in his grave.

> It may take 30-60 mins for this scrubbing workflow to complete, and up to 2-4 hours if BridgeOS update is required

I’m curious. Did nobody at any point in time ever say ‘this is unacceptable’ about this? Because it sure sounds so to me. It’d be (much) faster to boot up a new instance than wait for your previous instance to exit pending state.

I suspect the macOS license precludes this.

Copyright law seriously needs to change. They should not have to jump through hoops like this simply to use a device that they already paid for.

Thank you. This was very helpful. I would have spent another few hours without your help. If I may make a suggestion, those steps you described should be performed out of the box when I launch the instance with a larger volume size to begin with. And the docs should mention what you wrote above in case someone resizes their volume after the fact. As far as I saw, the docs do already contain instructions for Linux and Windows. Would save others like me, many of whom I suspect will run into this same issue, a lot of time if it gave the macOS instructions you wrote as well.

Why is mac on ec2 so expensive?

This is a genuine question, I'm not being snobby or anything like that.

Not indefinite - there's a 24 hour minimum for macOS instances on the cloud...

That's not what I meant. I want to deploy a new instance on the host which I have to rent for min 24. But I can't because the host is "pending".

Reply on news.ycombinator.com