VirtualBox broken on Ivy Bridge Macbooks after 10.8.2 and Firmware Update(discussions.apple.com)
discussions.apple.com
VirtualBox broken on Ivy Bridge Macbooks after 10.8.2 and Firmware Update
https://discussions.apple.com/thread/4311118?start=15&tstart=0
53 comments
(Vagrant creator here)
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.
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.
Thanks for looking into this and working so hard on Vagrant. It's an awesome product.
It's not your fault, I shouldn't have upgraded :( Thanks for vagrant it's really awesome!
I've used virtualbox for a while, but hadn't heard of Vagrant; it looks awesome. Luckily, this article popped up before I upgraded, so I'm sticking firmly to .1 now.
But I'm definitely going to download and use vagrant now :)
But I'm definitely going to download and use vagrant now :)
I've used VMWare for a while now, and it is indeed very fast. I've just started using Vagrant (thanks for creating it!) and love it, despite the slowness of Virtual Box. Good luck with VMWare support, I'm looking forward to that.
Just revert back to the backup you took right before you did the upgrade.
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.
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.
This seems to be based on an upgrade to the EFI firmware, in addition to the 10.8.2 update. While I've got verified backups for the OS, I'm not in the habit of regularly backing up the EFI firmware, nor do I know how I would restore it on my MBP.
Anyone got advice for backing up firmware on laptops to allow for roll-backs on breaking changes?
Anyone got advice for backing up firmware on laptops to allow for roll-backs on breaking changes?
I'm not sure there is a way for an end-user to revert to a previous version once a firmware update has been successfully applied.
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.
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.
Just to confirm, this is only caused by 10.8.2, not the EFI firmware update. So you can rollback to a 10.8.1 backup and everything works fine.
Is there a discussion with details on the issue? Parallels and VMWare release new versions all the time for compatibility issues, they just fix them before the update comes so their new version is ready. Should VirtualBox just fix the bug on their side, or is this really an Apple issue?
I'm not sure who to blame, these are the details everyone is posting so far: https://www.virtualbox.org/ticket/10965 It seems like the VirtualBox community was talking about this problem for a long time already, since early september.
You have Linux/Ubuntu development envinroment, right? Why do you use it in a VM on a Mac in the first place?
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?
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?
Because being able to have a copy of the deployment environment - especially one that you can build, deploy and test automatically, is stupidly useful.
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 :-)
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 :-)
Well, it can be as easy as 'sudo apt-get install mydevenv'.
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.
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.
Get a Linux box you can run VMs on then (ie non virtualised), or use a cloud service?
Linux supports about a dozen virtualization technologies, and modern distros, e.g. Ubuntu 12.04, makes it trivial. Here's what it takes to start a new Ubuntu based container (less isolated, but more than enough for a dev environment) on Ubuntu 12.04:
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.
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.
Sorry - I just answered the "Why do you use it in a VM" bit, and ignoring the "why a Mac" bit :-)
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 :-)
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 :-)
You can virtualize linux in linux with no trouble at all (even with VirtualBox if you like). As I read it, the suggestion wasn't that you replace your virtualized Linux with physical hardware, it was that you replace your Macbook with a system that does what you need.
As I read it, the suggestion wasn't that you replace your virtualized Linux with physical hardware, it was that you replace your Macbook with a system that does what you need.
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.
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.
I'd be interested in knowing whether this is genuinely a bug on Apple's side or whether it's something that VirtualBox should have been aware of. It sounds like a bug, but if there's an issue with virtualization surely VMWare and Parallels would also have broken functionality as well.
https://forums.virtualbox.org/viewtopic.php?p=52266
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.
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.
Thanks. Well that certainly makes it look like a VB issue rather than Apple, doesn't have an impact for me but I can imagine there's some very stressed developers this morning.
There's more information here: http://www.virtualbox.org/manual/ch10.html , "Hardware vs. software virtualization" and forward. If I'm reading it right, it might be possible to run VB in software virtualization mode even with the new firmware.
[deleted]
This is another benefit of still being on Lion. I didn't have to deal with weird homebrew issues and now I don't have to deal with this. I have not upgraded to Mountain Lion on any of my machines, and the way things are going I'm probably not going to until forced.
> I didn't have to deal with weird homebrew issues...
Just out of curiosity: which weird issues? The only "issues" I had involved installing XQuartz, and chowning /usr/local/ back to me[1]
[1]: http://robots.thoughtbot.com/post/27985816073/the-hitchhiker...
Just out of curiosity: which weird issues? The only "issues" I had involved installing XQuartz, and chowning /usr/local/ back to me[1]
[1]: http://robots.thoughtbot.com/post/27985816073/the-hitchhiker...
I don't actually know any details. All I know is that when several of my coworkers upgraded to 10.8 components of their homebrew setup stopped working. It may have been related to ruby.
The (annoying, but working) workaround is the following:
I imported my Vagrant-managed Ubuntu 10.04.4 LTS VM into a trial copy of Parallels Desktop 8. I then logged into the VM manually using the Parallels VM window using the default Vagrant user / password (vagrant/vagrant) and changed the password for my custom Vagrantfile dev login. Then in Parallels I switched the networking on the VM to Bridge Mode (so I can access it via IP address on my local network).
Remarkably everything in the VM worked and I'm back to coding. Would like to see a quick fix for VirtualBox so I can get back to my Vagrant awesomeness.
I imported my Vagrant-managed Ubuntu 10.04.4 LTS VM into a trial copy of Parallels Desktop 8. I then logged into the VM manually using the Parallels VM window using the default Vagrant user / password (vagrant/vagrant) and changed the password for my custom Vagrantfile dev login. Then in Parallels I switched the networking on the VM to Bridge Mode (so I can access it via IP address on my local network).
Remarkably everything in the VM worked and I'm back to coding. Would like to see a quick fix for VirtualBox so I can get back to my Vagrant awesomeness.
Can anyone confirm this update does not break VirtualBox on the mid 2011 Macbook Air i7? I rely on Vagrant and am not feeling confident enough to update since the issue appears to be related to VT-x on the CPU
For what it's worth, I just updated to 4.1.22 on such a machine and a snapshotted VM resumed without any trouble.
Edit: And then also to 4.2.0 without trouble.
Edit: And then also to 4.2.0 without trouble.
And somehow VMware Fusion doesn't have any problems after the same update ... sometimes you do get what you pay for (then again, I remember when an earlier Fusion update bricked itself, so YMMV).
The other thing you get with Fusion (and Parallels, but not Virtual Box) is decent performance; in my office we're all running Ubuntu in Fusion on OSX - we were running Virtual Box until we realised our unit tests ran in half the time under Fusion.
But that's pretty much what I'd expect from two companies in the business of virtualisation, versus one behemoth who really doesn't care - particularly if they're not making a significant slice of revenue (or any?) from it.
But that's pretty much what I'd expect from two companies in the business of virtualisation, versus one behemoth who really doesn't care - particularly if they're not making a significant slice of revenue (or any?) from it.
Hm - is this just for Mac OS X or is this true for the windows version of virtualbox as well?
I was trying to find the difference between virtualbox and vmware player on the windows side.
Can't really decide between parallels and fusion though...I need to run some opengl stuff which isn't too complicated, but I'd rather it be solid. But I do like to use virtualbox to test some python/django/nginx builds so better ubuntu and networking support would be nice.
I was trying to find the difference between virtualbox and vmware player on the windows side.
Can't really decide between parallels and fusion though...I need to run some opengl stuff which isn't too complicated, but I'd rather it be solid. But I do like to use virtualbox to test some python/django/nginx builds so better ubuntu and networking support would be nice.
> Can't really decide between parallels and fusion though
In case you haven't seen it, MacObserver did a comparison of Parallels to Fusion to VirtualBox recently (on the Mac):
http://www.macobserver.com/tmo/article/benchmarking-parallel...
Their conclusion is that Parallels 8 is a bit faster than VMWare Fusion 5 and both are much faster than VirtualBox. VirtualBox doesn't have nearly the 3D support of the others, so depending on what OpenGL stuff you try to run it might not work.
> Hm - is this just for Mac OS X or is this true for the windows version of virtualbox as well?
You mean is Parallels and Fusion more performant than VirtualBox? I'd be willing to bet that the commercial products in this arena are easily faster.
As for me, I have no real need for Windows, I just like to keep the ability to run Windows apps on rare occasion, so I've stopped paying for VMWare Fusion updates and plan to just use VirtualBox since I don't need the speed. It was Steam on the Mac that put an end to my need for really good Windows virtualization.
In case you haven't seen it, MacObserver did a comparison of Parallels to Fusion to VirtualBox recently (on the Mac):
http://www.macobserver.com/tmo/article/benchmarking-parallel...
Their conclusion is that Parallels 8 is a bit faster than VMWare Fusion 5 and both are much faster than VirtualBox. VirtualBox doesn't have nearly the 3D support of the others, so depending on what OpenGL stuff you try to run it might not work.
> Hm - is this just for Mac OS X or is this true for the windows version of virtualbox as well?
You mean is Parallels and Fusion more performant than VirtualBox? I'd be willing to bet that the commercial products in this arena are easily faster.
As for me, I have no real need for Windows, I just like to keep the ability to run Windows apps on rare occasion, so I've stopped paying for VMWare Fusion updates and plan to just use VirtualBox since I don't need the speed. It was Steam on the Mac that put an end to my need for really good Windows virtualization.
Parallels Desktop ist more polished than VMware Fusion but more expensive due to a higher number of paid upgrades – those are about the essential differences in my opinion.
ah ok. I was expecting VMWare to be miles ahead since they are the 800 lb virtualization gorilla, but parallels imported my virtualbox windows box more or less seamelessly (save an automated microsoft phone re-registration) and some sales guy got in touch with me 12 hours after I downloaded the trial. Go figure...
Moving from VMWare Server to VirtualBox on Windows I found VirtualBox to be significantly faster.
I'm getting mass tearing with my work iMac and VMWare Fusion, Parallels locks you in at 60.
I also found Parallels 8 to have a bug where when using it with Ubuntu 12.04 XFCE, it would skip tabs in Chrome. Downgraded back to 7 - 8 was a free upgrade for me anyway.
Have you locked your framerate to 60 with fusion? I'd be interested in using fusion 5 if it has good performance compared to Parallels, especially now that 8 is buggy for me.
I also found Parallels 8 to have a bug where when using it with Ubuntu 12.04 XFCE, it would skip tabs in Chrome. Downgraded back to 7 - 8 was a free upgrade for me anyway.
Have you locked your framerate to 60 with fusion? I'd be interested in using fusion 5 if it has good performance compared to Parallels, especially now that 8 is buggy for me.
A main reason many of us use Virtualbox is because of Vagrant. If the same thing was easily possible (Is it?) with Parallels or VMWare we'd use those exclusively. I have licenses for both and use Parallels for any Windows-required work.
Vagrant will work with Parallels and VMWare in the next 12 months.
How are the chances of a version working with libvirt/kvm?
Would be willing to help.
Would be willing to help.
If it is Linux/Debian/Ubuntu the development environment setup problem can be solved by maintaining internal apt repository. It takes a bit of effort to setup, but after that it is a really smooth ride.
[deleted]
It seems as though it will take a few more of these before Apple users learn what Windows users learned awhile ago -- there's rarely any good reason to upgrade any software, particularly your operating system, immediately upon release.
Has anyone installed the relevant firmware update https://support.apple.com/kb/DL1590 for 2010 MacBook Airs? I'd like to know if that introduces the same bug.
https://www.virtualbox.org/ticket/10965 indicates that it's the Ivy Bridge skus, so I think your 2010 Air is ok. Caveat emptor: I do NOT own a 2010 MacBook Air.
We will have a hard time coming https://www.virtualbox.org/ticket/10965
From vbox forums, someone at Oracle:
"That said, I believe we're now far enough along to say that there will highly likely be at least a test build pretty soon. Certainly sooner than in two weeks..."
https://forums.virtualbox.org/viewtopic.php?p=236591#p236591
"That said, I believe we're now far enough along to say that there will highly likely be at least a test build pretty soon. Certainly sooner than in two weeks..."
https://forums.virtualbox.org/viewtopic.php?p=236591#p236591
Oracle: We reported the bug a long time ago and still Apple released the update.
Apple: ...
Me: How the fuck am I going to work tomorrow? Maybe going full Vagrant wasn't a good idea after all :(