Ugh. This is a pretty bad situation. I took a look at the VirtualBox Darwin driver source code as well as the relevant method in the Darwin kernel (`host_vmxon`), and I can't see a workaround that I can meaningfully or confidently contribute. I'm hoping for a quick turnaround by Oracle or Apple on something here. :(

For the future, I've been working on VMWare support for some time now, and it should be ready in the next few months. These sorts of problems will be mitigated then by saying "oh, well you can just use Vagrant with X instead for now" (where X is some other virtualization layer).

For now, I'm sorry, I don't think there is anything I can do here.

But I'm definitely going to download and use vagrant now :)

You DID do a backup, didn't you? You HAVE tested that your backups are working, by doing a complete recovery with them, right?

Right? ;)

My personal philosophy is to be cutting edge on my personal/hobby gear (like the last gen MB Pro I keep for, ah, movies and such), but not to do ANY same-day updates on anything even remotely required for work. That shit stays behind the times but reliable for paying the bills.

After I've seen the upgrades working in the wild for a week or two, and I have verified that all the stuff I need actually works like I need it to, THEN I'll do the upgrade on my work box. After backing it up, of course. Hell, I even have a text file with search phrases and forum URLs for the software I need to have working to make it easy and ensure I don't miss anything.

Call me crazy, but I've learned that lesson the hard way.

Anyone got advice for backing up firmware on laptops to allow for roll-backs on breaking changes?

If it wasn't successful, you could use the firmware restore CD that came with the box, or create the CD to do that, but again, that only works for failed upgrade attempts.

I've had to do this once in the past, and the easiest way I could find was to just take it to the local Apple Support shop and get them to do it. They did it for me while I waited, and it didn't cost me anything but time. YMMV.

But good point... I'm not in the habit of backing up firmware.

Why not just using a fast desktop with a couple of monitors at your workplace? And ssh/xterm to it, if you need to work remotely?

It's not being able to have a linux machine. It's being able to have one that you can build, throw away, test different deploy strategies on, etc. etc.

Suddenly you have all the developers dealing with deployment problems as soon as they occur - cutting that loooooong feedback loop to minutes saving everybody time, pain and money.

TL;DR - coz it's a good thing :-)

lxc-create -n [some name] -t ubuntu

Then:

lxc-start -n [some name]

to start it and get the console (or tack on "-d" to run it in the background)

Ubuntu by default starts dnsmasq to serve up local dns results for vm's, so you can ssh to them, and setting up a tunnel for external access is easy.

LXC also works fine on Debian, though the experience isn't quite as polished.

Otherwise, you can use KVM, Qemu, Virtualbox, Vmware, Xen, OpenVz and more. In all cases, you can use the same deployment tools: Build .deb's and set up a local APT repo (just a directory you run dpkg-scanpackages over), or use Sprinkle or use Chef or Puppet or half a dozen other tools. Use buy into Ubuntu's orchestration tools (in particular Juju,which supports direct deployment onto LXC locally, OpenStack or EC2 for now)

In other words, putting your environments on a Linux box doesn't remove the ability to have copies of the deployment environment or building, deploying or testing automatically - it adds a massive number of additional options for how to do it. In particular, it lets you do it in ways that translates directly to private or public Linux based cloud solutions.

The "Why a Mac" bit is because I find I'm more productive on a Mac - and I like them.

(By "more productive" I mean I've actually tracked and measured the stuff I get through each day during several months of using both platforms - ubuntu on the Linux side - and found I come out ahead on the Mac. I didn't try this with Windows coz, until Windows 8, I actively disliked the OS and didn't feel I needed to use something I didn't like even if I did turn out to be more productive :-)

I am very happy with Linux. All our boxes that aren't Mac's are Ubuntu - including some folks personal machines. My personal view towards hardware is you get whatever you feel most productive on. I've been using Unix-ish platforms for large chunks of my working day since 1988. For more than five years I used nothing but Unix-ish boxes (SunOs then Solaris then Linux). I spend large chunks of my day dealing with unix via various terminal windows. I don't find Linux scary or confusing. I just happen to like Macs, and some of the work that I do is easier to do on Macs.

"In other words, putting your environments on a Linux box doesn't remove the ability to have copies of the deployment environment or building, deploying or testing automatically - it adds a massive number of additional options for how to do it. In particular, it lets you do it in ways that translates directly to private or public Linux based cloud solutions."

I never meant to imply in any way that putting things on a Linux box removed the ability to have copies of the deployment environment or building, deploying or testing automatically. My apologies if I was not clear about that.

I know how lxc-create et al work. If the number of virtualisation options were the main factor I had in picking the OS of the machine my keyboard is attached to I'd be using a Linux based laptop. For me, personally, it isn't. So I'm not. That is, of course, in no way saying that Linux laptops are bad (have 'em, use 'em, love 'em). Just that they're not the best fit for me and the work that I do (and I have graphs to prove it :-)

Create a corporate apt repository with your custom modules/libs/ets and mydevenv module that includes all the dependencies. And that's it. You can recreate the environment with one command...

Edit: Uh. Deployment environment. Sorry. Yes. Having QA/Deployment env. in VM is a way to go.

That was the question I was attempting to answer - I have obviously failed :-) Let me try again.

A Macbook + virtualised environment does exactly what I need.

I happen to prefer Apple HW and the OS X GUI. My partner prefers Ubuntu. We both run dev environment in a VM because automating the creation and deployment on a virtualised environment brings a whole bunch of advantages that running it on your base machine does not.

Virtualisation of the dev environment is a good thing regardless of what that virtual environment is running on.

For example:

* We can trivially run the current dev branch on multiple versions of the OS by just building on top of a different vagrant box

* It has basically killed deployment issues stone cold dead for us - since we're always deploying. Problems get found as soon as you f\\k up. You can't forget dependencies. You don't get tempted to make a quick tweak to a config file that you then forget about it. And so on.

* You get your automated deployment code "for free" since you're developing it as you go rather than thinking "okay - how do we deploy this".

* It makes experimenting with different infrastructure / dependencies / versions very, very cheap and simple

* Makes developing in odd/remote locations really simple. All I need is an internet connection, virtual box, our repo and vagrant and I can get a dev environment up and running.

* We each get to have the OS that we like for coding on, without all that tedious "it works on my machine" faffing.

The "VMX root mode" problem is known since at least 2008. On Linux hosts it's been possible to disable whatever puts the CPU into that mode, but that may be harder on OSX.