Virtualbox Mac m1

I’m really sorry. I was very tempted to buy a new top of the line too but held off after researching. Apple really over exaggerated about the capabilities of Rosetta.

Personally I love MacOS, and the Apple hardware but I feel like they’re lost. Touch Bar thing for a few years then throw it aside.

Apple keeps doing these things leaving consumers out of dry.

How can actual developers use MacOS with the newest Apple MacBook Pro’s? Short answer, many can’t.

Want to run Virtualbox? Parallels? VMWare? No, you can’t do any x86 based OS’s virtualized.

How does docker work with x86 OS’s?

What about older versions of python or dotnet core or Haskell or native anything?

Sorry you feel scammed, Apple is scamming us by lying!!!!

Yet right there on the VirtualBox "End User Documentation" page is:

In order to run VirtualBox on your machine, you need:

• Reasonably powerful x86 hardware. Any recent Intel or AMD processor should do.

https://www.virtualbox.org/wiki/End-user_documentation

Not emulated x86, x86 hardware.

I’m really sorry. I was very tempted to buy a new top of the line too but held off after researching. Apple really over exaggerated about the capabilities of Rosetta.

Where did they do that? As with the first Rosetta, Rosetta 2 allows you to run Intel-only Mac apps. Rosetta never let you virtualize a PowerPC OS. You can probably run an intel-only virtual machine app, but that doesn't mean that virtual machine can host an intel OS. If the virtualizer had to translate all of the Intel calls through Rosetta 2, it would just sit there for hours. That's not how a virtual machine works.

Touch Bar thing for a few years then throw it aside.

It isn't particularly useful. I've got one I almost never use. Occasionally I tap the OK button when I enter a PIN because it is right there. It never provided any value for me. That's why it is dead.

Barney-15E wrote:

It isn't particularly useful. I've got one I almost never use. Occasionally I tap the OK button when I enter a PIN because it is right there. It never provided any value for me. That's why it is dead.

I had the problem that I use the ESC key frequently and moving a finger toward the ESC key brought it close enough to activate whatever was on the left side of the touch bar, and there's no way to reduce the touch bar's sensitivity or shut it off altogether.

Then if they buy M1 Macs they will need to buy Parallels or VMWare and run VMs of operating systems that are ARM-based like Windows for ARM or, of course, Linux.

Qemu might work to emulate x86 instructions well enough to allow you to launch virtual x86 instances on M1, but none of the big vendors (VirtualBox, Parallels or VMWare) are willing to commit to that, and performance won't be great.

Exactly. That’s a pretty big capability to lose. In my dreams we’d have mbp with Intel cpu, 64GB ram and GeForce gpus for machine learning.

This current crap is making think about going elsewhere for my new laptop and that’s upsetting cause their hardware is my problem. I feel like this M1 thing is a bad decision

For people like you, Dell or HP anxiously await your business.

For those who just want to get a job done or who develop for iOS or macOS, the M1 is a minor miracle, freeing Apple from Intel’s delayed timelines and the heat budgets that caused past MBP 16 owners to complain incessantly about fans.

I’m thrilled with the increase in performance and lower heat generation the M1 Max brings.

I’ve never needed to run x86 VMs on my

iPad, and I don’t need to on my MBP.

Nope, Apple’s done with Intel and is transitioning fully away, the same as once they switched to x86 they never made another PowerPC Mac.

That’s the whole reason they design their own CPUs now - the M processor is where Apple’s future lies.

Oh ya, remember Touch Bar? How about dumb chicklet keyboard? These things come and go. Rosetta v2 is v2 for a reason, Apple already did this like 20 years ago and went back to Intel.

Lol, guess we’ll see where things wind up in a few years. The M1 doesn’t seem ready for developers not focused on iOS or MacOS dev.

I’ll buy a 32GB MBP from Apple refurbished site next and wait 3 more years and see.

I wish Apple was more upfront with all of these shortcomings instead of acting like they totally solved all of the problems, this makes customers lose trust in Apple.

You’re right, I guess changing things so dramatically created this response in me. I need to work the way I do, and so do many other developers.

If you don’t research enough you’ll find yourself unable to work holding a brand new laptop, cut off from capabilities you didn’t necessarily think you’d be missing!

I agree, that’s why it’s amazing Apple offers their 14 day refund policy.

You can order a maxed out $6K MBP M1 Max, and Apple will gladly refund you in full even if you don’t like the feel of the keyboard.

Hi @spencerator,

