IssueTracker

Hi, this is Wei from Intel HAXM team.

I am afraid that I cannot reproduce the crash as your steps.

In the call stack, it is shown that crash is happened on hax_sync_vcpus. (Failed to sync HAX vcpu context between qemu and hax driver, hax_arch_set_registers() return negative value)

In mac platform, hax sys run errors/logs should be redirected to file /var/log/system.log. We can use Console to find system.log or use Terminal to open the system.log. And we can find lines like:
haxm_error: ...
Panic: ...

If hax sys/driver failed for IOCTLs inside hax_arch_set_registers(). Some errors should be printed out in /var/log/system.log. And we can check this file to see if anything wrong inside hax sys.

Can you please reproduce the issue in your side and send me back with the file /var/log/system.log. Then I can check more.

Thanks
Wei

hello Wei,
   this crash is reported by the breakpad and the information here is all we have got :(
if we have produced it internally, will put up the system.log certainly.

One way to reproduce this issue "Failed to sync HAX vcpu context", is by running emulator with HAXM then run a VM using Virtual Box (Docker/genymotion will do the trick).

Some information about my environment:
Virtual Box 5.0.4 r102546
The emulator that I am using is Nexus 6P API 23 Google APIs x86_64

Ok, we've reproduced the bug (we think) but are unsure how to proceed.

Coming off of yohan.hartanto's suggestion, the reproduction was done by:

1. Creating a FreeBSD virtualbox image (although any image should do)
2. Starting Virtualbox with that image
3. Starting the emulator

stdout/err shows:

Hax is enabled
Hax ram_size 0x77300000
HAX is working and emulator runs in fast virt mode.
console on port 5554, ADB on port 5555
Failed to sync vcpu reg
Failed to sync vcpu reg
Failed to sync HAX vcpu context
QObject::~QObject: Timers cannot be stopped from another thread

system.log shows:

Jan  5 11:42:42 lfy-macbookpro.roam.corp.google.com LookupViewService[689]: Error in CoreDragRemoveTrackingHandler: -1856
Jan  5 11:42:42 lfy-macbookpro.roam.corp.google.com LookupViewService[689]: Error in CoreDragRemoveReceiveHandler: -1856
Jan  5 11:42:46 lfy-macbookpro kernel[0]: cvcpu 0xffffff80496e4000 vmid 0 vcpu_id 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: HAX: vmxon failed (12c79000). Is that another VMM running?
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: The VMXON err: 1
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4_vmxe: 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err 1
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_addr 12c79000
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type1 1
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type2 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type3 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmclear_err 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmptrld_err 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_no 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_err 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: HAX: vmxon failed (12c79000). Is that another VMM running?
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: The VMXON err: 1
Jan  5 11:42:46 lfy-macbookpro kernel[0]: Panic:load_vmcs fail while vcpu_prepare: 1haxm_error: log_host_cr4_vmxe: 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err 1
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_addr 12c79000
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type1 1
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type2 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type3 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmclear_err 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmptrld_err 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_no 0
Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_err 0
Jan  5 11:42:52 lfy-macbookpro.roam.corp.google.com UserEventAgent[47]: extension com.apple.RemindersNC -> com.apple.reminders
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: HAX: vmxon failed (12c77000). Is that another VMM running?
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: The VMXON err: 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: Panic:load_vmcs fail on vcpu_set_regs: 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4_vmxe: 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_addr 12c77000
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type1 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type2 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type3 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmclear_err 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmptrld_err 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_no 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_err 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: HAX: vmxon failed (12c77000). Is that another VMM running?
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: The VMXON err: 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: Panic:load_vmcs fail on vcpu_set_regs: 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4_vmxe: 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_host_cr4 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_addr 12c77000
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type1 1
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type2 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmxon_err_type3 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmclear_err 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmptrld_err 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_no 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error: log_vmoff_err 0
Jan  5 11:42:57 lfy-macbookpro kernel[0]: haxm_error:
Jan  5 11:42:57 lfy-macbookpro kernel[0]: ...........hax_teardown_vm
Jan  5 11:42:57 lfy-macbookpro root: Error reading bundle identifier: {
            NSApplicationName = "qemu-system-i386";
            NSApplicationPath = "/Users/lfy/emu5/master/external/qemu/objs/qemu/darwin-x86_64/qemu-system-i386";
            NSApplicationProcessIdentifier = 44384;
            NSApplicationProcessSerialNumberHigh = 0;
            NSApplicationProcessSerialNumberLow = 491640;
            NSWorkspaceApplicationKey = "<NSRunningApplication: 0x1007a6ab0 ((null) - 44384)>";
            NSWorkspaceExitStatusKey = 0;
        }

So: I recall that I was never able to run either more than one instance of the emulator at a time, let alone other emulators side by side. Could there be like a HAXM config thing that would allow us to do it? From system.log, it sort of looks like that HAXM is not intended to run more than one 'VMM' at a time.

A more common scenario (possibly) is running dev API services using docker and connect our app on emulator to that docker container. This is the dev environment setup that we want but this issue prevents us from doing so.

Please see the haxm official release notes:

Known Issues:
-Coexistence problem with VirtualBox versions newer than 4.2.8 on Mac OS X*

The reason is VirtualBox will exclusively use VT. So HAXM driver can no longer take VT ownership, that is why vmxon will failed for hax.

For this issue, VirtualBox should change its behavior, while HAXM has correct logic and behavior at present.

 

In this specific case, tell the user about a probable conflict with VirtualBox 4.2.8+ on OSX

Yurii, Please open a bug with VirtualBox to discuss.

The bug is already there: https://www.virtualbox.org/ticket/14294
I bumped it

Yurii, in your error message, can you please reference the VirtualBox issue in your error message:

"Unfortunately, VirtualBox 4.3.30+ does not allow multiple hypervisors to co-exist.  In order for VirtualBox and the Android Emulator to co-exist, VirtualBox must change back to shared use.  Please ask VirtualBox to consider this change here: https://www.virtualbox.org/ticket/14294"

Re-opening.  Still an active issue, even if we have a better error message.

Hi Intel engineers,

> VirtualBox will exclusively use VT. So HAXM driver can no longer take VT ownership

IIUC, You should be able to reproduce this problem with VirtualBox and VMware.  Can you please try those together to see if VMware Fusion is able to work with VirtualBox?

> The reason is VirtualBox will exclusively use VT. So HAXM driver can no longer take VT ownership, that is why vmxon will failed for hax.

Hi Wei,

I've searched the VirtualBox svn for references to host_vmxon and only found a hit in one file:

src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp

rc = host_vmxon(false /* exclusive */);

It appears to call host_vmxon with exclusive==false

I even searched history of this call to see if it was ever exclusive.  It appears to be non-exclusive all the way back to its first appearance in r14905

I'm starting to think we have a problem in host_vmxon.  I'll reach out to Apple unless you disagree.

In Frank's repro, we're getting this:

Jan  5 11:42:46 lfy-macbookpro kernel[0]: haxm_error: The VMXON err: 1

https://github.com/opensource-apple/xnu/blob/10.11/osfmk/i386/vmx.h

#define VMX_OK                  0 /* all ok */
#define VMX_UNSUPPORTED 1 /* VT unsupported or disabled on 1+ cores */
#define VMX_INUSE               2 /* VT is being exclusively used already */

So it looks like host_vmxon is returning VMX_UNSUPPORTED (not VMX_INUSE)

https://github.com/opensource-apple/xnu/blob/10.11/osfmk/i386/vmx/vmx_cpu.c

host_vmxon
  if (!vmx_globally_available())
                return VMX_UNSUPPORTED;

vmx_globally_available
  checks that all cpus have cpu_datap(cpu_number)->cpu_vmx.specs.vmx_present

Since vmx_present is true for all CPUs when VirtualBox is not running, I would assume that this bit is changed by operation of VirtualBox.  But it only looks like vmx_present is set during machine startup?  Reading source hasn't made it clear how this could change.

processor_start_thread
  slave_machine_init
    cpu_machine_init
      vmx_cpu_init
        specs->vmx_present = vmx_is_available() && vmxon_is_enabled();

I think the next step is to build an OSX kernel and try to figure out how vmx_present is true for VirtualBox and then false for HAXM?

The issues didn't exist in VirtualBox 4.3.28, but introduced with 4.3.30 with everything else being the same (Android Studio, OSX version). After I got the issue with upgrade to 4.3.30, I immediately rolled back to 4.3.28 and just that fixed everything. I tried almost all sequential VirtualBox releases and the issue immediately reappears.

So, if someone could figure out what's changed between these releases in VirtualBox, that might help.

I have confirmed that VMWare Fusion and VirtualBox both run with VT-x enabled.  (I'm running a 64 bit windows machine and a 64 bit linux machine in VMWare and VirtualBox respectively.)

Just tested with the new release of VirtualBox 5 and seems to be working again (tested on a mac).

Still an issue in this environment:
OSX - 10.10.5 (14F1713)
VirtualBox 5.0.16 r105871
SDK Tools 25.1.0
SDK Platform-Tools 24rc1

Just in case it was happening to you guys, I was running docker-machine on a MAC.

I did everything, nothing could make it work, as soon as I quit VirtualBox it started working....

"dm stop default" solves the problem on 10.9.5 OSX,

docker-machine --version
version 0.4.1 (e2c88d6)

docker --version
Docker version 1.11.0, build 4dc5990
dm

Looks like Intel was awared of the issue for 4 years base on this page:


https://software.intel.com/en-us/forums/android-applications-on-intel-architecture/topic/279137#comment-1869657

"HAXM stops VirtualBox from working on OS X" - first reported  03/22/2012 - 08:29

Same problems occurs with Docker for Mac (which utilizes the native hypervisor framework of OS X: xhyve).

Stopping Docker for Mac solves the problem.

Cheers!

[Comment deleted]

Can confirm solution in comment #28 fixes the issue...at least for me!

I came across same issue. Killing VirtualBox did the trick...

$ emulator -avd marshmallow                                                                                                          [0:45:53]
Hax is enabled
Hax ram_size 0x40000000
HAX is working and emulator runs in fast virt mode.
console on port 5554, ADB on port 5555
Failed to sync vcpu reg
Failed to sync vcpu reg
Failed to sync vcpu reg
emulator: ERROR: Unfortunately, there's an incompatibility between HAXM hypervisor and VirtualBox 4.3.30+ which doesn't allow multiple hypervisors to co-exist.  It is being actively worked on; you can find out more about the issue at http://b.android.com/197915 (Android) and https://www.virtualbox.org/ticket/14294 (VirtualBox)
Internal error: initial hax sync failed

$ pg docker                                                                                                                          [0:46:06]
user         74112   1.0  2.7  3084932 448692   ??  S    Tue10AM   7:49.30 /Applications/VirtualBox.app/Contents/MacOS/VBoxHeadless --comment boot2docker-vm --startvm b2e4ad69-a37b-401d-89d5-851edf059a44 --vrde config
user         84762   0.0  0.0  2444056    800 s002  S+   12:51AM   0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn docker

$ sudo kill -9 74112

For anyone else pulling out their hair because uninstalling VirtualBox and Docker wasn't enough, check you don't also have dlite installed - removing this and rebooting fixed the problem for me. (mac osx 10.11.5)

I can confirm solution commented below in #28 too, just stopped Docker for Mac daemon and the problem was solved.

I can confirm solution #28 too (stop Docker on my Mac), but how to test an App on a local Docker server...

Agree with Arnaud, #28 allows running emulator, but it's not a fix if you need to run both: docker based dev server and emulator because that's your dev environment.

@Arnaud
You can try non x86 image/architecture. It's painful, but at least it works.

I can confirm as #25 said that when closing docker ("docker-machine stop default") my emulator can run again. For me that's a good-enough solution as I'm not running docker to directly use from within my Android app for now.

"It is being actively worked on;"

Who is working on this?

Same as comment #28, I confirm that the problem still happens using Docker for Mac (1.12.0-rc2), i.e without VirtualBox/docker-machine.

Also reproduced with "Docker for Mac" #214287

Guys! This is not just a problem with VirtualBox. I have Docker Version 1.12.0-rc2-beta17 running on my Mac and it shows me the same error message. VirtualBox is not even installed! It's annoying. These days Docker is omnipresent. It must be possible to run Android-Emulator and Docker on the same machine.

It looks like the main issue is that HAXM and xhyve (the hypervisor used by Docker) [1], cannot be used at the same time on OS X.

It looks like the best way to solve the problem is to use the new Hypervisor.framework on OS X, instead of HAXM. The former doesn't require a custom kernel driver (!) and allows several virtualization solutions to work concurrently (!!).

[1] http://www.xhyve.org/
[2] https://developer.apple.com/library/mac/documentation/DriversKernelHardware/Reference/Hypervisor/

By the way, someone is working on porting upstream QEMU to use the hypervisor framework (by essentially performing KVM -> Hypervisor.framework translation).

See https://github.com/abligh/qemu/tree/qemu-hypervisor-framework

May we have hope to see the Android emulator on OS X using the Hypervisor Framework in a foreseeable future? What can we do to help?

I am running docker-beta.

docker --version
Docker version 1.12.0-rc2, build 906eacd, experimental

stopped docker and i am able to run the android emulator.

Ugh no wonder people prefer developing for iOS. Out of the box Android Studio on an i7 Macbook Pro don't even work.

Getting along with https://www.virtualbox.org/ticket/14294

When running a QEMU based emulator, firing up the Docker 1.12beta kills off the emulator (causes it to hang and die.

I think the essential problem is haxm is not compatible w/ the osx hypervisor framework...the emulators have to use the hypervisor framework :-(

What's horrible is you can't use Docker w/ any Android development environment...Genymotion doesn't work w/ Docker because it uses Virtualbox.  The official Android QEMU emulators don't work.

The only thing you can do if you need to run Docker at the same time is use Genymotion and Docker 1.11, not the latest Docker 1.12 :-P

I confirm solution in comment #28 benjoh...@gmail.com

#28: "Stopping Docker for Mac solves the problem."

That's not really a solution IMHO...if you want to run a local test server in a Docker container at least.

What I've been doing is using Docker Toolbox (less efficient than Docker for Mac) and Genymotion....it's a suboptimal compromise...

I'm trying to connect the emulator to my local server running in Docker, and this is a huge problem. Is a solution in the works?

Same issue here, running Virtualbox 5 on OSX and AVD. Very frustrating that I can't run my VM with the dev server I use as an API. It's been more than 6 months of people reporting this same issue, is there any resolution coming any time soon?

I stopped docker and it's still not working. Just going to develop for ios and come back to this in a few weeks.

This happens only when using the emulator on x86 or x86_64. When using ARM you may use it at the same time with virtual box / docker / whatever.

Problem is: ARM emulation is too slow on x64 system, unfortunately this is not a viable solution.

Stop Docker and/or any VirtualBox VM and problem solved.

Confirmed stopping Docker for Mac worked for me.

Please stop recommending or confirming to stopping docker or virtual box. That is exactly the issue that we want to be resolved, having emulator and virtual box (docker) running in parallel in Mac.

Any news on this?

Any news?

To be able to run with Docker in parallel, emulator needs to use another hypervisor implementation that's compatible with Docker's VirtualBox. This is a large project, and the emulator team is now in a designing phase. I will keep this bug updated and will post news on the progress.

Docker does not use Virtualbox anymore!

Docker for uses the macOS Hypervisor.framework (part of macOS 10.10 Yosemite and higher) to run containers, meaning that no separate VirtualBox is required.
Docker for Windows requires the Hyper-V Windows feature (only Windows 10, which is not available on Home-edition).

https://docs.docker.com/docker-for-windows/faqs/
https://docs.docker.com/docker-for-mac/faqs/

Docker Toolbox still uses Virtualbox luckily.
That way, at least for Android development, I can run Docker Toolbox and Genymotion on the same Macbook until Google/Intel/MS get their act together and fix this incompatibility :-)

And 4 years have passed... and still not working... that's how Oracle "engineers" worry about user problems... shame on you.

I get this crash when trying to run the Android emulator while Docker is running, I stopped Docker from the system bar on my Mac and then the emulator started fine.

Stopping Docker for Mac didn't help until I also restarted Android Studio itself. Not sure what difference does that make.

For those facing this issue and have no clue, which kext is locking vcpu context: Try stopping Docker daemon!

I still haven't understood what i should do.
working on mac osx 10.11
I dont have Docker installed,
Using Virtual box (5.0.26) - with a virtual machine i cannot afford shutting off

Does it really mean i cannot run the AVD emulator - very strange it has been 4 years since the Problem was reported to 2 tiny startups like Oracle and Google and still its not working.....

someone? something?

maimon: the answer is don't run the accelerated AVD emulator...use Genymotion or use the non-accelerated ARM emulator (though that feels like watching ice melt :-)

GenyMotion is not free

I started docker machine to server my web API, then I failed to launch the android emulator.

It's impossible to use the ARM emulator on x86, that feels like watching ice melt.  (* ￣ー￣)
Bluestacks launch also failed when the docker-machine is started. (or virtual machine is still running)

Maybe I should launch a proxy server at localhost then...

Short answer for me: kill local Docker container manager.

I encounter the issue because I had a vagrant box running. Stopping vagrant made the Android emulator start but that's quite annoying.

A pragmatic approach for those of us needing to run a VirtualBox dev server and an Android emulator  on the same physical machine there is the option of installing an x86 Android VM in VirtualBox itself.  See http://www.android-x86.org/ for images and set up details.  It works well - just need to "adb connect xx.xxx.xxx.xxx" to the virtual android device - it's then available for debugging etc

or https://www.osboxes.org/android-x86/#android-x86-7_0-vbox for alternate images...

Why is it that Docker & Virtualbox can run in parallel, but Docker & AVD, or Virtualbox & AVD can't? Hmm ...

Docker actually runs on VirtualBox. So it is really one thing. It is really VirtualBox and Emulator that are incompatible.

Thats not entirely true. Modern Docker for MacOS uses a component called
HyperKit [1] to talk to the CPU hypervisor through MacOS native APIs
(Hypervisor.Framework [2]). Even in this scenario, Android Emulator and
Docker are incompatible and cannot be used at the same time.

[1] https://github.com/docker/hyperkit
[2] https://developer.apple.com/reference/hypervisor

Comment #79 on issue 36949180 by yohan.ha...@gmail.com: [Emulator] HAXM ioctl
failed on Mac when trying to restore vcpu state
https://code.google.com/p/android/issues/detail?id=197915

Docker actually runs on VirtualBox. So it is really one thing. It is really
VirtualBox and Emulator that are incompatible.

I know we should not ask questions here but we have 2017 now and it's not possible to run Android-Emulator and Docker in parallel on the same machine (on Mac).  This is MORE than annoying! Everything is dockerized these days which is great but I have to use real devices to test my Android app!! Do you just ignore developers using a Mac??  

So, yea.. I can't work on Android on my Mac because I use Docker. Great.

Virtualbox 5.1.14
Android Studio 2.2.3

Tested with latest updates on all SDK / HAXM etc, and it still doesn't work.

Just to note that if i change to a non-x86 device image, the emulator runs fine (albeit horribly slow).

But this may be because it's actually not using the HAXM thing.

Same Issue here on Mac pro 2016 using HAXM and Docker for Mac(CE) with docker HyperKit (based on apple Hypervisor framework).

Dear Google Android Emulator Team:
how about build an offical docker image for Android? Android ist built on linux kernel and docker runs on linux kernel. That seems plausible to me. Developers will love it. And Linux Community will be grateful for your contribution to linux kernal and will love it too. Please do it and let us make the linux great again.    

[Comment deleted]

Virtualbox and VMWare Fusion can run together without problem.  VMWare Fusion and AVD has no problem.  Only Virtualbox and AVD has problem.

Has anyone tried working around this by running qemu in docker and X-windows on mac?

I just quit docker and it worked.

Has anyone tried

https://software.intel.com/en-us/android/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-mac-os-x

The change log suggests this update resolves the issue. I tried but still having the problem

 stop Docker for Mac worked for me.

[Comment deleted]

The latest HAXM update was offered to me in Android Studio 2.4 Preview 3 today and it seems to run fine together with the latest Android Emulator, the latest MacOS, Docker 1.13.0, and the latest VirtualBox.

Re #94: Yes, after updating to HAXM 6.1.1 (thanks for Intel), you are able to run Android Emulator with Docker and VirtualBox.

Considering the bug fixed: HAXM 6.1.1 (available as a part of Android Studio or on Intel website at https://software.intel.com/en-us/android/articles/intel-hardware-accelerated-execution-manager ) is designed to coexist with Docker/VirtualBox/HVF hypervisors on Mac OS

Important note, taken on Intel's website:

The SDK Manager will download the installer to the "extras" directory, under the main SDK directory. Even though the SDK manager says "Installed" it actually means that the Intel HAXM executable was downloaded. You will still need to run the installer from the "extras" directory to finish installation.

After installing 6.1.1, I can finally run the emulator alongside my vagrant box. YAY!

The emulator now works with vagrant as well as with docker! Christmas came in April this year!
And yes, as mentioned in #97, I needed to run the installer from `extras/intel` directory manually.

Hi. As of now (2017-APR-06) I've been running the latest OSX, latest Android Studio 2.3.1 from April 1. Its SDK manager said HAXM 6.1.1 should be installed. I tried spinning 1 VirtualBox VM and Android emulator afterwards:

~/Library/Android/sdk/tools]$ ./emulator @Nexus_5X_API_22
emulator: WARNING: encryption is off
Hax is enabled
Hax ram_size 0x60000000
HAX is working and emulator runs in fast virt mode.
Failed to sync vcpu reg
Failed to sync vcpu reg
Failed to sync vcpu reg
Failed to sync vcpu reg
Failed to sync vcpu reg
Failed to sync HAX vcpu contextInternal error: Initial hax sync failed

So whatever shipped with Android Studio didn't help me.  I went to Intel's website and I've installed HAXM 6.1.1 again, by hand. This time it worked.  I can run Android x86 emulator with vagrant VM.


Darwin wkoszek_laptop 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

Hi! As it was said in #99, SDK manager does not install HAXM correctly.

After updating HAXM 6.0.1 was still installed (for my upgrade case). I checked it by running a following command:

$ANDROID_HOME/extras/intel/Hardware_Accelerated_Execution_Manager/silent_install.sh -v
6.0.1

I had to reinstall HAXM manually:

sudo $ANDROID_HOME/extras/intel/Hardware_Accelerated_Execution_Manager/silent_install.sh

After that the emulator and docker run both at the same time! \o/

I have been unable to start the Emulator recently on Mac OS X 10.12.4, and found that HAXM strangely wasn't installed anymore in the SDK Manager.  So I chose to install it from the SDK Manager and it completed, but still the emulator would not start with Docker installed/running.  I then downloaded HAXM 6.1.2 from the Intel site and installed it manually and then even with Docker running it would start.

Just to add my $0.02 here. There are two problems on OSX:
1. Haxm reports a conflict with virtualbox when in actual fact the conflict may be with another hypervisor (e.g. docker very common now).
2. Haxm is installed incorrectly by android sdk. I suspect the problem may be that it needs sudo permissions which it does not have and silently ignores. If I install manually (6.2.1) with sudo all is good and the error goes away even with docker running.