While I have the same problem as you (I spin up tons of VM's for development), I'm actually pretty happy with my M1 machine for stuff like code compilation and video editing. I just run my VM's remotely on other x86 based machines (vSphere or my old Mac), or in the cloud (AWS in my case). Headless x86 machines with decent CPU/MEM/Storage can be pretty cheap these days, and cloud costs are also pretty low if you only spin machines up for short periods.

Apple are still selling Intel (x86) based Macs, and they have a 14 day "no questions asked" returns policy that would have allowed you to switch back to x86. They should have offered you that option when you said "hey, VirtualBox doesn't work and it's critical to my workflow" so I'd ask them why that was missed and whether they could be nice to you and extend the returns deadline.

If they won't extend beyond the 14 day returns window, you can still sell your M1's privately to fund the purchase of x86 Macs... and since M1 still has a fairly long lead time and low availability, you may break even or even make a profit.

With respect to support longevity, when they switched from PowerPC to x86, they supported the old machines for quite some time.

While Rosetta works for some stuff, Hypervisors access the hardware at a pretty low level, and the ARM instruction set is pretty different to x86 (and so requires a lot of heavy/cpu intensive emulation instead of running natively). Oracle has opted not to put the work in to port their code to ARM, and both Parallels and vmWare are opting to run hypervisors that allow ARM VM's only (at present).

If you're interested in going the emulation route (to run x86 OS) you might look at QEMU, which has a nice wrapper called UTM https://mac.getutm.app/

WRT you comments on M1 based Linux, there are many ARM based distros that will run under Parallels or vmWare Fusion but see https://asahilinux.org/about/ which is being developed specifically for M1. It's rumoured that ARM based windows will also run under vmWare Fusion for Apple Silicon, but it's doubtful this will be considered legal in the short term.

TrickyEarlobe wrote:

It's rumoured that ARM based windows will also run under vmWare Fusion for Apple Silicon, but it's doubtful this will be considered legal in the short term.

I don't know why there would be an issue with VMWare given Parallels proudly advertises Windows will run on their product for Mac, either x86 or Apple Silicon, provided you have the appropriate version of Windows, of course:

Parallels: Install Windows on a Mac with Apple M1 chip

@TrickyEarlobe,

Thanks for the info. QEMU looks like an interesting possibility to explore.

I ended up halting half the iMacs that we ordered until we figure out what to do. I too am letting my old Mac with the VMs run remotely in the IT lab for now.

I did send back the Mac Mini That we ordered to act as an MDM server... because the day it arrived, Apple Updated the server app and essentially broke the only function that the Server app still does lol.

I also like something dangoulet1 pointed out in the previous comments:

"Most people use those apps for years and simply forget, their workflows grow and change and they trust Apple to have a solution to a normal problem. "

That's what happened to me. You just get used to Apple's "It Just Works" reputation because they usually have thought of everything before they release. Until I actually tried to spool up a VM, I didn't really think about chipset compatibility because in my initial tests, Virtual Box installed and started just fine. But after I posted my initial rant I was like... "Oh Yeah. Of course the x86 VM won't run on ARM, duh."

I do love the new iMac for coding and all the things I do on the IT side. The displays are super crispy. Can't say enough about how good they are in every other way.

It's probably just a matter of time before someone has some ARM Virtual Machines that will be compatible with Apple Silicon. I am primarily spooling LAMP server VMs so I don't need the VM to be x86, just needs to run a LAMP stack and I have several Raspberry Pi machines setup as LAMP servers on ARM hardware so it should be doable. Until then the old intel Macs will run the VMs remotely in the lab.

Dogcow-Moof wrote:

I don't know why there would be an issue with VMWare given Parallels proudly advertises Windows will run on their product for Mac, either x86 or Apple Silicon, provided you have the appropriate version of Windows, of course:

Hi @Dogcow-Moof,

For sure, Windows for ARM runs on Parallels, and they make it easy by automating the process to get the necessary Windows Insider images, but the licensing is a bit "iffy" as technically Windows ARM is only licensed by Microsoft for distribution through OEM's who preload it ONLY on ARM machines based on Qualcomm CPU's.

By manually downloading the Windows Insider images, and with a bit of help from QEMU (to do the VHDX to VMDK conversion) you can get it to run in vmWare Fusion too, but there are currently problems with networking that need to be resolved.

Since vmWare don't officially support running ARM Windows in Fusion (probably due to the Microsoft/Qualcomm ARM license situation) its not clear if they will add the installation helpers that are in Parallels, and fix the network driver issues any time soon. There are however some workarounds involving the kernel debugger which I've read about, but haven't investigated/verified.